[Haskell-cafe] cryptography in haskell

[zaki at manian.org]

On Sat, Feb 7, 2015 at 8:53 AM, Patrick Mylund Nielsen <
haskell at patrickmylund.com> wrote:

> 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!
>
>
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 at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20150207/2e768df2/attachment.html>