On Thu, Jun 07, 2007 at 12:32:01AM -0400, Joey Hess wrote: > I'm running into this since I prefer my headless slug start the ssh > server as early in the boot process as possible -- which increases the > chances of not enough entropy. > > I don't understand this comment from #310732: > > A solution could be to have dropbear first check /dev/random, and if > > it blocks, to fall back to /dev/urandom. > > Avoiding /dev/random blocking is exactly what /dev/urandom is designed > for. There is no need to read from /dev/random first and try to detect > it blocking; a read from /dev/urandom will return full-quality random > data same as /dev/random, if it's available.
Where can I read about this? > It's worth noting that openssh uses /dev/urandom. Using /dev/random is > appropriate for things like gnupg key generation that generate > long-lived keys and require absolute best-effort randomness, but it > doesn't seem warrented for a (semi-)transient ssh session key, especially > when the result is that the vital ssh service can't be relied on because > the daemon may have hung during boot. > > It's perhaps also noteworthy that OpenWRT's dropbear is built to use > /dev/urandom. I imagine that anyone using it in production will do the > same: the entropy issues are absolutely crippling. Ok, fine with me, I'll change dropbear to use /dev/urandom only. Thanks, Gerrit. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
