it also provides the much-needed middle ground between /dev/random and /dev/urandom.
What do you mean?
What do you mean?
/dev/urandom is too loose. It's designed to be computationally secure, which means that you could use it if your adversaries were stuck in our universe and had to make their computers out of matter and power them with energy. However, it never blocks, even if there isn't enough entropy in the pool.
We just need a PRNG that will spit out numbers as long as, say, 256 random bits were added to the pool at some point. Once you have that many bits, just keep on spitting out numbers.
urandom is not too loose. There is exactly one Linux issue with urandom: it will service requests before the urandom pool is initialized. Linux distros work around this by trying to make sure urandom is initialized securely very early in the boot process.
Once urandom is initialized, the idea that it can ever "run out of entropy" is nonsensical; urandom is structurally the same as a stream cipher keystream generator, and we generally don't fret about whether AES-CTR keystreams will "run out of key". Nonetheless, the belief that urandom will sporadically "run out of entropy" is virulent.
The motivation behind the new system call has more to do with chroot environments, where the device might not be available at all. It's a good change; randomness should be provided by a system call and not a device. Unfortunately, by adding the flag, they've basically managed to add two system calls: getrandom and geturandom. >HEADDESK<
It turns out Fortuna and variants thereof score very well in this metric, but this does not have any bearing on the quality of the output, or whether it loses entropy by generating more bytes.
Why wouldn't one simply create the appropriate device node inside the chroot? This argument strikes me as nonsense.
Forcing urandom to exist also precludes mounting partions 'nodev' which has secuirty implications in a chroot enviroment.
Lastly, relying on a devicefile makes you prone to things like fd exhaustion attacks.
If the seed value for urandom were compromised or you were unsure of its provenance (some systems carry over from last boot), would you not be safer calling /dev/random for something sensitive like key generation? What if you did not trust the PRNG that urandom used?
EDIT: Thanks for the clarification tptacek. I don't mean to disagree -- in fact it was you who explained this to me last time as well.
Unless you are concerned about where the seed came from (e.g. not storage like /var/run/random-seed) or have any concerns that there is a flaw in the PRNG that could leak information.
Something doesn't add up. Supposedly the reasons for creating urandom were to avoid blocking - but at the same time all the docs warn about entropy depletion. Are you now saying this is meaningless? If so, then why ever use /dev/random?
Given the lack of the "middle ground" introduced by this patch, you have (had) a choice between the failure mode of "block for a very long time" and the failure mode of "might generate easily predicted cryptographic keys under certain extremely rare circumstances". You use /dev/random if you prefer the first failure mode.
Edit: The whole situation didn't make sense from a system design point of view (unless you don't believe in CSPRNGs, but then you're basically screwed anyway), but given the unreasonable interface as a constraint, it's conceivable that somebody might have reasonably made the choice to use /dev/random.
no, he's not saying that - he's saying that there's no such thing as entropy depletion - and so urandom is secure. Which makes me ask after urandom was created - why EVER bother using /dev/random with it's blocking flaw/deficiency?
Use /dev/urandom. Don't use /dev/random. On sane systems (FreeBSD for example), /dev/urandom is a symlink to /dev/random and /dev/random only blocks once, upon startup to gather entropy, after that it never blocks!
/dev/random is also stupid, but it does protect you against that particular failure mode.
Exactly. The warnings about "entropy depletion" are only relevant to theoretical attacks which require either impossibly large computational resources or a flaw in the PRNG algorithm. Since either assumption breaks all our crypto for other, unrelated reasons, we use /dev/urandom.
That, and if you use /dev/urandom before it's seeded, you expose yourself to real attacks.
Why is /dev/urandom spitting out anything before it has acquired enough entropy for the initial seed? Wouldn't it be a good idea for it to initially block?
On a system with a recent Intel processor, there's a instruction (RDSEED) that uses on on-die hardware RNG. I'm not familiar with the standard linux boot-up process, but it could in principle seed urandom using RDSEED arbitrarily early in the process. That should work on VMs too unless the hypervisor is blocking access (can't imagine a good reason for that).
Via has on-die RNG considerably longer, though it's accessed slightly differently. I don't believe AMD or ARM has anything similar.
Is there a specific quote that isn't correct?
This particular way in which tptacek's comment is "mistaken" is related to the tone and attitude tptacek takes in his comments. If this were the only instance, even the only instance for this particular topic, it would be one thing, but this is a common issue with tptacek's comments. The pattern is that there are certain "common misconceptions" that everyone has, and tptacek is not generous to the poster of any specific comment that they might not possess them.
I further believe that it is a serious problem on Hacker News that people do not address these kinds of tone issues: that it is perfectly fine to "HEADDESK", claim that certain beliefs are "virulent", and to even use the word "nonsensical" to describe someone's idea, and yet attempts to point out issues in the tone of peoples' comments is somehow a problem: something where you feel the need to say "don't make this conversation personal". More people need to stand up to this.
I, myself, have done some of these things in my own comments. I feel like most of these cases were situations where I was responding to someone else doing it to me, but I've found at least a few instances where that is not the case. It makes me very unhappy that I contributed to this problem: someone should have also complained about my tone in those instances. It needs to be ok to exit the topic and address how someone is saying something, not just what was said.
To be clear, tptacek's position is correct: we don't need a new interface; klodolph's argument largely ends up arguing for fixing /dev/urandom. However, tptacek doesn't say this, as he has assumed that klodolph doesn't understand the difference between /dev/urandom and /dev/random, and then argued based on that assumption. If you read the other comments from klodolph, it is very very clear that he understands perfectly. tptacek could at least apologize.
(If you re-read my comment, you'll also find that the >HEADDESK< isn't addressed to 'klodolph at all, but to the designers of the Linux randomness system call).
You could probably mail me further thoughts you have about my comments on HN, if you wanted to keep talking about it.
https://blogs.oracle.com/darren/entry/solaris_random_number_...
I'm certain OpenBSD differs here as well.
/dev/random blocks whenever the system's "entropy count" is too low, even if the system has previously gathered enough entropy to produce secure randomness. The frequent blocking of /dev/random makes it unsuitable for practical use while providing questionable security benefit.
getrandom() blocks only until the system has gathered enough entropy to safely seed a CSPRNG, and then never blocks again. (Assuming the GRND_BLOCK flag and not the GRND_RANDOM flag.)
An in-depth explanation: http://www.2uo.de/myths-about-urandom/
/dev/urandom is insecure. Always use /dev/random for cryptographic purposes.
Fact: /dev/urandom is the preferred source of cryptographic randomness on UNIX-like systems.
This seems to contradict your first point, which is that /dev/urandom is insecure in some situations. (Returning randomness without sufficient entropy is a security problem.)
Can urandom ever be used insecurely? Tptacek has said many times that you should just seed /dev/urandom from /dev/random, then never use /dev/random again: http://hn.algolia.com/#!/comment/forever/prefix/0/author%3At...
Is LibreSSL's situation different? If so, why?
Seeding /dev/urandom from /dev/random is a trick that can be used early in the boot sequence to ensure that /dev/urandom is henceforth secure. (In practice, distros carry over a seed from the previous boot which accomplishes the same effect.)
well, you agree up to the point you actually need to convert your words into facts, at that point you don't agree anymore :)
https://github.com/AGWA/git-crypt/commit/34432e915e8415b112c...
By "this mess" I meant the LibreSSL fork/chroot mess. I think crypto libraries should just use whatever the OS provides and not try to implement their own CSPRNGs. But git-crypt is a cross-platform application, not a crypto library. Implementing my own cross-platform wrapper around OS CSPRNGs would be decidedly less sane (and more error-prone) than just using the crypto library's CSPRNG, even if I disagree with how the library has done things.
So even if you convince to use urandom for their crypto needs on *nix platforms, it'll still have to be easy to seed one in userspace if someone really wanted to.
This way, you could, say, somewhat simulate the behaviour of ZeroVM with Docker containers, by having the CSPRNG seed be a configuration parameter passed to `docker run`.