<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Nov 28, 2016 at 9:38 AM, ianG <span dir="ltr"><<a href="mailto:iang@iang.org" target="_blank">iang@iang.org</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 28/11/2016 11:46, Bill Cox wrote:<br>
</span><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 Sun, Nov 27, 2016 at 11:02 AM, ianG <<a href="mailto:iang@iang.org" target="_blank">iang@iang.org</a><br></span><span class="gmail-">
<mailto:<a href="mailto:iang@iang.org" target="_blank">iang@iang.org</a>>> wrote:<br>
<br>
On 26/11/2016 09:38, Salz, Rich wrote:<br>
<br>
Absolutely right. Only TRNGs that make raw data available<br>
should be trusted. <br></span></blockquote></blockquote><div>.... </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><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-">
Meanwhile, back in the real world... </span></blockquote></blockquote><div>....</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><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-">
Ian, would you agree that something on the platform needs to first<br>
ensure that /dev/random is well seeded before OpenSSL reads from<br>
/dev/urandom?<br>
</span></blockquote>
<br>
Yes absolutely! That is a platform responsibility - see the thread with John Denker where he says:<br>
<br></blockquote><div><br></div><div>The startup case is the most fragile. <br>This is the easy to attack -- closest to the butterfly taking wing case.<br>
<br>The number of "true" random bits is interesting. </div><div>On the internet there are a lot of devices and as long as the </div><div>vast majority have a lot of good bits those that have less will</div><div>be invisible as long as they are not identifiable as a class. <br>Specifying twice what you expect makes sense to compensate</div><div>for weaker hardware in the connected hardware population.</div><div><br></div><div>The more valuable the data the more quality needs to be specified.<br>Thus the interface needs to allow the likes of the NSA, Google, </div><div>Amazon.... to attach better and unique devices.<br><br>Modification of hardware like laptops is getting harder.<br>USB device have risks that invites epoxy.<br>Apple is all dongles too easy to swap or misplace.<br><br>Portable hardware is IMPORTANT as it is the remote and portable access</div><div>for almost all workers today. (Navy data breach, lost laptop this week).<br>Phones are used more and more for access. The critical links</div><div>are increasingly portable.<br><br>Portable devices are the connection point and need to be as well</div><div>secured at the servers.<br><br>Exotic packaging for thin and light notebooks and sealed phones </div><div>are all difficult to inspect yet special tools and tricks allow it to be repaired </div><div>and modified. The big boys could modify devices in transit no mater the maker.</div><div><br></div><div>Sandboxes and Virtual machines confound easy hardware solutions</div><div>with a layer of abstraction.</div><div><br></div><div>BIOS "white lists" limit the exchange of one WiFi device for another</div><div>and thus hobble the ability to design and deploy a WiFi+entropy device.</div><div><br></div><div>Sensors, GPS receivers do see a lot of positional uncertainty.</div><div>Compensating data from reference sites is one interesting</div><div>regional wiggle. A GPS receiver sitting on a window can </div><div>draw a target that will center on one location but any individual</div><div>read will have entropy in the low bits.</div><div>In Texas..."<span style="color:rgb(0,0,0);font-family:calibri,verdana,geneva,sans-serif;font-size:14px">high-accuracy base stations referred to as "Regional Reference Points" (RRPs). TxDOT </span></div><div><span style="color:rgb(0,0,0);font-family:calibri,verdana,geneva,sans-serif;font-size:14px">is participating with the RRPs in the National Continuously Operating Reference Stations (CORS) </span></div><div><span style="color:rgb(0,0,0);font-family:calibri,verdana,geneva,sans-serif;font-size:14px">network operated by the National Geodetic Survey (NGS). The RRPs are based on the North </span></div><div><span style="color:rgb(0,0,0);font-family:calibri,verdana,geneva,sans-serif;font-size:14px">American Datum (NAD) 83 (EPOCH 2010.0) coordinates and are used to improve positional </span></div><div><span style="color:rgb(0,0,0);font-family:calibri,verdana,geneva,sans-serif;font-size:14px">accuracy through post-processing techniques. " </span> <a href="http://ftp.dot.state.tx.us/pub/txdot-info/isd/gps/">http://ftp.dot.state.tx.us/pub/txdot-info/isd/gps/</a><br> <br> </div><div><br></div><div><br></div><div><br><br></div><div><span class="gmail-"><br></span></div><div><span class="gmail-"><br></span></div></div><br><br clear="all"><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>