AES anyone?

[Regan Heath]

BCS wrote:
> Reply to Bedros,
> 
>> can you explain your idea of streaming?
> 
> It would sit on top of another stream object (a socket or file object or 
> whatever). When it is given data it would encrypt it and pass it out the 
> other side. Another object at the other end would receive the data and 
> decrypt it. If, for instance, the intervening data path is a network 
> socket, then the code that uses the stream would be able to treat the 
> objects as if they were the socket it's self. As to the 16 byte issue, 
> undersized packets would be padded and the length would also transfered 
> with them. How, would be up to the implementation.
> 
> 
> IIRC Tango has a way of doing this sort of filtering.

The padding and length are only applied at the end of the stream, you 
cannot apply them in the middle.  The existing digests are written in 
such a way to support streaming, see:

http://www.dsource.org/projects/tango/docs/current/tango.io.digest.MerkleDamgard.html

for a list of the operations and the order they are applied.  I believe 
AES could be implemented using the same method.

What this means in terms of streaming is that the AES filter will read 
from the source until it has 'blockSize' bytes, it will process those 
and produces some output which can then be read from it.  This continues 
until it reads EOF from the source stream, at this point it pads and 
appends the length producing the final block of data.

One further consideration is upon decode you must know when you are 
processing the final/terminal block of data as only then can you unpad 
correctly, usually this means you must know the exact length of the 
encrypted data.

You cannot tell the terminal block by inspection as the case for 1 byte 
of padding is the block finishing with a byte of value 0x01.  This case 
is indistinguishable from a non-terminal block ending 0x01.

Regan Heath