You can clone with
HTTPS or Subversion.
Currently, AES-NI support is enabled via a compilation flag. However, to get more usage to the code, and to make the life of package maintainers easeir, AES-NI support should always be compiled (when compilable). Usage of AES-NI instructions should be selected at runtime.
In its current state, cryptocipher package is next to useless if not compiled with AES-NI. The pure haskell implementation is roughly 100x slower, and 7x slower than a C implementation (on my machine, YMMV).
please use cipher-aes which does exactly this. I consider cryptocipher AES implementation's deprecated.
Heh, you seem to have written that, too. I wonder what to make of that :-)
well, the next branch of tls & tls-extra are already using cipher-aes instead of cryptocipher. I don't plan to backport it to the master branch, although anyone can pull the commit very easily to it. it will be the default only in tls 1.0 (which is the next branch).
Okay, good to hear! Hopefully tls 1.0 will arrive soon and be picked up by package maintainers, as it seems that both Network.HTTP.Conduit and Network.Wai.Handler.WarpTLS use your tls implementation, making the current state of HTTPS support in Haskell rather bleak.