[Haskell-cafe] cryptography in haskell

[Patrick Mylund Nielsen]

On Sat, Feb 7, 2015 at 11:21 AM, Julian Ospald <hasufell at 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!

(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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20150207/143d42ce/attachment.html>