flat assembler
Message board for the users of flat assembler.

Index > Main > Multi-OS Advanced Encryption Standard (AES) Library

Author
Thread Post new topic Reply to topic
AlexP



Joined: 14 Nov 2007
Posts: 561
Location: Out the window. Yes, that one.
AlexP
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.


Description: Windows (slower than AES_Win32) C-compatible version. Uses stack for parameters & preserves cdecl registers (ebx,esi,edi,ebp).
Download
Filename: AES_Win32_C_Version.zip
Filesize: 7.28 KB
Downloaded: 169 Time(s)

Description: Windows 32-bit AES library and example usage program.
Download
Filename: AES_Win32.zip
Filesize: 8.92 KB
Downloaded: 208 Time(s)

Description: Linux 32-bit AES library and example usage program provided by gunblade.
Download
Filename: AES_Lin32.zip
Filesize: 8.68 KB
Downloaded: 170 Time(s)



Last edited by AlexP on 20 Apr 2008, 13:59; edited 9 times in total
Post 11 Apr 2008, 01:58
View user's profile Send private message Visit poster's website Reply with quote
AlexP



Joined: 14 Nov 2007
Posts: 561
Location: Out the window. Yes, that one.
AlexP
May I have some feedback please? What did the Win32 example say to you if you ran it?
Post 12 Apr 2008, 00:08
View user's profile Send private message Visit poster's website Reply with quote
edfed



Joined: 20 Feb 2006
Posts: 4240
Location: 2018
edfed
win32 example:
Code:
DRIVER cause a page fault in 
the module KERNEL32.DLL at 015f:bff7ddd5.
Registers :
EAX=00000000 CS=015f EIP=bff7ddd5 EFLGS=00010246
EBX=862aa90c SS=0167 ESP=0054fc38 EBP=d04257b8
ECX=2c3a1616 DS=0167 ESI=00410000 FS=3ff7
EDX=0000001e ES=0167 EDI=00000000 GS=0000
Bytes at CS : EIP :
89 45 e4 29 65 e0 03 65 e0 5f 5e 5b 83 7d e0 00 
Stack state :
00000000 00410000 862aa90c 862af790 862a8edc 862a8ef0 e8c1bc00 01673ff7 00010002 8b360000 8c58360f 0000360f 2e000000 3a438c8d 4e49575c 53574f44 
    


he he. this is a feedback.

platfrom: win98 first edition in a OMNIBOOK XE3.
Post 12 Apr 2008, 00:17
View user's profile Send private message Visit poster's website Reply with quote
AlexP



Joined: 14 Nov 2007
Posts: 561
Location: Out the window. Yes, that one.
AlexP
? What the heck happened there? Well, may I know where in the driver the code faulted?
Post 12 Apr 2008, 00:58
View user's profile Send private message Visit poster's website Reply with quote
Remy Vincent



Joined: 16 Sep 2005
Posts: 155
Location: France
Remy Vincent
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...
Post 12 Apr 2008, 02:08
View user's profile Send private message Visit poster's website Reply with quote
AlexP



Joined: 14 Nov 2007
Posts: 561
Location: Out the window. Yes, that one.
AlexP
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.
Post 13 Apr 2008, 19:35
View user's profile Send private message Visit poster's website Reply with quote
daniel.lewis



Joined: 28 Jan 2008
Posts: 92
daniel.lewis
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.

_________________
dd 0x90909090 ; problem solved.
Post 14 Apr 2008, 00:00
View user's profile Send private message Reply with quote
AlexP



Joined: 14 Nov 2007
Posts: 561
Location: Out the window. Yes, that one.
AlexP
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.
Post 14 Apr 2008, 01:29
View user's profile Send private message Visit poster's website Reply with quote
edfed



Joined: 20 Feb 2006
Posts: 4240
Location: 2018
edfed
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.
Post 14 Apr 2008, 01:49
View user's profile Send private message Visit poster's website Reply with quote
AlexP



Joined: 14 Nov 2007
Posts: 561
Location: Out the window. Yes, that one.
AlexP
It's not a self-modifying code, it is just a dword of data located in the code section.
Post 14 Apr 2008, 02:04
View user's profile Send private message Visit poster's website Reply with quote
edfed



Joined: 20 Feb 2006
Posts: 4240
Location: 2018
edfed
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.
Post 14 Apr 2008, 02:09
View user's profile Send private message Visit poster's website Reply with quote
AlexP



Joined: 14 Nov 2007
Posts: 561
Location: Out the window. Yes, that one.
AlexP
Smile Okay, I will change it so it is located in the .udata section when I get the chance.
Post 14 Apr 2008, 02:17
View user's profile Send private message Visit poster's website Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2341
Location: Usono (aka, USA)
rugxulo
AlexP wrote:
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.


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

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??
Post 14 Apr 2008, 21:06
View user's profile Send private message Visit poster's website Reply with quote
AlexP



Joined: 14 Nov 2007
Posts: 561
Location: Out the window. Yes, that one.
AlexP
Naw, Edfed reported something bad. Thanks a lot for testing it guys, well, if it does break then tell me! Smile. Please list here what OS/processors it works on also, I am curious to know
Post 14 Apr 2008, 23:08
View user's profile Send private message Visit poster's website Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2341
Location: Usono (aka, USA)
rugxulo
edfed, try this:

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

Quote:

The aim of the project is to implement functions (not present on Windows 98 / ME) to kernel32.dll and other system libraries so that recent Windows XP applications and games work on Windows 98 / ME.
Post 14 Apr 2008, 23:24
View user's profile Send private message Visit poster's website Reply with quote
AlexP



Joined: 14 Nov 2007
Posts: 561
Location: Out the window. Yes, that one.
AlexP
Hmm, if you mean the Windows API, my AES code uses no API calls.
Post 14 Apr 2008, 23:52
View user's profile Send private message Visit poster's website Reply with quote
edfed



Joined: 20 Feb 2006
Posts: 4240
Location: 2018
edfed
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.
Smile

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 Sad ) and maybe try to code my own vision of the code if i find it is interresting.. inspirating from you code of course Wink
Post 15 Apr 2008, 00:12
View user's profile Send private message Visit poster's website Reply with quote
AlexP



Joined: 14 Nov 2007
Posts: 561
Location: Out the window. Yes, that one.
AlexP
I use macros to make it more structured and readable, not including if you have repeated code like me Smile. 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 Smile.

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!
Post 15 Apr 2008, 20:45
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar. Also on YouTube, Twitter.

Website powered by rwasa.