On Sat, Feb 7, 2015 at 8:53 AM, Patrick Mylund Nielsen <haskell@patrickmylund.com> wrote:
On Sat, Feb 7, 2015 at 11:21 AM, Julian Ospald <hasufell@posteo.de> wrote:
I've been wondering about the state of cryptography in haskell. Not so
much in the sense of "what libraries are out there?", but rather about
the question what crpyto and IT security people think about ideas like
rewriting something as OpenSSL in haskell. 
 
I know it can be technically done, but are there any remarks in this
area that are important for practical security?

It's an interesting exercise (at least implementing TLSv1.2+) One thing to remember, though, is that a lot of the issues with OpenSSL aren't solved by having memory safety or isolation of effects: downgrade attacks, mac-then-encrypt instead of encrypt-then-mac, Heartbleed, etc.

In other words, Haskell eliminates several classes of errors, but doesn't prevent logic errors, and can do nothing about poor standards.

Aside from this, I think the main issues would be:

  - Timing resistance: This is not as simple as sprinkling some bitwise operations on your crypto code. It took a long time to figure out even the basics in OpenSSL, and for better and worse it's more difficult to intuit what your Haskell code will be compiled to than it is with C (though C compilers have been known to optimize away constant-time code.)

  - Usability: C is easy to embed in any program written in any language. Haskell, not so much. If nobody is using your library, it doesn't matter if it's the safest TLS implementation in the world!


TLS contains numerous design errors that we all have to live with like "mac then encrypt" which we have to deal with through incredibly "careful" implementation. It would be an interesting research project to try to understand if laziness is a benefit or a challenge when working with flawed protocol designs that known to vulnerable to timing oracle attacks.

The Open Mirage project which uses an OCAML unikernel architecture makes a strong case for putting security critical parts of an applications stack in a virtualized type safe container.

Haskell seems like it offers the strongest properties when demonstrating a good design is implemented as intended. It isn't likely to have any magic properties for protect against poor design.




 
(Another small issue is that it's not easy to erase something, e.g. a private key, from memory in Haskell, so they may stick around for some time. This isn't a big deal as long as your application's memory isn't swapped to disk.)

From a high-level security perspective, libressl offers the most hope in the short-term, and it's possible that e.g. a Rust (which at least is a lot like Haskell, but without a runtime!) TLS implementation could replace OpenSSL in a lot of existing applications in the longer-term. But because of the complexity of TLS and the possibility of logic errors, it's not a sure thing that implementations in Rust, Haskell, or what have you, would be more, or even equally as safe as something like libressl.

That being said, if you're thinking about doing something like this, go for it! Implementing TLS is fun (as long as you don't try to reach compatibility with anything but recent clients,) and it might be useful for other Haskellers.

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe