word-based AES encryption/decryption algorithm

[mangui]

Hi folks, I re-implemented AES encryption/decryption using a word-based algorithm (instead of byte-based) I am using this new algorithm in my HLS player https://github.com/mangui/HLSprovider (that needs to support AES-128 decryption) now I can AES-128 CBC decrypt at 48 Mb/s on my Core-i5 2410M @2.30 GHz (with byte-based algo, I was around 2 Mb/s)

algorithm is derived from from https://code.google.com/p/crypto-js/source/browse/tags/3.1.2/src/aes.js code footprint is also smaller as the all the static arrays are built in static initializer (not hardcoded)

Feel free to merge, I am ok to stick with same license. Cheers, Mangui

[Neverbirth]

Nice contribution. Have you tried to make an alternative version using ASC2 Alchemy opcodes? back in the day made a quick hacked Haxe version, and the speed differences were very noticeables.

[mangui]

Hi, no i didn't try. Can this compiler be downloaded freely ?

On 26 févr. 2014, at 19:46, Neverbirth notifications@github.com wrote:

Nice contribution. Have you tried to make an alternative version using ASC2 Alchemy opcodes? back in the day made a quick hacked Haxe version, and the speed differences were very noticeables.

— Reply to this email directly or view it on GitHub.

[Neverbirth]

Yes, ASC 2 is freely available, it's been the default compiler in the AIR SDK for a few releases. Anyway, I've just seen you provided changes to use AZOTH? I guess the result would be the same, but people would not need to know about it. Although current code would compile using any compiler (even if slower if not later using AZOTH), and the new one would only work with ASC2.

EDIT: Although it was later removed, is it not possible to use the fast memory opcodes with the new method?

[makc]

if not later using AZOTH

I think you could just add trace()-s to azoth as3 headers or even throw exceptions there to prevent this.

[mangui]

Hi folks,

regarding azoth, let me just to recap the steps I followed: I first took the existing byte-based AESkey.as code and used fastmem.as from azoth see https://github.com/mangui/as3-crypto/commit/f7adb446a5a155d249ae21269cbdb5d256969e82 then compiled swc, extracted swf and run azoth.exe on top of it. this provided me a factor 2.5x performance improvement.

as it was not enough, I then rewrote AESkey.as using word based algorithm inspired by crypto-js. the performance improvement I got (from 2 Mb/s with vanilla as3crypto.swc to 48 Mb/s with word based) was by compiling with adobe flex 4.6 so no special opcode here. Also please note that these are not straight benchmarks. these are decryption benchmarks run in the context of HLSProvider. the numbers could be slightly different with straigth benchmarks, but definitely they should also show some decent improvements.

regarding alchemy opcode : I just downloaded latest AIR compiler, I see it provides a mxmlc command line wrapper, do you know if by just calling this wrapper, AIR compiler will output any ASC2 Alchemy opcodes ?

[Neverbirth]

a 2.5x improvement sounds like what I got back in the day with my hacked Haxe version. I wonder if you can use the Alchemy opcodes with this new version and get a ~90x improvement.

The ASC2 mxmlc wrapper is there for some backward compatibility support, it will support the Alchemy opcodes, but of course, it won't be able to compile down Flex applications. I wonder if the Apache Flex community is working on this for the Falcon compiler.

[makc]

@mangui,

regarding azoth

What I said was in reply to @Neverbirth

but people would not need to know about it.

So, to make them know, you could edit fastmem.as to be something like:

public static function fastSelectMem(mem:flash.utils.ByteArray):void {
            throw new Error('Yo! Run azoth.exe over this SWF.');
}

Edit: perhaps I misread what @Neverbirth was saying, seems like he actually sees the ability to run without azothifying SWF as +1. But, what's the point, if it is going to be slow.

[Neverbirth]

Didn't mean I'm valuing compiling without Azoth possitively, but that it is possible to at least compile any type of application with that method. I'd prefer native ASC2 Alchemy opcodes, but that would make Flex apps imposible to run (if trying to use the source code directly instead of the SWC, of course).

[mangui]

Hi folks, I recompiled with Flex 4.6 and latest Adobe Air compiler, then disassemble the main encryption/decryption loop see diff here : https://gist.github.com/mangui/9245374

I don't see significant difference. I didn't compare performance-wise but, with the new implementation most of the computation is performed using Vectors, stored as local variables. input/output ByteArray is just accessed at the beginning and at the end to extract back and forth the 16 bytes into 4 words. could this still benefit from other optimization using ASC2 Alchemy opcodes ? Cheers, Mangui