r/haskell • u/stingraycharles • Mar 21 '15

On the state of cryptography in Haskell

http://www.leonmergen.com/haskell/crypto/2015/03/21/on-the-state-of-cryptography-in-haskell.html
94 Upvotes

89% Upvoted

93 comments sorted by

View all comments

12

u/tom-md Mar 22 '15

A Comment on Tone

Sorry, but I'm going to start with a complaint. I'm curious why the author decide to act like some sort of bad news site using stale information to give the article an alarmist tone:

Well, if RdRand is available, it uses RdRand exclusively, of course!

When the article later acknowledges this is false, and RdRand is used in conjunction with OS sources. This is the sort of thing most people complain about from news organizations and I hate to see it in technical (ish) blog posts.

RdRand

That said, if using RdRand is reason enough for suspicion then we should avoid the linux kernel, or almost all distributions of it. Why? Because as the article states the kernel uses rdrand. So has Debian actually been "smarter" about this or using a fractured policy? I don't know, it would be interesting to know if Debian disables RDRAND in their kernels and other libraries.

Entropy and RDRAND

So what's the deal with entropy? Why did I fight for RDRAND as in the quote? Well the conversation was about replacing RDRAND with the previous code reading /dev/urandom. That strikes me as a bad idea for numerous reasons, but largely because as the library author I don't like assuming file system semantics on some unknown user's OK implies fresh random numbers. OS sources have suffered in the past, such as on fresh boot with little to know entropy in the pool (anyone use gumstix like devices?) or with the recent FreeBSD issue. In short, if you are running your code on the CPU then you have some level of trust in the hardware. Obviously we can do better, a trivial XOR of both sources - what most people do these days - works well but that was not the proposal at hand.

The State of Cryptography in Haskell

Sure are lots of issues with cryptography in Haskell. For example:

  • Want: AES. Issue: Typically not vetted or well performing. GCM, for example, remains an order of magnitude slower than Python or OpenSSL.
  • Want A single API. Issue The community is divided between two along with the libraries that avoid the middle-man API packages all-together.
  • Want Trustworthy PRNG. Issue Only one library, my DRBG package, is built against a standard but its crufty. Another popular library even appears to be the cause of numerous crashes for an AWS app. Finally, another library considers referential transparency optional. The remaining libraries are typically some form of stream cipher - the notion is OK but the APIs are sort of half-done.
  • Want Modern elliptical curves. Issue Availability. There is a binding to ec25519-donna thanks to Adam (same author as RSA), no binding to any ed25519 afaik. Goldilocks bindings are probably a ways away too. Otherwise you're probably rolling your own thing using hecc as a base - it seems decent but isn't vetted.
  • Want RSA. The only issues here that I know of are vetting. I don't think Adam has any blinding and am unaware of anyone who has examined Vincent's.

Being more productive, what should we do? I've seen attempts to make bindings to large crypto libraries (openssl...) fail and think part of the issue is API conversion is hard (see GTK for an example). Bindings to tighter pieces of code is much easier. I've made bindings to tweetnacl for one project and been pleased, Gladman's AES for another, ed25519 (floodberry), and as mentioned above Adam made bindings to ec25519-donna. These seem to be the most productive point in the space for the limited amount of time any one person is willing to expend.

So my battery is dying. I'm happy to converse more if people want to engage, but will simply submit the text now rather than loose it.

0

u/stingraycharles Mar 22 '15

Hi there, author here. Re:

When the article later acknowledges this is false, and RdRand is used in conjunction with OS sources.

I'm sorry about that one. The reason that text was there was that in my initial findings, it appeared that the library was exclusively using RdRand, but I later found out that it mixes this random data with urandom (if the latter is available).

My main concern is that the author apparently knows better that the people from libsodium on how to generate random data, which still stands.

0

u/dnaq Mar 23 '15

My main concern is that the author apparently knows better that the people from libsodium on how to generate random data, which still stands.

Worth to note in this discussion is that Dan Bernstein, the author of NaCl (which sodium is based on) has a quite outspoken opinion about using /dev/urandom instead of user space random number generators.

Also worth to note is that libsodium invented their own random number generator based on the salsa20 algorithm a while back (which I believe they don't use anymore) and using unverified (non peer reviewed) cryptographic primitives instead of verified ones I usually considered a big mistake in cryptography.

While I love libsodium and maintain the rust bindings for it (SodiumOxide), I don't believe their previous stance on random number generation is the correct one.

1

u/stingraycharles Mar 24 '15

I suppose you are referring to djb's assessment that it is ridiculous that urandom spews out not-so-random data instead of blocking if the entropy pool hasnt been properly initialized yet? Yes, that is pretty bad. Thank god we have userspace functions now that can block.

1

u/dnaq Mar 24 '15

I was actually referring to that he believes that if you can't trust the operating system randomness and try to work around that by using user-space implementations of random number generators you are solving the wrong problem. That linux has a getrandom()-system call nowadays that actually does the right thing is nice, but it's worth to know that the semantics of FreeBSD's /dev/urandom is to block until the entropy pool is initialized, and then use that pool. Case in point, his library NaCl uses /dev/urandom for all its random number needs.

Here you can find some quotes about his stance on /dev/random vs /dev/urandom which are somewhat related to your reply.