I've finished my AES library, it works fine and passes all test vectors I have tried (some from NESSIE too). I only needed AES-256 for personal use, so I didn't include AES-128 or AES-192. They can be added later if I need them, or by request.

I plan to use this library in combination with SHA-256 for my use, the code can be optimized for instruction sizes (maybe using registers instead of memory constants) for a small increase in speed, but I have not done this.

I would love if people would test this library, included is a small exe to run each of the functions. The results (place a breakpoint after decryption) should be 0x11223344 (and so on..), the same value as stored in memory close by.

Finally, for anyone wanting to run this code, I used the environment var %fasm%, which should be changed to whatever you have set. It is for little-endian processors.

Please give feedback, this is my first ASM project!

Can someone please tell me how my code is working for you?!

I can't find your code

Edit:
sorry, i saw it when i logged in.
Edit2:
I use Linux

Have patience, because not many people here use encryption of this type. Given a few months I expect someone will find it useful for a project they are working on.

Someone named "ic2" in another thread, "forward referencing" may have a use for it, and next week I have the enitire week off. by the end of this week I will post my corresponding SHA-256 code, it's up and running now but I have found a lot to work on.

It should be around the beginning of April that I will then post my AES multiple-mode library, using all three key sizes of AES and OFB, CFB, and CBC modes (did I spell right?). It will be a very fun learning (crash learning) experience. As for now, I'm having fun with SHA all over again

PS: As for the IV (initilization vector) for encryption, do you think I should use Window's CryptGenRandom, a personal implementation of a PRNG, or something else? I've also seen TrueCrypt use a combination of CryptGenRandom (twice a second), mouse-movement in a window (like PGP) repeatedly to generate keys/IV's.

Thanks, I'll keep checking back to see how you're doing with your project, and meanwhile my list of what to learn is still going, like:

1) Encryption modes (implementation)
2) MDS Matrices
3) PRNG's

So I should have a good time over here, and for anyone wishing to use my AES code please hold off, by the end of next week or so I will have a great AES all-key sizes with OFB,EFB, and CBC modes of operation to use all in one fantastic library. Thanks again, see you later.

PS: I you ever need help with debugging or ideas you are trying to work with, I will probably be able to help, just email me and I can help you, I check mail every morning.

Actual post below, managed to annoy the mysql parser by using single quotes in the file descriptions (sorry )

Great stuff, grabbed it along with your SHA code, and decided to convert it to work under linux. I'll post the linux version of it here, i know its in the wrong forum section, but would rather keep it under your topic, rather than start a new one.

Not much needed changed, the core of the code is the same, the differences are just in the way it gets interfaced mainly. One thing.. this code is not for creating a shared library under linux (.so), i looked into it, but the problem is that for a shared library, the code would have to be made completely PIC (Position Independent), which would mean having to keep one register with the address of the GOT, and adding rva to every address access. So what i did was, simply make it a ELF format, (static library if you will), to create a working binary using the AES.asm and AESDriver.asm (a modified version of the one above, it prints out the data in hex to check that the enc/dec is actually working properly), simply execute:



youll need the $fasm environment variable set to point to the location of the includes, because this code makes use of the struct.inc file, you can do that either by doing: (bash-specific)

or a more general way, replace the first line in the instructions above to:


(all the files/directories in the include dir will also have to be in lowercase (i believe the INCLUDE dir and all its sub-folders/files are in upper case in the fasmw.zip distribution))

This will create a 32-bit binary, although the binary will also work on a 64-bit machine (with 64-bit kernel, which is my current setup, and is why i have the -m elf_i386, its to force it to create a 32-bit binary, otherwise the default is a 64-bit one).

Oh, one last thing.. I had to make aes_init public (as AES_Init), and it must be called (with no parameters), before any other function is called, this is because its now a simple binary rather than an actual library, and therefore doesnt have (as far as i know) a "init" section which will be called when the binary starts up (I tried .init, but it didnt seem to work).

final final note: I havent updated/modified any of the comments, so what they say, and what the code actually does may vary, but its mainly things like "fasm PE file headers" not being changed to "fasm ELF file headers" and section names.

Still, I'm so glad that I can now port my projects to ELF. I guess I'll post a short description of my next library here, might as well:

1) Full AES library, all 128,192,256 key sizes, 128-bit (16 byte) block size
2) Actual implementation in FIVE different encryption modes:

; ECB {Electronic Codebook Mode}
; CBC {Cipher Block Chaining Mode}
; CFB {Cipher Feedback Mode}
; OFB {Output Feedback Mode}
; CTR {Counter Mode}

3) Code-size reduction (because of all that is included, I decided to not have user-defined code reduction constants for unrolling loops, including functions, ect..

4) Just plain beautiful-working code. Will be ported to ELF format (with help of GunBlade . )

Today I hope to have the encryption key schedule up and running, for speed help I've decided to have three different encryption schedules for the key sizes. (This is because of the AES-192, it has a small difference that requires special handling in the middle of a speed-intensive loop)

