A number of people are suggesting that this Haskell implementation must be worse than OpenSSL. It probably is. Writing good crypto code is hard. There are probably bugs.<p>Many are saying that one problem with Haskell is that you can't eliminate side-channel attacks due to features of the language. I disagree. There is no common language better than Haskell at encoding invariants in the type system. One could, for example, implement a "biggishnum" library in Haskell using large but fixed size integers and constant-time operations.<p>Free monads are a powerful idea in Haskell[1]. They allow one to easily generalize "interpreters" over sequences of commands. In Haskell, more-so than any other language I've ever used, one can decouple execution from algorithm specification.<p>Free applicative functors generalize further[2]. They define a computational structure that must be fixed a priori. That is, by definition a free applicative functor cannot know the state of the data during its execution.<p>There are some problems with this. Applicative functors have an operation which can lift regular functions into it. That operation would have to be hidden, so that only a kernel was exposed that offered the ability to initialize data, and then perform computations upon it.<p>But it's possible to do this. It is actually not a radical idea to imagine this being done in Haskell. Making a library and a set of primitive operations <i>that can be used by an end user safely</i>, in provably constant time is possible.<p>[1] <a href="http://www.haskellforall.com/2012/06/you-could-have-invented-free-monads.html" rel="nofollow">http://www.haskellforall.com/2012/06/you-could-have-invented...</a>
[2] <a href="http://paolocapriotti.com/assets/applicative.pdf" rel="nofollow">http://paolocapriotti.com/assets/applicative.pdf</a>