Vincent uses gcc header files to get the AES instructions: Header files of: #include <wmmintrin.h> #include <tmmintrin.h> And later calls of: x = _mm_aesenc_si128(m, K1); But currently you must know you have AESNI and use a flag: cabal install cryptocipher -faesni But if you are wrong: Illegal instruction (core dumped) This is a great place to be - now we just take the CPU checking from intel-aes, make a switch between Vincent's C and Gladman (in haskell or out, I doesn't matter to me), graft on Ctr mode as specified then it's all about matching the current 'random' API. Cheers, Thomas On Fri, May 4, 2012 at 6:37 AM, Ryan Newton <rrnewton@gmail.com> wrote:
My end goal is to have the user use transparently the fastest implementation available to their architecture/cpu providing they use the high level module. I've uploaded the cpu package which allows me to detect at runtime the aes instruction (and the architecture), but i've been distracted in implementing fast galois field arithmetics for GCM and XTS mode (with AES).
Yes! A worthy goal!
I think the proposal here is that we do the build/integration work to get something good which is portable enough and install-reliable enough to replace 'random'. Then people who don't care will be using a good implementation by default.
That was my goal when I had my own small shot at this, but what I came up with was *very* build-fragile. (Depended on assembler being available, or on prebuilt binaries being included for that package.) You can see the Setup.hs customization I attempted to do in intel-aes to compensate, but it's not enough.
Can we write a cabal-compatible, really robust installer that will test the users system and always fall back rather than failing?
-Ryan
P.S. How are you doing the CPUID test for NI instructions? I used the *intel provided* test for this (in intel-aes) but I still had reports of incorrect identification on certain AMD CPUs...