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>
While Haskell mitigates or eliminates some classes of bugs common in C (such as buffer overflow), it also makes it more difficult to guard against side-channel attacks like timing attacks[0], because lazy evaluation makes it more difficult to reason about the actual behavior of the code at runtime.<p>This isn't a dig at either Haskell or C; the point is that all programming languages and environments have their "gotcha!" moments.<p>[0] <a href="https://en.wikipedia.org/wiki/Timing_attack" rel="nofollow">https://en.wikipedia.org/wiki/Timing_attack</a>
Possibly more interesting is a machine checked implementation.<p><a href="http://www.mitls.org/wsgi" rel="nofollow">http://www.mitls.org/wsgi</a>
This seems interesting.<p>I'm completely ignorant about Haskell. I see there's some code in a "Benchmarks" folder; I think it would be highly interesting to see a comparison in speed between OpenSSL's SSL implementation and this one (the operations that a web server would normally have to do).<p>Can anyone make that happen? I can't even figure out how to execute Haskell code in Ubuntu 13.04.<p>Seems to me like if the code base is 20 times smaller than OpenSSL, <i>and</i> we can assess whether timing attacks are present or not -- and if they are, replace the timing critical code with C code, perhaps -- that this would be a real alternative to OpenSSL. Am I being unrealistic in thinking this? Not that everyone will adopt it, mind you, but that adopting it would be a wise thing to do?
If you're curious (like I was) if anything else in the Haskell ecosystem is using this, this page lists packages that have dependencies on tls in Hackage (the Haskell package repository). There are 26 packages that depend on tls.<p><a href="http://packdeps.haskellers.com/reverse/tls" rel="nofollow">http://packdeps.haskellers.com/reverse/tls</a><p>Meanwhile, HsOpenSSL (Haskell bindings for OpenSSL) has 22 dependencies:<p><a href="http://packdeps.haskellers.com/reverse/HsOpenSSL" rel="nofollow">http://packdeps.haskellers.com/reverse/HsOpenSSL</a>
Nice and everything, but I somehow cannot imagine people massively jump over it. Maybe it's superstitious, I dunno…<p>On the other hand, I undoubtedly agree that we should start making and deploying alternatives in more safe modern languages. In fact, I guess we should start step-by-step rewriting <i>everything</i> that's written in C/C++ and OpenSSL is a good thing to start with.<p>I guess it's a good chance for Rust & friends.
The response to a subtle weakness in cryptographic software should not be to reimplement the cryptographic implementation from scratch. This inevitably introduces far more problems than it solves.
TLS implementation in Go. <a href="http://golang.org/pkg/crypto/tls/" rel="nofollow">http://golang.org/pkg/crypto/tls/</a><p>Go is probably better at this.
Totally off topic, but programmers, I REALLY need your help...
<a href="https://news.ycombinator.com/item?id=7559067" rel="nofollow">https://news.ycombinator.com/item?id=7559067</a>