<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Feb 7, 2015 at 11:21 AM, Julian Ospald <span dir="ltr"><<a href="mailto:hasufell@posteo.de" target="_blank">hasufell@posteo.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">I've been wondering about the state of cryptography in haskell. Not so<br>
much in the sense of "what libraries are out there?", but rather about<br>
the question what crpyto and IT security people think about ideas like<br>
rewriting something as OpenSSL in haskell. </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> <br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
I know it can be technically done, but are there any remarks in this<br>
area that are important for practical security?<br></blockquote><div><br></div><div>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.</div><div><br></div><div>In other words, Haskell eliminates several classes of errors, but doesn't prevent logic errors, and can do nothing about poor standards.</div><div><br></div><div>Aside from this, I think the main issues would be:</div><div><br></div><div>  - 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.)</div><div><br></div><div>  - 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!</div><div><br></div><div>(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.)</div><div><br></div><div>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.</div><div><br></div><div>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.</div></div></div></div>