3 ms·

Then what are the requirements that make this necessary? Given security in layers tends to be the ideal, surely the dependence on generating at boot time could

• marshray 14y ago
  The basic requirement for a CSPRNG is that no one will ever be able to guess the values of a prior or future set of 200 bits with greater than a 1 in 2^200 chance of success (or pwning your kernel). It's not just a super-smart attacker you worry about too, sometimes all the systems on the internet collaborate accidentally to unmask each others' weak keys (see Heninger et al. linked in the thread). Boot up naturally involves starting network services and daemons which need their keys, right? It's a reasonable thing to want to do. The hard thing here is if we say "you can't have any output from the system CSPRNG until we're totally sure it's fully preheated", we end up with a few inevitable situations. Blocking read: "BUG: System hangs noticeably on boot" "If I change /dev/random to /dev/urandom my system boots 5 seconds faster! Woot!" and "So how long do I have to wait then? Why does boot take longer on some networks than others?" Nonblocking: If the kernel returns 0 bytes of data from read(), some apps will just continue on processing with their uninitialized or zeroed buffer. It's not so much that gathering entropy is hard, it's that making an accurate estimate of the entropy you gathered is hard (it's basically writing embedded code which attempts to estimate the capabilities of some unknown future black swan). Getting a platform full of developers to write code that correctly handles an error condition that never appears on their own developer workstation seems basically impossible.