<font size=2 face="sans-serif">The next question you should be asking
is: does our proposed design mitigate known issues ?. </font><br><font size=2 face="sans-serif">For example this:</font><br><br><a href="http://www.pcworld.com/article/2886432/tens-of-thousands-of-home-routers-at-risk-with-duplicate-ssh-keys.html"><font size=2 color=blue face="sans-serif">http://www.pcworld.com/article/2886432/tens-of-thousands-of-home-routers-at-risk-with-duplicate-ssh-keys.html</font></a><br><br><font size=2 face="sans-serif">Consider most of the worlds compute
is now done on VM's where images are cloned, duplicated and restarted as
a matter of course. Not vastly different from an embedded system where
the clock powers up as 00:00 1-Jan, 1970 on each image. If you can trust
the OS to come up with unique state each time you can rely solely on the
OS RNG - well provided you reseed often enough anyway, i.e. before key
generation. That's also why seeding a chain of PRNG's once at startup is
probably not sufficient here.</font><br><br><font size=2 face="sans-serif">And FYI. On systems not backed with
hardware RNG's /dev/random is extremely slow. 1-2 bytes/second is a DOS
attack on it's own without any other effort required.</font><br><br><font size=2 face="sans-serif">This isn't solely a matter of good software
design. And yes, I know, hard problem. If it wasn't a hard problem you
probably wouldn't be dealing with it now.</font><br><br><br><font size=2 face="sans-serif">Peter</font><br><br><br><br><br><font size=1 color=#5f5f5f face="sans-serif">From:      
 </font><font size=1 face="sans-serif">Benjamin Kaduk via
openssl-dev <openssl-dev@openssl.org></font><br><font size=1 color=#5f5f5f face="sans-serif">To:      
 </font><font size=1 face="sans-serif">openssl-dev@openssl.org,
Kurt Roeckx <kurt@roeckx.be>, John Denker <ssx@av8n.com></font><br><font size=1 color=#5f5f5f face="sans-serif">Date:      
 </font><font size=1 face="sans-serif">28/06/2017 09:38</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><font size=3>On 06/27/2017 04:51 PM, Kurt Roeckx wrote:</font><br><tt><font size=3>On Tue, Jun 27, 2017 at 11:56:04AM -0700, John Denker
via openssl-dev wrote:<br></font></tt><br><br><tt><font size=3>On 06/27/2017 11:50 AM, Benjamin Kaduk via openssl-dev
wrote:<br><br></font></tt><br><tt><font size=3>Do you mean having openssl just pass through to<br>getrandom()/read()-from-'/dev/random'/etc. or just using those to seed<br>our own thing?<br><br>The former seems simpler and preferable to me (perhaps modulo linux's<br>broken idea about "running out of entropy")<br></font></tt><br><tt><font size=3><br>That's a pretty big modulus.  As I wrote over on the crypto list:<br><br>The xenial 16.04 LTS manpage for getrandom(2) says quite explicitly:<br><br></font></tt><br><tt><font size=3>Unnecessarily reading large quantities  of data
will have a<br>negative impact on other users of the /dev/random and /dev/urandom<br>devices.<br></font></tt><br><tt><font size=3><br>And that's an understatement.  Whether unnecessary or not, reading<br>not-particularly-large quantities of data is tantamount to a<br>denial of service attack against /dev/random and against its<br>upstream sources of randomness.<br><br>No later LTS is available.  Reference:<br>  </font></tt><a href=http://manpages.ubuntu.com/manpages/xenial/man2/getrandom.2.html><tt><font size=3 color=blue><u>http://manpages.ubuntu.com/manpages/xenial/man2/getrandom.2.html</u></font></tt></a><tt><font size=3><br><br>Recently there has been some progress on this, as reflected in in<br>the zesty 17.04 manpage:<br>  </font></tt><a href=http://manpages.ubuntu.com/manpages/zesty/man2/getrandom.2.html><tt><font size=3 color=blue><u>http://manpages.ubuntu.com/manpages/zesty/man2/getrandom.2.html</u></font></tt></a><tt><font size=3><br><br>However, in the meantime openssl needs to run on the platforms that<br>are out there, which includes a very wide range of platforms.<br></font></tt><br><tt><font size=3><br>And I think it's actually because of changes in the Linux RNG that<br>the manpage has been changed, but they did not document the<br>different behavior of the kernel versions.<br><br>In case it wasn't clear, I think we should use the OS provided<br>source as a seed. By default that should be the only source of<br>randomness.<br><br></font></tt><br><font size=3><br>I think we can get away with using OS-provided randomness directly in many
common cases.  /dev/urandom suffices once we know that the kernel
RNG has been properly seeded.  On FreeBSD, /dev/urandom blocks until
the kernel RNG is seeded; on other systems maybe we have to make one read
from /dev/random to get the blocking behavior we want before switching
to /dev/urandom for bulk reads.<br><br>-Ben</font><tt><font size=2>-- <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>