> Mouse wrote:
> > That means, that a program that creates output into
> > StreamTransformationFilter containing CBC encryptor (and tries to
> > force each individual record out), using something like:
> >
> > for (i=0; i < total; i++) {
> > encrStream.Put(record[i], record[i].size());
> > encStream.MessageEnd();
> > }
>
> This is fine (except that for security you need to use a
> different random IV for each record in CBC mode),
Yes that is understood. I've got to work the code without MessageEnd(), but
now having difficulties with MessageEnd(). Please see below.
The example you gave does not work when the encrypted file is also encoded,
i.e. when file is created by sequence Encrypt->Base64Encode->FileSink.
MessageEnd() is called on the aesEnc that comprises of encryptor, encoder
and file-sink:
Base64Encoder *baseEnc = new Base64Encoder(new FileSink("tenc.txt"));
StreamTransformationFilter aesEnc(encrAES, baseEnc);
Every binary output message is 100 bytes long prior to encrypting+encoding.
> but on the decryption side, you need to call
> MessageEnd() at the end of each encrypted record.
The decryptor code doesn't even get to the point where I'd be able to call
MessageEnd().
> FileStore f("tenc.txt");
I use here
FileSource f("tenc.txt", true, new Base64Decoder());
Is this the cause of my problem? But I need to place Base64 decoder in line
before the actual read from the file, and I couldn't figure how to do it
with FileStore. Besides, all the record length information is on un-encoded
data, so I need to get through the encoding before I can deal with record
size...
> StreamTransformationFilter d(decrAES, new ByteQueue);
OK so far.
> while (f.AnyRetrievable()) {
> int size = 100;
> f.TransferTo(d, size);
At this point my code crashes. No chance to call d.MessageEnd().
f.MaxRetrievable() here is 562. Encryptor placed 5 records of 100 bytes each
(that are subsequently Base64-encoded) in the file.
Is it possible to process Base64-encoded file where each record was closed
and padded by MessageEnd()?
> You might also want to think about why you need to
> pad/packetize your records in the first place. Why not
> encrypt all of the records as one big "message" and only
> pad (call MessageEnd()) at the end? You'd save a lot of
> space on the IV and padding.
In general I agree with you, and my "main" processing doesn't use
MessageEnd() until the end of data stream (of course there should be no
padding in CFB or cTR mode, but that's besides the point). But sometimes
packetizing is necessary - and I'm trying to figure out a way of dealing
with packetized encoded data. I need your help in that.
Thank you!
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the "Crypto++ Users"
Google Group.
To unsubscribe, send an email to [EMAIL PROTECTED]
More information about Crypto++ and this group is available at
http://www.cryptopp.com.
-~----------~----~----~----~------~----~------~--~---
