Re: NetBSD Security Advisory 2013-003: Pseudo-Random bits weaker than expected

[Petar Bogdanovic <petar%smokva.net@localhost>]

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?