Myths about /dev/urandom (2014)
1–10 of 70 posts
Re: Myths about /dev/urandom (2014)
#2This document is very informative for sure, but I don't really think it's dispositive for many of today's use cases for randomness. In fact, I think this document is pretty dangerous.
I referenced this document here in this stackexchange question, which I think has a good and lively discussion about the real stakes of /dev/urandom today:
https://security.stackexchange.com/questions/186086/is-alway...
Re: Myths about /dev/urandom (2014)
#3This document is very informative for sure, but I don't really think it's dispositive for many of today's use cases for randomness. In fact, I think this document is pretty dangerous. I referenced this document here in this stackexchange question, which I think has a good and lively discussion about the real stakes of /dev/urandom today: https://security.stackexchange.com/questions/186086/is-alway...
I don't think you're going to find too many cryptography engineers recommending that you use /dev/random, or, for that matter, the blocking variant of getrandom(2).
This might be a live debate on message boards, or on the wrong stack overflow boards --- though Pornin's answer[1] on this question is one of the all-time good Stack Overflow answers --- but among practitioners, this is long settled.
[1]: https://security.stackexchange.com/questions/3936/is-a-rand-...
Re: Myths about /dev/urandom (2014)
#4> I just claim that it's bad to block when the entropy estimate is low.
As always when it comes to engineering, good and bad can only be defined when you are specific enough about what it is you're trying to accomplish.
Is it a single-user client system with an intelligent user who won't try to subvert security (maybe because you've defaulted to /dev/urandom but given them a choice to override and use /dev/random), and you're trying to do something of crucial importance like generate a long-lived crypto key? Then blocking might be fine or even the better way.
Is it a multi-user and/or server system where randomness is a scarce resource whose exhaustion could bring down the system like any other scarce resource (disk, network, RAM, CPU, etc.)? Then blocking is probably a terrible idea and could even open you up to denial of service attacks, thus causing you to achieve less security.
Re: Myths about /dev/urandom (2014)
#5(disclaimer I sell a HW random number generator)
I think both the diagrams here are simplistic - in reality pre 4.8 there were 3 pools (an input pool and 2 output pools, one of which blocked) and post 4.8 where there are 2 pools, an input pool and a blocking pool (urandom now pulls from the input pool thru a CSPRNG).
One big downside of the new (post 4.8) architecture is that urandom_min_reseed_secs is ignored - pre-4.8 you could ask the kernel to periodically pull a little bit of real entropy from the input to refresh the urandom output (non-blocking) pool, by default that was once every 60 seconds, but in our case with lots of entropy available we'd set it to happen once a second - now post 4.8 it looks like urandom_min_reseed_secs is ignored and the input pool (where /dev/urandom gets its data from) is not regularly updated unless data is also pulled from /dev/random - which may make sense if entropy is rare, but is not so useful when back pressure from /dev/random is left to control the rate at which external entropy flows into the system - I suspect it's time to present a patch that makes urandom_min_reseed_secs work again
Nevertheless the conclusion "use /dev/urandom" is still valid
Re: Myths about /dev/urandom (2014)
#6> I just claim that it's bad to block when the entropy estimate is low. As always when it comes to engineering, good and bad can only be defined when you are specific enough about what it is you're trying to accomplish. Is it a single-user client system with an intelligent user who won't try to subvert security (maybe because you've defaulted to /dev/urandom but given them a choice to override and use /dev/random), a…
First problem with this response: programmers have a terrible understanding of what "crucial importance" is. In fact, most things in cryptography that want random values need unpredictable values. The old Linux man page creates the impression that you want "good" random for keys, and "mediocre" random for everything else, which is false.
Second problem is, there is no such thing as "good" and "poor" random. There are two states: unpredictable (seeded) and predictable (not yet seeded). Once you read seeded state, you're done; blocking serves literally no purpose.
Re: Myths about /dev/urandom (2014)
#7This seems to just muddy the waters.
https://sockpuppet.org/blog/2014/02/25/safely-generate-rando... is shorter, more succinct, and to the point.
Re: Myths about /dev/urandom (2014)
#8On a VM that someone else runs (i.e. Google or AWS), is either /dev/random or /dev/urandom cryptographically secure?
If no, are there any "safe" choices? (other than an external source like an HSM or hardware random number generator)
Re: Myths about /dev/urandom (2014)
#9[deleted]
Re: Myths about /dev/urandom (2014)
#10On a VM that someone else runs (i.e. Google or AWS), is either /dev/random or /dev/urandom cryptographically secure? If no, are there any "safe" choices? (other than an external source like an HSM or hardware random number generator)
What do you mean cryptographically secure? Do you mean secure against Google or AWS attacking you by poisoning or recording the randomness? That type of security doesn't sound possible to me. There is the field of homomorphic encryption that has the goal of protecting you against attacks by your cloud provider, but from what I've heard it's extremely slow and requires to you rearchitect all your jobs.