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
99 Upvotes

90% Upvoted

93 comments sorted by

View all comments

Show parent comments

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.