Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

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

Closed
nakedible opened this Issue · 5 comments

2 participants

@nakedible

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).

@vincenthz
Owner

please use cipher-aes which does exactly this. I consider cryptocipher AES implementation's deprecated.

@vincenthz vincenthz closed this
@nakedible
@nakedible

Heh, you seem to have written that, too. I wonder what to make of that :-)

@vincenthz
Owner

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).

@nakedible

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.