[fpc-pascal] TBlowfishDecryptStream flaw

[Michael Van Canneyt]

On Sat, 5 Mar 2011, Jorge Aldo G. de F. Junior wrote:

> i have a problem with TBlowfishDecryptStream :
[snip]
>
> The problem now is that it eats chars at the end of the generated
> lBuffer (tested by taking a tmemorystream thru tblowfishencryptstream,
> then taking the result to this tblowfishdecryptstream, than back to a
> tmemorystream and comparing the results, the original tmemorystream
> shows to be bigger than the resulting tmemorystream)...
>
> Basically i need :
>
> 1 - That TBlowfishEncryptStream guarantees that the same ammount of
> bytes feed to it, ends up at the output of it

That should be the case. See below for an explanation why you get different results.

> 2 - That TBlowfishDecryptStream simply allows us to use Size property
> (Well, sometimes i receive a tmemorystream in an unrelated part of the
> code so i cannot read the original size the buffer had before
> encrypting)...

This is impossible by definition.

You should always design your algorithms so they don't need size.
Compression and encryption streams cannot have size, since they 
do not know the size of the input data.

There are only 3 streams that have guaranteed size:
- Memory stream
- File stream
- String stream (a variant of memory stream)
All other streams do not have size.

Your second mistake is that the output of the BlowFish encryption stream is 
only fully known when it is destroyed. You should FIRST destroy the 
blowfish encryptor/decryptor stream. Only then, all characters that are in 
the internal encryption buffer are written to the output buffer.

Alternatively, call Flush() to write the remains of the internal buffer to 
the output buffer. Note that after a call to flush(), no more data can be 
written to the stream, because the output will then be wrong.

Michael.