> 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.
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.
> programmers have a terrible understanding of what "crucial importance" is.
If you cannot understand requirements, you cannot produce satisfactory software.
Anyway, it was intentional that I gave an example where an educated end user is able to make the choice rather than a programmer having to guess.
> The old Linux man page creates the impression that you want "good" random for keys, and "mediocre" random for everything else, which is false.
It certainly is false, and it is a myth that many people believe, but it isn't what I was saying.
> Once you read seeded state, you're done; blocking serves literally no purpose.
As the article explains under the last section ("Not everything is perfect"), /dev/urandom does not guarantee that you are reading seeded state.
Also, those numbers' unpredictability rests on the crypto being really good. Which I'm sure it is, but crypto weaknesses have been discovered in the past. It would be defensible to seek additional protection against that possibility for peace of mind if peace of mind is more important to you than running time and/or availability.
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.