Hacker News new | past | comments | ask | show | jobs | submit login

But the entropy estimates are spurious, which means /dev/random can easily fail silently. This is the whole motivation behind Bruce Schneier and Niels Ferguson developing the Fortuna algorithm. Yarrow relied upon entropy estimates to recover from state compromise. With Fortuna, you don't know how long it will take to recover from state compromise (since it's difficult to reliably estimate entropy), but you know it eventually will happen.

Also note that most POSIX systems will cat a random seed file into /dev/random at startup and save entropy from /dev/urandom to the seed file at shutdown (and also hopefully right after adding to the entropy pool at startup). As long as an attacker doesn't have access to the disk or root permissions on the host, insufficient entropy should only be a problem the first time a host boots after install, presuming it gathers enough entropy after first boot.

FreeBSD and OSX use Yarrow for /dev/random and /dev/urandom, with absolutely no difference in behavior between /dev/random and /dev/urandom. I'd like to see Linux adopt Fortuna and make /dev/random non-blocking, though I can see the case being made for making /dev/random block after each boot until the estimated pooled entropy first goes above some threshold.




What happens with live-cd's on a read-only media? What about disk-less/thin clients? What about image restoration from backup? In each of those cases, the seed will either not be there or identical for each boot.

I would like to see a smarter /dev/urandom which asserts that there is enough fresh entropy. It would increase the trust of using it, and would put /dev/random usage in the special category of one-time pads. Until then, each case which the saved seed can cause issues with will have to be addressed if one choose to use /dev/urandom.


/dev/random should not be used for one-time pads. It's still generated from a stream cipher-based CSPRNG and is not "true" randomness.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: