<font size=2 face="sans-serif">Debian also screwed up here at one point
and the SSH keys for Debian installs came from a very small subset of keys.
This CLASS of problem is common and it's something you need to make efforts
to avoid. And again, it is something you need to address as far as you
can because you simply can't rely on the users of your software to be able
to do better.</font><br><br><font size=2 face="sans-serif">Seeding is a hard problem as is using
the seed material correctly.</font><br><br><font size=2 face="sans-serif">The overall objective is security, security
requires instance unique keys, keys that aren't trivially guessed. Quite
a few of the suggestions made so far would compromise that. It's a very
different problem from generating good pseudo-random sequences and by it's
nature doesn't lend itself well to clean and elegant solutions. </font><br><br><font size=2 face="sans-serif">Peter </font><br><font size=2 face="sans-serif"><br><br></font><br><br><br><br><font size=1 color=#5f5f5f face="sans-serif">From:      
 </font><font size=1 face="sans-serif">Cory Benfield <cory@lukasa.co.uk></font><br><font size=1 color=#5f5f5f face="sans-serif">To:      
 </font><font size=1 face="sans-serif">openssl-dev@openssl.org</font><br><font size=1 color=#5f5f5f face="sans-serif">Date:      
 </font><font size=1 face="sans-serif">28/06/2017 17:15</font><br><font size=1 color=#5f5f5f face="sans-serif">Subject:    
   </font><font size=1 face="sans-serif">Re: [openssl-dev]
Work on a new RNG for OpenSSL</font><br><font size=1 color=#5f5f5f face="sans-serif">Sent by:    
   </font><font size=1 face="sans-serif">"openssl-dev"
<openssl-dev-bounces@openssl.org></font><br><hr noshade><br><br><br><tt><font size=2><br>> On 28 Jun 2017, at 04:00, Paul Dale <paul.dale@oracle.com> wrote:<br>> <br>> <br>> Peter Waltenberg wrote:<br>>> The next question you should be asking is: does our proposed design
mitigate known issues ?. <br>>> For example this:<br>>> </font></tt><a href="http://www.pcworld.com/article/2886432/tens-of-thousands-of-home-routers-at-risk-with-duplicate-ssh-keys.html"><tt><font size=2>http://www.pcworld.com/article/2886432/tens-of-thousands-of-home-routers-at-risk-with-duplicate-ssh-keys.html</font></tt></a><tt><font size=2><br>> <br>> Using the OS RNG won't fix the lack of boot time randomness unless
there is a HRNG present.<br>> <br>> For VMs, John's suggestion that /dev/hwrng should be installed is
reasonable.<br>> <br>> For embedded devices, a HRNG is often not possible.  Here getrandom()
(or /dev/random since old kernels are common) should be used.  Often
/dev/urandom is used instead and the linked article is the result.  There
are possible mitigations that some manufacturers include (usually with
downsides).<br><br>When you say “the linked article”, do you mean the PCWorld one? Because
that article doesn’t provide any suggestion that /dev/urandom has anything
to do with it. It is at least as likely that the SSH key is hard-coded
into the machine image. The flaw here is not “using /dev/urandom”, it’s
“exposing your router’s SSH access on the external side of the router”,
plus the standard level of poor configuration done by shovelware router
manufacturers.<br><br>Cory<br><br>-- <br>openssl-dev mailing list<br>To unsubscribe: </font></tt><a href="https://mta.openssl.org/mailman/listinfo/openssl-dev"><tt><font size=2>https://mta.openssl.org/mailman/listinfo/openssl-dev</font></tt></a><tt><font size=2><br></font></tt><br><br><BR>