www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - AES anyone?

reply 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
Aug 16 2007
next sibling parent 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

Aug 16 2007
prev sibling parent reply 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.
Aug 17 2007
parent reply 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.

Aug 17 2007
parent reply 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
 

Aug 17 2007
next sibling parent reply 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
Aug 17 2007
parent 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
 

Aug 17 2007
prev sibling parent reply 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]
Aug 17 2007
parent 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]

Aug 19 2007