RDRAND

[esoeylemez]

As far as I see in the source code, if the platform supports RDRAND, then RDRAND becomes the only entropy source. Since its trustworthiness has been questioned numerous times, I'd ask to make the regular system random number generator (like urandom) the preferred choice, as it most likely includes RDRAND already, but also mixes in some other sources and in such a way that a malicious RDRAND implementation could not erase the entropy pool.

[vincenthz]

you can disable RDRAND at compilation time with a cabal flag (with a handy support in stack to make it a project wide decision). Is this mechanism not enough ?

[esoeylemez]

In general the operating system's entropy source should be the default. At this point in the default setting all our entropy sources are ignored, and we rely on a completely opaque proprietary source that may or may not be trustworthy.

I ask to flip the order in supportedBackends, such that the OS pool is preferred. Again note that most operating systems include RDRAND in a trustworthy manner in their OS entropy pools anyway.

[vincenthz]

But what about the existing mechanism to disable it ?

[vincenthz]

linking to #13 for my preferred solution

[esoeylemez]

The existing mechanism does not quite do it: it disables RDRAND, which is not what I'm proposing. I'm proposing to keep it enabled, but as the second choice. Also Cabal flags can be awkward to use in certain deployment scenarios. For example if I change a flag in cryptonite with my Nix-based deployment system, I will effectively disable the binary cache for all packages that depend on cryptonite.

So these are really separate issues: this issue is about whether the default is a good idea, so it's more of a design/philosophy issue. I'd much prefer to make the system entropy pool the default for reasons explained earlier. If you agree, I'm happy to contribute the necessary code change.

[vincenthz]

aside from the rebuilding issue which is minor, moving it to be a second choice would prevent to be used at all: It's very unlikely that urandom would not have the requested amount of bytes.

The thing is, it's basically impossible to choose a default and make everyone happy here. So arguing to change the default is not going to go very far.

I can see two valid development path at the moment:

• go in the direction of cprng-aes and crypto-random replacement #13
• runtime override (environment variable, special configuration file ?)

[esoeylemez]

You present it as if it's a bad thing that urandom has the requested amount of bytes, but it is not. In fact it is a good thing! And this is not a question of community satisfaction, but of security and logic.

I have talked to a number of people about this issue, and the general consensus is clear: Do not use RDRAND. The OS entropy pool is more trustworthy and includes more sources (including RDRAND!), so using it as the default is just an absurd choice from a cryptographic and strategic standpoint. It has less sources, and the implementation is not available for review.

That makes the attitude of Haskell's crypto implementors very toxic. As much as I would prefer to shake some sense into you, the only valid and reasonable path at this point seems to be more community fragmentation: a new crypto library that favours tried and true over new and shiny.

[vincenthz]

sigh I'm not sure where to start ..

You're more than welcome to your view, but trying to impose them on everyone because "security and logic" is just a joke. I do not share your conspiracy views about RDRAND, and the "consensus" you're talking about is just in your head.

Regarding toxicity; what's toxic is someone barging in, trying to impose his short-sighted view on highly charged subject "security" claiming it's "the truth". Specially considering that I've been perfectly reasonable trying to find compromise for you. cryptonite already have a compile workaround, and I defined a way to have a runtime one, or/and a project one. And yet this is toxic ? what a freaking joke.

Good luck forking anything your want. bye.

[esoeylemez]

I made a simple strategic argument: single entropy source bad, closed-source entropy bad. RDRAND has no advantage over the OS PRNG (if you know one, I'm all ears!), but at least these two disadvantages. And now you're insulting me? And you won't even listen anymore? You're a major crypto maintainer, so to be honest, I expected more from you.

Was my tone heated? Of course, because I'm worried and angry, because we have no crypto library on Hackage that uses readily available entropy sources by default. And now I'm labelled the bad guy. Thank you.

I'm happy to discuss this further with you, if only to prevent the community fragmentation that would result, but the choice is yours.

[vincenthz]

Here's a list of advantage of RDRAND:

• system independent: works on windows, linux, osx, bsd, halVM, any VM system, random-OS, etc.
• more resilient to VM cloning (i.e. clone a VM, same entropy pool in both VM, possibly outputing same bytes in a short windows after cloning)
• it's faster than going through a syscall, being a user space cpu instruction it's extremely cheap to call (less cheap to execute, but still really fast).
• RDRAND is actually NIST SP 800-90A FIPS 140-2 compliant

Now when you're ready to have a real discussion that is more balanced (not angry, respect other PoVs, try to find a solution, etc), we'll (probably) be here.

[edom]

Sorry for necroing. This issue is indeed a serious one, but the reporter might have rubbed you the wrong way. Let me explain the gravity of this problem in a neutral tone:

The problem is: by allowing RDRAND to be used exclusively (or even at all), you are putting your 5,000 users (and also the users of other systems that use your library) at risk. Your users will think your library is secure by default whereas it is actually not. Lots of (and more) people are depending on this, and this library is putting every one of them at risk. Everything that uses this library is compromised.

I don't understand cryptography, but shouldn't a cryptographic library concern itself on being secure first before concerning itself with anything else, such as speed, portability, etc.? Shouldn't a cryptographic library be secure by default? What's the point of making a cryptographic library that's not secure? What's the point of making a software that is fast but does not satisfy its requirements? Shouldn't we make it as hard as possible for users to shoot themselves in the foot?

There are two solutions that will solve the problem:

1. Change the support_rdrand flag in cryptonite.cabal to Default: False. Your library becomes more secure by default, and I thank you for preventing bigger problems later down the road. (I think the original reporter was basically just asking you to make this one-line change, but I agree with you that the way he said it could be improved.)
2. If you won't do that, at least write about this security bug in the readme, and write a snippet to disable that flag for cabal/stack users.

I recommend the first option; it's less work but does more good.

Mixing RDRAND and other entropy sources is not a solution as it may be insecure. http://blog.cr.yp.to/20140205-entropy.html

See also the Linux and FreeBSD Reception in https://en.wikipedia.org/wiki/RdRand#Reception

I came here after reading https://leonmergen.com/on-the-state-of-cryptography-in-haskell-c272fb0b6478

TLDR: Reporter wanted a one-line change, but rambled instead of submitting a patch. Instructions unclear; reporter & maintainer fought.

Thanks.

[Lazersmoke]

I agree with @edom. A crypto library, especially a low-level/primitives library like this one should focus on pedantically performing its job as best as it can, even at the expense of speed. A mention in the comments/haddock or the readme should be sufficient to alert high-level library writers that there is a way to speed up their library at the price of (maybe) some security.

A different argument could be made for a hypothetical "cryptonite-user" library that exposes a high-level API for situations where fine-grained control of the details of the encryption aren't needed, and speed is preferred over paranoid levels of security. In that case, leaving rdrand enabled by default makes sense because that's what it's good at.

That said, if the speed difference is very large between entropy sources, to the point where cryptonite would be a bottleneck if rdrand were disabled, then it would be sufficient to add an easy way to disable it, and a note explaining the situation in the readme or comments/haddock.