On 07/02/15 18:53, Patrick Mylund Nielsen wrote:

(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.)

https://hackage.haskell.org/package/securemem

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.

https://hackage.haskell.org/package/tls

Am Sat, 7 Feb 2015 11:53:42 -0500 schrieb Patrick Mylund Nielsen:

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.)

I feel prompted to add something in here, since I'm working on this as the author of hecc[0]. My published basic implementation of elliptic curve cryptography contains the basic math for the so-called NIST-curves[1] in a best-effort timing-attack resistant way, which I will try to explain here. I will try to make my own experiences into simple guidelines this way, so it might be a bit long-ish. There are numerous ways to see different execution times depending on the bits of the secret key, each of which has to be fixed. First of all, if there is a branch in your code, a construct like if secretkeybit == True then do_something else do_nothing is way too easy to attack. (1) All your branches need to have exactly the same execution times. If you implement RSA or ECC, there will at some point be a square-and-multiply or double-and-add equivalent. A good fix for this is the Montgomery's Ladder, which has the property of juggling both branches in its parameters. In theory, this will leave no timing channel since both branch-parameters will be executed (I learned: {-# LANGUAGE BangPatterns #-} is very helpful here). (2) All branches need to be really executed. Sadly, this is not sufficient in a lazy evaluation environment like Haskell - or any other language which permits the compiler to optimize computations away (I agree: There be dragons if you really want to be compiler-safe in C! ;-)). I found out that special patterns in a secret key can lead a lazy Montgomery Ladder to faster execution times in Haskell, which I will try to explain in a proper paper in detail, time permitting. There are malicious little things in modern CPUs called "caches", which make some executed code quite a bit faster. In company with the branch prediction unit, branches based on bits of the secret key become very volatile, so the best defense is (3) No branches based on the content of bits of the secret key. This point is very hard to do when implementing the NIST-curves for TLS, my own code is not yet made in this fashion. Also currently, most people use Integer-gmp, which is of course based on gmp, which got timing-attack resistant (slower) implementations of methods in its version 6 release, so every one before that may be insecure when regarding timing attacks. This is not a deal-breaker, since other libraries in other languages also depend on gmp, like nocrypto[2] for Mirage OS and GNUTLS. I am currently fixing my new Ed25519/EdDSA implementation in pure Haskell (please don't confuse it with the fully functioning and fast C-wrapper one [3]), which is branch-free per point (3) and should be an example of code under such a rule. Right now I am not sure when the code will be ready for public scrutiny, but it should at least be implementation-secure and correct, being fast can follow later. This release will also feature a rework of hecc and a name-change, since the possible confusion with Hyper-Elliptic Curve Cryptography. Please note: I am currently searching a (paid) position as (preferably) phd student. I like working on functional programming, provabilty and cryptography. If you or anyone you know has interest in having me working for them, please contact me! Best of wishes, Marcel Fourné [0]:https://hackage.haskell.org/package/hecc [1]:http://csrc.nist.gov/groups/ST/toolkit/documents/dss/NISTReCur.pdf [2]:https://github.com/mirleft/ocaml-nocrypto [3]:https://hackage.haskell.org/package/ed25519

Another path worth investigating would be to construct a Haskell (e)DSL which produces C code, but adds better constraints and guarantees through Haskell's type system, a bit like what people are already doing for embedded systems On Feb 16, 2015 12:34 PM, "Yitzchak Gale" wrote:

Julian Ospald 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.

At Galois they have done a lot of work on this during the past few years. Of course, the good points brought up by Patrick have been prominent in their thinking.

I'm not sure how much of that work is available publicly. But they did open-source Cryptol, their Haskell-based DSL for designing and testing crypto algorithms.

http://galois.com/ http://cryptol.net/

Regards, Yitz _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe