On Tue, Feb 26, 2013 at 11:39:26PM +0000, NetBSD Security Officer wrote: > > (...) > > Given that ECDSA ssh host keys are new in NetBSD 6 and get generated > by /etc/rc.d/sshd at system boot if not yet present, it is likely > that for systems that have been updated to NetBSD 6.0 or a netbsd-6 > branch kernel before the fix date, ECDSA host keys have being > considerably weakened by lack of actual randomness, especially > since with little system uptime stack contents will be more > predictable than later. Also, for systems newly set up with > NetBSD 6, all ssh host keys are suspect. > > Other persistent cryptographic secrets (for example, SSH or SSL keys of > any type) generated using /dev/urandom on NetBSD 6 systems which may have > had insufficient entropy at key generation time may be impacted and should > be regenerated. > > > Solutions and Workarounds > ========================= > > Workaround: > > Don't generate cryptographic keys, and don't use random numbers for > critical applications, unless the system has sufficient > "GOOD" entropy. In practice, this means reading from /dev/random > rather than /dev/urandom when using system entropy to generate > cryptographic keys.
I'm trying to process this issue but am not sure if I understood the problem properly. It affects /dev/urandom but not /dev/random? I thought ssh-keygen reads from /dev/random? Also, is there a precise interval one could use in conjunction with a find(1)? Or in other words: What would a "complete" cleanup approach look like?
