This article naturally leads to a question that I didn’t see addressed, perhaps you can answer it here:
If it’s unnecessary to ever prefer /dev/random to urandom, then why does /dev/random’s current blocking implementation still exist? Surely between all of the kernel developers, between all of the Unix-ish OS’s, over the last couple of decades would have realized that /dev/random should simply act like /dev/urandom?
Because Theodore Ts'o, a major Linux contributor and maintainer, created and maintains /dev/random and blocks attempts to make it nonblocking like every other cryptographically secure random source. It's a political problem, not a technical one.
I don't see how this is political. In that link he presents actual problems that have arisen from non-blocking versions. I'd call that a technical justification.
I don't necessarily agree with his justification, but that's also a difference in technical opinion. The only way I'd fault him is if I can come up with a an approach that addresses his concerns yet he still refuses to accept them.
Full disclosure: I've actually interacted with him on a few occasions. IMO calling him risk/change-averse would be an understatement, which partly explains this stance. While at times frustrating for us, this is exactly the quality you want in someone maintaining such a critical part of the kernel.
I suspected that “politics” was going to end up being the answer to my question. Simply because this seems to be a very contentious issue, even if it doesn’t need to be.
And what is the current state of /dev/urandom on Linux? Does it finally block on cold start with too little entropy? If it does, then effectively everybody can finally just use /dev/urandom, if I understand it correctly?
If it's still not blocking, it seems that still the best thing to do is using getrandom( ..., 0 )?
Why should it be made non-blocking? If you want a large string with little entropy just use /dev/urandom.
The political/dogmatic argument is that is should be made non-blocking. The process of acquiring entropy in typical computers is definitely blocking.
But you can't do this "those 128 bits are used but are kept not known" thing with software. Sure, it is being tried again and again, and it fails every time.
You need separate hardware to safely prevent these 128bits from leaking.. but then why don't we ditch whole idea and implement true HW RNG instead?
I don't think you understood what he was saying, because if you think "you can't protect 128 bits in software" rebuts it, you also don't believe that any software cryptography works, in any setting; virtually all of it involves managing secret or unpredictable 128 bit values.
His point is that the mechanism used to generate random bytes by a modern CSPRNG is virtually identical to the mechanism that encrypts the application_data in a TLS session.
So you see absolutely no difference between leaking /dev/urandom PRNG seed from which all random numbers are generated for days or weeks, and leaking just one key for one TLS session?
Mechanism can be identical, but the stakes are definitely not.
Because we don't generate random numbers to look at them and marvel at their philosophical pureness, we use them. In software.
So those bits will be known to software, no matter where the generation happens.
Your argument would make a bit of sense if you were arguing for doing all cryptographic operations in hardware. Like on a smartcard. But that's not what we're talking about.
/dev/random is more secure than /dev/urandom because it blocks if there's not enough entropy. So if you want to generate private key, you should use /dev/random or you risk getting weak keys.
In low-entropy conditions (e.g. right after OS in VM has been installed) /dev/random is better but it might block (for minutes or hours). /dev/urandom is always issues some data, so your application won't hang because of it, but it might issue not very crypto strong bytes in those conditions. Best solution is to use hardware crypto or pass random data from host to VM or something like that. Also you might consider to use getrandom syscall. It's non-blocking if entropy pool has been initialized, otherwise it blocks (AFAIK the same as FreeBSD /dev/random). Probably the best of both worlds. That's how I understand the whole topic anyway.
This suggests that you're not an expert. Therefore, it is wise to just stick to what the experts write, in articles such as this. That's what I do. Cryptography is a very complex subject; non-experts who give advice without knowing exactly why they are saying what they're saying are contributing to the problem, so please avoid doing that.
Nota bene: I‘m not an expert, just quoting them. :-)
I used to be very confused, too, and after learning something about it, I wrote that page. Almost didn‘t finish and publish it when tptacek put his page up, but by that time I had already invested most of the effort, and I wanted to be less terse.
True, maybe I should have added ...and non-experts who try to faithfully summarize them for us mere mortals.
Edit: actually, I think I would recommend everyone interested in this subject to read at least a few texts by actual experts (professors in cryptography and people who work for high-stakes security businesses), to get a taste of what it's all about.
If it’s unnecessary to ever prefer /dev/random to urandom, then why does /dev/random’s current blocking implementation still exist? Surely between all of the kernel developers, between all of the Unix-ish OS’s, over the last couple of decades would have realized that /dev/random should simply act like /dev/urandom?