Skip to content


Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP


AES-NI support should be compiled always and only used on machines which support it #19

nakedible opened this Issue · 5 comments

2 participants


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.

@vincenthz vincenthz closed this

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.