• Bedros Hanounik <2bedros gmail.com> Aug 16 2007
• kris <foo bar.com> Aug 16 2007
• BCS <ao pathlink.com> Aug 17 2007
• Bedros Hanounik <2bedros gmail.com> Aug 17 2007
• BCS <ao pathlink.com> Aug 17 2007
• Regan Heath <regan netmail.co.nz> Aug 17 2007
• BCS <ao pathlink.com> Aug 17 2007
• kris <foo bar.com> Aug 17 2007
• Bedros Hanounik <2bedros gmail.com> Aug 19 2007

Bedros Hanounik <2bedros gmail.com> writes:

anyone knows if tango lib has AES?

if not, I'm willing to write AES functions for it. I've never used D language
before, but I'm very familiar with AES implementations. 

I'll appreciate any feedback about AES modes needed, and where to start with D,
and how to integrate with Tango.

Thanks,

-Bedros

kris <foo bar.com> writes:

Tango does not have AES (if you're talking encryption). It does have a 
home for such things within tango.io.digest, so you may get some ideas 
regarding D from the code already there? Actually, perhaps AES should 
live in tango.io.cipher instead?

- Kris

p.s. tango.io.digest currently includes MD2, MD4, MD5, SHA0, SHA1, 
SHA01, SHA256, SHA512, and Tiger


Bedros Hanounik wrote:
 anyone knows if tango lib has AES?
 
 if not, I'm willing to write AES functions for it. I've never used D language
before, but I'm very familiar with AES implementations. 
 
 I'll appreciate any feedback about AES modes needed, and where to start with
D, and how to integrate with Tango.
 
 Thanks,
 
 -Bedros

BCS <ao pathlink.com> writes:

Reply to Bedros,

 anyone knows if tango lib has AES?
 
 if not, I'm willing to write AES functions for it. I've never used D
 language before, but I'm very familiar with AES implementations.
 
 I'll appreciate any feedback about AES modes needed, and where to
 start with D, and how to integrate with Tango.
 
 Thanks,
 
 -Bedros
 


If AES can operate in a stream mode, then having it as available as a stream 
filter would be high on my list.

Bedros Hanounik <2bedros gmail.com> writes:

can you explain your idea of streaming?

I was thinking of passing a buffer (pointer) to the AES function (with mode and
keys), along with the length. and the you get back the cipher data.

please remember that AES only processes data in increments of 16bytes. So, if
you send 17 bytes, you'll get cipher data length of 32byte; and you need all
the 32 bytes to decrypt. if you pass 127 bytes, you'll get back
128bytes.....etc.

so, it's important to keep track of the length of plain (original) data along
with the cipher data, so we can trim the extras once we decipher it.

-Bedros


BCS Wrote:

 Reply to Bedros,
 
 anyone knows if tango lib has AES?
 
 if not, I'm willing to write AES functions for it. I've never used D
 language before, but I'm very familiar with AES implementations.
 
 I'll appreciate any feedback about AES modes needed, and where to
 start with D, and how to integrate with Tango.
 
 Thanks,
 
 -Bedros
 


 If AES can operate in a stream mode, then having it as available as a stream 
 filter would be high on my list.
 
 

BCS <ao pathlink.com> writes:

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.

 
 I was thinking of passing a buffer (pointer) to the AES function (with
 mode and keys), along with the length. and the you get back the cipher
 data.
 
 please remember that AES only processes data in increments of 16bytes.
 So, if you send 17 bytes, you'll get cipher data length of 32byte; and
 you need all the 32 bytes to decrypt. if you pass 127 bytes, you'll
 get back 128bytes.....etc.
 
 so, it's important to keep track of the length of plain (original)
 data along with the cipher data, so we can trim the extras once we
 decipher it.
 
 -Bedros
 

Regan Heath <regan netmail.co.nz> writes:

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

BCS <ao pathlink.com> writes:

Reply to Regan,

 BCS wrote:
 


 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.


If you check for EOF after each block then you could detect the last block 
that way. This however might require sending an empty block if things match 
up exactly.

 
 Regan Heath
 

kris <foo bar.com> writes:

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.


Yes, Tango has stream filters to modulate (or even hijack) the content 
flowing through. Such filters are usually built upon a more generic 
mechanism though, such as plain old incremental-adjustment (the strategy 
followed by tango.io.digest classes)

- Kris

[snip]

Bedros Hanounik <2bedros gmail.com> writes:

I like the streaming concept.

First, I'll get AES implementation in D, then I'll adapt it for streaming. I'll
make AES class similar to tango.io.digest.Digest class.

my first goal is to get AES D implementation optimized; and at least as fast as
openssl AES implementation.




kris Wrote:


 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.


 Yes, Tango has stream filters to modulate (or even hijack) the content 
 flowing through. Such filters are usually built upon a more generic 
 mechanism though, such as plain old incremental-adjustment (the strategy 
 followed by tango.io.digest classes)
 
 - Kris
 
 [snip]