Hey Fred,
I haven't gotten the time to look at this code thoroughly, but I just
wanted to say (before too much time passes) that I'm pleased to see an
optimized version come out of the woodwork. I'm unfamiliar with all the
ways that AES gets optimized in the wild, so porting a project's actual
implementation is really interesting. I look forward to reading your code
more carefully.
> All of this may turn out to be just an academic exercise on my part. ;-)
Well, strictly speaking I assume implementing crypto on your own (even
existing algorithms) is usually an academic exercise regardless, unless
you're an expert cryptographer working on an established crypto library.
Cf.
http://web.archive.org/web/20130121031415/http://chargen.matasano.com/chargen/2009/7/22/if-youre-typing-the-letters-a-e-s-into-your-code-youre-doing.html
Doesn't mean it's not fun. :)
Regards,
--Alex Vondrak
On Sun, Jun 16, 2013 at 10:32 AM, Fred Alger <f...@fredalger.net> wrote:
> Oh my, this is what I get for not reading the Factor mailing list.
>
> I've done my own independent implementation of crypto.aes:
> https://github.com/phred/factor/tree/implement-aes
>
> It's based on the original, which used 7zip's infuriatingly optimized C
> implementation as a reference. It uses 32-bit integer arithmetic and
> lookup tables for encrypt and decrypt.
>
> Reading through the smart commentary in this thread, I've already found
> some cleanup to do. I'd also like to benchmark my code.
>
>
> All of this may turn out to be just an academic exercise on my part. ;-)
>
> I actually find Gabriel's "pure" implementation much more aesthetically
> pleasing than my own. Lookup tables muddy the code's readability, and feel
> more like "hey, I'm shoehorning C into Factor" than an elegant expression
> of the core AES algorithms. Adding OpenSSL bindings also limits the
> utility of a "pure Factor" optimized lookup-table implementation (unless we
> can get close to OpenSSL's numbers, that'd be wicked!)
>
> So pleased to see that the community's chugging along! It will be nice to
> have a working crypto.aes implementation in the core. I don't wish to
> compete for submission to the project, nor step on anyone's toes.
>
> Some notes on my implementation:
> ---
> I used HOOKs to implement a generic AES "crypt" algorithm, which to me
> seems concise and elegant:
> : (aes-crypt) ( aes -- aes' )
> (first-round) [
> dup nrounds>> (counter)
> [ [ (do-round) ] dip add-round-key drop ] with each
> ] keep
> (final-round) ;
>
> aes-encrypt and aes-decrypt "strategies" provide their own implementations
> of the (first-round), (final-round), etc. words.
>
> I tried to use the '-unsafe' sequence words, inline, and unrolled-map
> wherever I could in the implementation. This was more of a sprinkling of
> "hey, that'd be good" rather than driven by hard benchmark numbers.
>
> Your feedback is most welcome. Thanks!
>
> --
> Fred Alger
> @_phred
>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> Factor-talk mailing list
> Factor-talk@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/factor-talk
>
>
------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk
