My latest project has been finished, and I would love to share it with the FASM community. It is an AES (Advanced Encryption Standard) implementation, all key sizes supported (128,192,and 256-bit), and may be used as either a Win32 DLL or a Linux linkable object file.

I would love for people to test the code under different platforms and report how it went. Under the Win32 version you only need to run the /BIN/Driver.exe program which will report if the code is working or not. (It does full tests on all functions). The Linux code requires linking, which is described in detail in the Linux version's Driver.asm comment headers.

Please not that both versions should (not checked) be able to run under 64-bit Windows or Linux machines.

If you would like to contact me, please either PM me here or send me an email at AlexPatterson@hasd.org and tell me how it works for your machine. I would be glad to help with any problems if it does not work on your system, or if you would like to suggest changes.

If you are going to use the code, feel free to do with it as you wish but please respect the license. If you do, please contact me as I would love to hear someone making use of it in their programs!

Please read the comment headers, as most parameters are passed in specific registers. Thanks!


Benchmark:

On a loaded down Windows Vista (around 995 threads running), with a 1.43 Ghz Pentium.

- Encryption / Decryption (same timings for both)

128-bit: 103,225,906 bytes / second
192-bit: 86,486,487 bytes / second
256-bit: 75,294,118 bytes / second

News:
- Linux driver program has been added (Thanks to gunblade!)
- A major bug in the Linux version has been fixed (Writing data to the code section isn't allowed in Linux)
- No versions write to the code page anymore, due to a very cycle-expensive code flushing reported by edfed.

May I have some feedback please? What did the Win32 example say to you if you ran it?

win32 example:


he he. this is a feedback.

platfrom: win98 first edition in a OMNIBOOK XE3.

? What the heck happened there? Well, may I know where in the driver the code faulted?

I have downloaded your work, and it is looking great...

But personaly, to really help you to find a bug, I would need those few steps:
- 1. Read some documentation about the algorithm
- 2. Code the algorithm with a "ALGORITHM ORIENTED" language, like Pascal or even Basic for Word.
- 3. Translate the slow "Basic for Word" algorithm to algorithm for FASM assembler, keeping EXACTLY the same comments than would help with the slow "Basic for Word" algorithm.
-4. Remove the same comments if you wish this program to appear as done by very quick and strong coder.

I'm sorry, but if you don't use multi-language programming and translations keeping the same comments, some bugs with this algorithm could stay forever until a team becomes addict with multi-language programming rules...

So, do the example programs report success? I have only gotten feedback from two people as to how it works, I would love to know if it is working for anybody who tried it.

edfed: I think the reason that the code faulted for you is because under newer Windows systems it allows writing to the .code section, I changed it under the Linux distribution but I'm not sure what Windows '98 allows.

If you qualified "newer" with "from Microsoft" then you'd be right. Unfortunately, allowing people to write to the code segment sets them up for failure as Intel/AMD have made changes that mean that writing to a code page flushes the code cache, inducing upwards of 100 cycle penalties every time it's done.

RX-only the code segment also provides another layer on the cake of partially effective security measures that keeps the hacking/reversing industry employed against the security industry.

Thanks, but I only wrote to the code section in the schedule. I looped it anyway, it was made to be slow. I wanted to keep the .udata section only uninitialized data, but unfortunately it seems I can't do this... I'll edit the code and place it in the (beginning) of the .udata section.

if you want to write a sort of self modifiable code... first, include the notion of FILE in your code.

the code segment will be a file.

copy the code file in a data segment.
then, you can overwrite the instructions (datas) without any problem. and to run the modified code, to make it safe, wait an user's event and then, copy this data file to a new code file and dispaly a message of copying in progress. then, call this code (don't forget to put a ret instruction at the end of the new code file).

as self modifying code is illegal (not forbidden!) make it only for tests and prototyping.

before to be a code, the datas are always assumed as datas. it's only when you load a segment with the base of this file that it becomes a code.

It's not a self-modifying code, it is just a dword of data located in the code section.

it is self modifying code.
intel qualify the modification of datas in code sections as self modifying code.
i didn't invent this.

then, if you want to modify a data in a code section (segment, file), assign a data segment to this area.

Okay, I will change it so it is located in the .udata section when I get the chance.

Well, if you didn't hear, "It broke!" then assume it's fine.

P.S. Worked fine on Win XP Home SP2 (Pentium 4 "Northwood" 2.53 Ghz: family F model 2 revision 4) w/ 512 MB RAM. What computers do you suspect it won't work on??

Naw, Edfed reported something bad. Thanks a lot for testing it guys, well, if it does break then tell me! . Please list here what OS/processors it works on also, I am curious to know

edfed, try this:

http://x86.neostrada.pl/KernelEx/

Hmm, if you mean the Windows API, my AES code uses no API calls.

thanks rugxulo, but i cannot risk to corrupt 98 more that it nativelly is.
i can't imagine what would happen to my mind if i crash my PC one more time.

maybe i'll try it in a long time, but for now... i prefer to not risk anything.
i'll contact the autor before.


AlexP:
amybe your code is to much macroed...
macro programming is not assembly programming. i rarelly use macro. and tend to never use tham as i always find short ways in asm..

for exemple:

to convert ascii in binary, we can use macro, but no, i use function (not proc).
fasm is Flat Assembler ... FLAT as it will generate a Flat binary exactlly as it is in the source code.
macro is a derivation i don't find OK for many reason.

i can try again your code... but before , i will learn more about AES -i don't know what iit is at all ) and maybe try to code my own vision of the code if i find it is interresting.. inspirating from you code of course

I use macros to make it more structured and readable, not including if you have repeated code like me . In my code, it showed the techniques for encryption. Without it, it would be ALOT more confusing to understand my techniques.

I believe that if you can have a good executable, along with a smaller source that allows things to be understood easily, you're hitting two birds with one stone .

Edfed: Okay, please do NOT use my code as a starting point to learn AES. I coded one myself, in full function form (without the lookup tables), and it went slow but it worked. Doing this, along with learning the math behind the AES help me aloT! I would suggest this:

1) Print off a copy of FIPS 197 and keep it as a bible to you. Memorize it, mess around with converting binary to polynomials and such techniques,.

2) Learn properties of the finite field 2^256

3) Implement the AES in full function form. (AKA with SubBytes,MixColumns,ShiftRows, ect...)

4) I spent a lot of time working with the key schedule, because it is the only thing that makes the AES secure. Implement it in different ways, in three functions for each bit size, in one loop like I have above (the 'setz' idea for the middle loop was from Revolution), and just keep toying with it.

5) Learn what the lookup tables are for! (It's in the 'Rijndael Proposal'. google it. Should be near end, it's simple in concept and in implementation (The table generation code provided by Revolution in my version above).

6) Try using different techniques. Just ask and I will give you the collection of other people's implementations I have sitting here. The most popular I've seen is the SHR/AND/XOR, which is quite slow due to the memory usage/ copying the state array every time.

7) It took me several weeks to learn how to do what I did in my code. I'll teach you if you want, or at least get you started. I highly doubt it'll click in your mind without help from someone who's done it.

Have fun learning AES if you decide to!