I have released library version 0.6 that introduces AES-192 and AES-256 privacy protocols.

I have held off for a long time on implementing the high encryption AES protocols because I didn’t have anything to test my implementation against.

I am not a cryptography expert so the only way I have of implementing required algorithms is by trial and error. It is very important for me to be able to properly debug SNMP exchange between the library and a test agent. Without detailed trace information that will give me encryption keys used, what is being received and exceptions (or errors) generated during every step of the packet processing I can’t confirm that library is doing what it’s supposed to.

A couple of days ago I received a request from Yiping asking for AES-256 support.

With somebody needing this level of encryption, I had a reason to invest some time into finding an appropriate debugging platform that will allow me to test strong cryptography. I did manage to find a way to do what I needed and now the final two of the three outstanding privacy protocols have been implemented.

I will implement the final outstanding privacy protocol, TripleDES when somebody out there in the Internet land requests it.

Quick review of what needed to be changed to provide support for the 192 and 256 bit versions of AES.

PrivacyAES class is a generic implementation of the AES encryption. Constructor accepts a single parameter determining what size key should be used and based on that value both encryption and decryption are performed.

I expected PrivacyAES to support 192 and 256-bit key sizes the way it was but I was reluctant to release it without at least rudimentary testing. Anybody who worked with any form of encryption will tell you that when you use “canned” encryption protocols that are part of frameworks (like .NET) you have to test.

Turns out this was a good call. Since I didn’t spend years studying RFCs, I have missed a section in the proposal draft-blumenthal-aes-usm-04.txt that describes how short encryption keys are extended. I assumed that HMAC version of the authentication protocol is used, the same way as when generating encryption key from the user secrets (passwords). Boy, was I wrong!

Short encryption key are generated by both AES-192 and AES-256. So with both protocols you need to extend them. Process to extend the keys involves hashing the generated short keys using SHA1 or MD5 (depending on which authentication protocol is selected) classes. This is done using SHA1.CalculateHash() or MD5.CalculateHash() and NOT using HMACSHA1 and HMACMD5 classes.

Good news is that encryption block size remains 128 Bytes regardless of which size key is used to encrypt.

One this that might be useful to know is that I have used Rijndael implementation included with .NET Framework version 2.0. Framework implementation of Aes is included and supported by the .Net framework version 3.5 but I did not like the dependency. This is mostly because a lot of the PCs I get to use don’t have framework version 3.5 installed and I don’t want to spend hours installing the newer version over too slow links.

From my tests and final implementation I have managed to figure out that relevant difference between Rijndael and Aes encryption is how they handle block sizes. Rijndael requires that data being encrypted is composed of a multiple of 128 byte blocks and if data being encrypted is not, padding should be applied to data. Aes on the other hand doesn’t depend on this and can encrypt and decrypt data of any size.

After some playing around it was apparent that I can take data that I need to encrypt that is not composed of 128 byte blocks, pad it and use Rijndael to encrypt it. Then, when encryption is done, I just trim the data back to its pre-encryption size and presto, it is ready for transmission.

As always, keep the commends and requests coming. That’s what is driving the development.