With the help of anyone interested in AES, I would love to get this done in a matter of two or three weeks. If you would like the intermediate code, all you have to do is contact AlexPatterson@hasd.org I would be happy to give you whatever it looks like at the moment for inspection or help.

[edit] For anyone who wants to use my code, for the encryption key schedules (algo that has three different structures for expanding a few bytes), do you think I should use:

1) Fast, but medium-sized seperated 3 loops
2) Slow, but smaller one loop
3) Medium, but okay-sized two in one, then one seperate

So far I'll make three seperate functions for expanding the keys, just makes it easier and faster.

The way you provide it now, with an option to unroll the loops which can be disabled or enabled is nice, that way it can be assembled to suit the purpose, whether the person wants speed, or size.

Also, updated the code above, and the one in the SHA post to contain if defined SYS_LIN around all linux-specific code, should make it easy for you to just copy paste that stuff into your own code, and add an else clause.

Could you make me a cup of tea with that? Thanks, I'm having a good 'ole time over here with the key schedules, decided to do a medium-unroll (only 4 more instructions) that will clean up 6 other conditional instructions for every iteration, plus it cut the iterations from 44 to 11. I'm getting the bugs out now, should be great by tonight (all-nighter just for you GunBlade).

[edit]: PS, I will definitely make every (feasibly) possible code-size and speed option that I can make available to the user, including the stosd instruction, which I did here:

Should work fine for some sor of a VOID_STOSD constant.

[edit2]: I saw in other great people's implementations that they had things to cut memory too, for example the tables are all just rotations of each other, so with a few more instructions in the encryption/decryption/schedules the memory can be cut back about 9*256*4 bytes or so.

Again Alex, its really impressive work, and for choice of speed over size, personally, i would go for speed, since this is code thats going to be used on (modern) x86 machines, so that means plenty of ram (especially relative to the actual binary size of your library), so might as well aim for speed.

I did a quick test the other day, using the AES code under linux to do encryption of a 100MB file and saved to another file, it came out at about 3.7MB/s.. although that is probably slower than your implementation can actually achieve, since that test imposes File I/O overheads. Will have to code up a small memory -> memory encryption test, about 100mb or so, and see how fast it does it.

The implementation I had actually was not about speed, I would have used registers instead. It was just a solid memory-usage thing just to get it running, and in this project I'm going to make it as fast as I can (and keep at it, as long as I can remember to).

I need your opinion on this, how should I format my encryption schedules?

1) Have them all in one (slowest), but smallest
2) Have the 128 and 256 in one, then 192 special (okay, few more code bytes)
3) Have them all seperate (fastest, but more code)

I have them all running fine right now, all seperate. I tried to smaller opcodes, I only used three hard-coded addresses with the looped version, but could use only one if I wanted. I'm really wondering how I should format them, though. Do you still think I should choose speed over a few dozen more bytes?

[edit] The largest of the schedules, 256-bit, uses 179 bytes of code. Could be smaller through several ways, but this is the smallest I would like it while still being fast, but not unrolled.

The way i see it, I think you should keep it as three separate functions. Sure, it takes a bit more space, but like you said, 179 bytes for the AES-256.. That's nothing on any half decent machine (thats nothing even on embedded microprocessors). Sure, the smaller you can get it, the better, but personally, I would aim more for speed, even if it means larger code sections (up to a limit of course, but you are nowhere near that size limit).

So be it, but what about when I have all 15 functions together?! If you would like the code to look at, I'll send it to you. ( or just post it). It'll help explain what I'm trying to do with the schedules.

It would be interesting to see the state of the code, if you dont mind posting it. And yes, thats one downside of using the seperate-functions method, is that youll end up with a lot of code, making it harder to manage. Depends on whether you want to have to deal with all that code, or prefer a smaller tidier version, but at the cost of speed

Halfway AES code, only encryption key schedules and IV gen code running seperate

You'll have to port to Linux, I still need to check how to do that again...

Speed tests show it encrypts and decrypts pretty damn fast, tried to compare against the openssl timings, but they do the benchmark a different way (number of operations in a set time (3 seconds), where as i did how fast would it take to encrypt a certain amount of data). I was able to do rough calculations to convert between my results and the openssl ones, and it came out to be about 60% the speed, which is really good, (especially seeing as you are one person, and your code has not been around for long, compared to openssl's time in production).

I was thinking, is there a way you could use MMX/SSE to improve the speed of some of those calculations? If it could be put to good use, it should help the speed quite a bit, the only downside would be that you would lose support with any processor which did not have those instructions (or you could use a if defined again to allow them to be enabled/disabled, so you could either use SSE or the older instructions if the cpu doesnt support it)

In due time I will have the project hold many different goodies.

1) Full support for the five FIPS modes of operation (working on it)
2) SSE optimized routines
3) 8-bit and 16-bit versions
4) Small-memory version (codename TINY)