<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Dec 2, 2016 at 9:26 AM, Nico Williams <span dir="ltr"><<a href="mailto:nico@cryptonector.com" target="_blank">nico@cryptonector.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">On Fri, Dec 02, 2016 at 11:24:45AM +0000, Peter Gutmann wrote:<br>
> Ray Dillinger <<a href="mailto:bear@sonic.net">bear@sonic.net</a>> writes:<br>
> >As written, it regards 128 bits as sufficient initial entropy.<br>
><br>
> Why 128 bits? What if it's less? Lets say you never block, which means you<br>
> could run on, say, 32 bits of entropy early on. Given the information<br>
> "somewhere on the Internet there may be a system that may be running with<br>
> lowered entropy in the RNG", how would an attacker exploit this?<br>
<br>
</span>For a sufficiently-low number of bits we'd have a number of recognizable<br>
SSH host keys and such. How low is that? 16 bits is too low for sure.<br></blockquote><div><br></div><div> </div><div>Does it make sense to look at a strategy that allows a system to boot and</div><div>connect with famous cached sites to update the system and then replace the</div><div>keys with unknown entropy with "better keys." Good bits should be very</div><div>possible once the device (IOT class device) has been up for reasonable </div><div>time (define reasonable).<br><br></div><div>It may be silly to have key generation so early in the boot process.<br>Better to let the system initialize itself and allow the entropy pool to </div><div>fill and then gate tools that need good keys. For sure after fsck has</div><div>run. The risky ssh attacks that can begin seconds after a device are real</div><div>but the attacks are distributed and the login+password+time is not</div><div>under the control of a TLA (today) and could be used as an additional</div><div>source of entropy. <br><div><br></div><div>Even connection attempts from the internet could trigger the lazy generation</div><div>of keys in contrast to building a key early. Knock, Knock... I hear you </div><div>let let me get presentable. Most real people would not answer the door without</div><div>pulling on pants... So a firewall rule, block, inspect the log to see who knocked</div><div>and act as needed. </div><br>If a design builds a map of a set of bits and lacking a quality TRNG require</div><div>bits from here and there be collected mixed and hashed into a larger seed </div><div>for use by a PRNG. </div><div><br></div><div>i.e. six bits of TRN is not enough but six bits to select, reorder and hash local "stuff"</div><div>like a DHCP assigned IPV4 and IPv6 tcp/ip address, domain name, a hash</div><div>of bits from a "random" offset into a binary system file or three, packet return or failure</div><div>times<br><br>If I time a reboot to a reconnect cycle on a small device the result is minutes today</div><div>so a lot of machine time exists to allow entropy to be collected.<br><br>Devices that only make outgoing connections need not keep the "first" key</div><div>generated. A fresh key a day might keep some snooper away.</div><div><br></div><div>Local DHCP servers can also deliver local bits to hash and mix.<br>The DHCP server uptime is likely long enough that quality bits invisible</div><div>to TLAs might be interesting interesting for enterprises. </div><div><br></div><div>Local AES accelerated encryption of local bits mixed into the pile.</div><div><br></div><div>All of these:</div></div></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div class="gmail_extra"><div class="gmail_quote"><div>Initial first boot, </div></div></div><div class="gmail_extra"><div class="gmail_quote"><div>IOT devices,</div></div></div><div class="gmail_extra"><div class="gmail_quote"><div>Portable devices with corporate data.</div></div></div><div class="gmail_extra"><div class="gmail_quote"><div>Portable with encrypted files.</div></div></div><div class="gmail_extra"><div class="gmail_quote"><div>Portable with encrypted filesystems.</div></div></div><div class="gmail_extra"><div class="gmail_quote"><div>Critical servers.</div><div>home routers,<br>local routers,</div></div></div></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div class="gmail_extra"><div class="gmail_quote"><div>trunk routers,</div></div></div></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div class="gmail_extra"><div class="gmail_quote"><div>Virtual machines (in many rolls).</div></div></div></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div class="gmail_extra"><div class="gmail_quote"><div>Mail servers.</div></div></div><div class="gmail_extra"><div class="gmail_quote"><div>Web servers</div><div>Data servers</div></div></div></blockquote>and more will be interacting and _any one_<div>might be used as the classic side door access</div><div>to gain elevate privilege and obtain access to the next.<br><br></div><div>So if the hardware+system does not deliver a quality TRN of sufficient</div><div>size quickly, a fall through swizzle of local bits and events could</div><div>leverage a small set (6+bits perhaps) to build a much better</div><div>seed for a more responsive system PRNG. </div><div><br></div><div>This is a fundamental system problem as much as an OpenSSL problem.<br>The system is no stronger than its weakest link. <br>The small devices are important.<br><br><br></div><div><div class="gmail_extra"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"> T o m M i t c h e l l</div></div>
</div></div></div>