[prev in list] [next in list] [prev in thread] [next in thread] 

List:       botan-devel
Subject:    [Botan-devel] Dubious MinGW error messages
From:       lloyd () randombit ! net (Jack Lloyd)
Date:       2008-04-25 15:58:30
Message-ID: 20080425155830.GC5487 () randombit ! net
[Download RAW message or body]

On Fri, Apr 25, 2008 at 05:42:54PM +0200, Hans Mull wrote:
> Jack Lloyd schrieb:
> > Pipe pipe(get_cipher(/*args*/),
> >           new Fork(
> >                    new Base64_Encoder,
> >                    new Chain(new MAC_Filter(/*args*/), new Base64_Encoder)
> >   ));
> >   
> Thank you, that works fine in encryption, but how to decrypt the string?

The general flow for decryption/MAC check would look like:

Pipe(new Base64_Decoder,
     new Fork(
         get_cipher(/*args*/),
         new MAC_Filter(/*args*/)
         ));

You would feed only the ciphertext through this pipe, not the received
MAC value. Then, when all data has been processed, check the MAC that
was just computed and compare it with the one that was sent. If they
match, then you know the ciphertext is authentic, and it is safe to
release the plaintext.

> How can I derive the salt SecureVector from the ciphertext input (maybe:
>     new SecureVector<byte>(ciphertext.substr(0,8));
>     string ct = ciphertext.substr(8, ciphertext.length();

In the code you sent earlier where those values were simply
concatenated, that would probably be fine.

A simple format for processing could be

8 bytes salt
20 byte MAC
arbitrary length ciphertext

With this, you could just pull off the first 28 bytes and then feed
the rest of the input into the Pipe. However this doesn't work well if
you are planning on encrypting large files, because computing the MAC
requires processing the ciphertext as well. This means you would have
to buffer the entire ciphertext in memory until you were completely
done, then write the MAC, then the ciphertext. For small inputs this
is not an enourmous issue though.

I'm feeling like there should be a set of password-encryption filters
in the library itself to handle this kind of thing for people. It
would have to be a non-standard format, as I have never gotten around
to finishing the CMS support, but I suppose one library-wide
non-standard format is better than tens of application-specific
non-standard formats.

-Jack


[prev in list] [next in list] [prev in thread] [next in thread]