AES x86 - Algorithms in Assembly / News: Recent posts

I found a few more areas that had unneeded instructions or were using excess instructions. Particularly when trying to access the individual bytes of a double word. I think at this point the ASM is reasonably fast while still remaining readable.

Two areas could definitely benefit though. As mentioned before.. Brian Gladman's method for encryption and decryption for Rijndael is much better. My code reads and writes to memory fairly often whereas he got around that. It does make it much less readable however so I will leave that out. Also.. Serpent's key creation would benefit from just one more register.. this could be done with 64 bit ASM. If you are going to be encrypting a large number of blocks, as you normally would, then the amount of time spent in key generation is relatively small and probably wouldn't be noticed.... read more

I just reinstalled VS2005 so could build the win32 package.

I just released version 1.00

I will release the Win32 version on Monday probably as my computer right now is missing Visual Studio

The assembly still needs commenting but I did some decent code cleanup. For example, I was pushing ESP onto the stack and creating stacks where they were not needed. This was left over from Rijndael (which I had started a while ago) when I was learning assembly I used it as a template for the other code. There were also numerous places where unneeded instructions were occuring.... read more

So as mentioned in the last news bit, there were a number of unneeded instructions in release 0.99

As I removed them... I am feeling more and more contention between keeping things readable and making things fast. I am thinking that I will probably redo Rijndael's encryption/decryption loops, Serpent's key schedule and probably parts of Twofish using x86-64 bit ASM.

With 32 bit.. you only have 8 general purpose registers and one of them (esp) is needed often as a pointer to memory to save off values. With Rijndael, I was constantly having to save off values to the stack and then re-read them at the end of each loop. This adds a lot of memory latency and slows things down. In this case I really needed more registers.. or I could do something like Brian Gladman did to prevent moving around. The only problem with using something like Gladman, as mentioned before, is that it will make the readability of the code quite a bit harder.... read more

I have gotten rid of all of the C code that I was using for the key schedules. It is now done all in ASM. There are a few notes:

1) I am sure that there are all sorts of instructions that don't need to be there. Some are from keeping things readable.. others are left over from testing and I didn't go through everything yet to get rid of wasted instructions.

2) The byteswap code still remains. These are only needed to convert little-endian to and from big-endian. It is only needed because different algorithms have different endianness internally and externally. The test vector files included were created with a particular endianess in mind.. and to make sure that testing would show output the same way it shows up in the file.. there are byteswaps being done in the C test code as well as a little bit in the ASM. I will probably remove it from the ASM.. but I think I will leave it in the test file since you may get a different encryption value.. but you will get you original data back when you decrypt it with the program. It doesn't make sense to add unneeded instructions to stay with the choice someone made when they made the test vector files. So unless someone needs to be compliant with another piece of software that will encrypt of decrypt.. it does not matter what endianness you choose to pass the ASM data or keys. I will however document in a future version what endianness is used externally and internally for each of the algorithms.... read more

I wrote the Rijndael code a pretty long time ago and knew at the time that register pressure was making me move to and from memory too much. At the time I decided I would make a 64 bit version which would alleviate this.

Well... foolishly I looked at Brian Gladman's code and noticed how he avoided a lot of the moving to and from memory as well as avoiding some shifts and "and" instructions. Now his code is burned into my head and when I try to write my own optimization of this sort.. I keep finding myself relating it to his code.. I think this is a grey area of inspiration vs. stealing code.. so I think I will leave the code as is.
The initial impetus for this project was a decently clean bit of assembly that would allow a beginner to play with ASM and learn about the algorithms. If I use an optimization like Brian Gladman's:... read more

I made a release that will allow people to compile the code under windows. I also included executables so people can play with it if they don't want to compile.

I decided not to add a binary for unix-like OSs because I am running under OpenBSD and I am not sure if my executable would run under Linux for example. I know that some systems have binary emulation and there are programs that can be used to change the "magic numbers" but I don't plan to deal with that. It is pretty straight forward to compile on any system that has GCC and NASM.... read more

Today I used nasm to output a win32 object file. Using the command line compiler that comes with Visual Studio.. I was able to like a C test program with the ASM object and get it to work under windows. I will probably include this information in the readme files in the next release.
For anyone that wants to do it themselves.. you need to rename the global functions in the ASM file to have a single underscore in front of them. This is needed by the MS linker. Then you have the same test program but running under Windows.

I just made a new release version 0.96

I went back through the code for twofish and saw that I was reading a register that no longer was needed many times. I also decided to go ahead and change some mov instructions to movzx in Rijndael and Twofish. These changes gave a slight increase in speed.. but not an extremely noticeable one..unless you are encrypting very large files.

I originally was not going to use the movzx instruction because it makes the code slightly less readable to a beginner. I decided however that I would use it in some places where the gist of the code could be gotten once someone understands the purpose of the instruction. I did not decide to change the ordering of Rijndael (like in Brian Gladman's code) because it makes the readability of the algorithm a bit trickier.. although it is definitely faster to do so.... read more

Twofish encryption and decryption were added. These are now part of AESx86-0.95.

I made a big leap in version numbers. It seems once I have the three algorithms implemented.. I shouldn't be back at 0.09. So I think I will move it to 1.0 when I have completed the following:

1) Remove borrowed C code from Rijndael and Serpent for key expansion. Do it all in the ASM files.

2) Clean up the code.. right now there are plenty of comments laying around that were notes to myself or, in Rijndael's case, written a long time ago and out of sync with the code.... read more

AESx86-0.08.tgz fixes the bug.

The bug was happening because of the way I was reading in the hex from the known value tests. scanf when used with %x reads integers into the given pointer. Since I was writing into a char array.. it was actually writing an extra three bytes. As writing got closer to the bound of the array, it was writing into the stack. When I wrote the Rijndael code.. I gave the "data" array a larger amount of space that was needed. Because of this, I had never noticed this issue.. it would just write into the "junk" area of my array. An interesting thing also happened when writing the "key" array. It was writing into my "data" array.. but since I filled in the "data" array after.. it would write over these false values.... read more

I completed Serpent decrypt.. however I found a bug in the way I read hex strings in Rijndael. Right now.. it is running up into the stack and overwriting data. On my machine.. I didn't see this because I gave an extra 4 bytes for the data array (an int).

This also brings up an issue of how data will be read in. Little-endian vs. Big-endian will be a trick and it seems that there is a slight performance loss by having to convert... will have to think about this one..... read more

I just finished the ASM for Serpent encryption. I should be able to finish decryption this week. I will then clean the code and the files up and make a new release.

After that.. I think I am going to take a good break before I tackle Twofish.

I created this project for the following reasons:

1) Learning about x86 assembly - I have been a C programmer for a while now and learned much about the low level workings of computers in college. All of this knowledge of low level computing was theoretical and it seemed quite difficult to use it practically. After researching it for a while, I found a nice way to compile ASM object files into C programs. This allows the learning programmer to forget about details that they are not focusing on. For example.. you don't have to call interrupts to do simple things like printing information to the screen or reading data from files. I figured this would be nice to share with others interested in playing around with ASM.... read more