3 ms·
> The /dev/random pool is limited based on the entropy that can be obtained from environmental noise, so if there is insufficient entropy, the requested number
by wtbob 12y ago
> The /dev/random pool is limited based on the entropy that can be obtained from environmental noise, so if there is insufficient entropy, the requested number of bytes may not be returned. If there is no entropy available at all, getrandom(2) will either return an error with errno set to EAGAIN, or block if the GRND_BLOCK flags bit is set.
Man, that's an ugly interface. So, if there are 8 bits of entropy available and I ask for 16, it will return 8, but if there are none available and I ask for 16 it will block and then return 16.
Also, it's not possible to know how much entropy is available. I'd really like to emphasise that: entropy estimation is nonsense.
Don't block; seriously, don't block. Just spit out the output of a properly-seeded PRF (e.g. AES in CTR mode).
- gioele 12y ago> Don't block; seriously, don't block. Just spit out the output of a properly-seeded PRF (e.g. AES in CTR mode). /dev/urandom does that and it is the suggested way to get secure random numbers for 99% of the applications.
- wtbob 12y agoNo, /dev/urandom fails the 'properly-seeded' criterion during early boot. The real answer is to just change the interface and be done with it, and to hell with backwards-compatibility, but that'll never happen. The really real answer is to make /dev/random and /dev/urandom the same CSPRNG, seeded as early in boot as possible (and continually refreshed with more entropy, of course), and never blocking thereafter, but that'll never happen either.