<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">Top posting just the new news, with responses to your comments below.<br></div><div class="gmail_quote"><br>The breadboard works! The estimated entropy coming out of the Infinite Noise Multiplier is very close to the predicted amount. I measure it by recording outcomes given the previous 16 bits many times until I have a reasonable guess for the probability of the next bit being a 1 or 0. I use that to estimate the probability of a long string of bits occurring. The entropy is estimated as log2(1/P(S)), where P(S) is the probability estimate of the string of bits S occurring. This estimated entropy closely matches the expected log2(K), where K is the gain in the op-amp circuit. I tested this for 3 different gains, and they all matched within 5% of the theoretical value. I added a picture of the breadboard here:<br><br><a href="https://github.com/waywardgeek/infnoise">https://github.com/waywardgeek/infnoise</a><br><br></div><div class="gmail_quote">I also wrote some code to find how soon we see a repeated string N bits long. The data from the INM has repeated strings of size N consistent with the estimated entropy. This proves that there is no scary cycling of the same outputs over and over, at least with a period less than the expected length before seeing an N-bit repeated string (20,000+ in my tests for 34 bits).<br></div><div class="gmail_quote"><br>On Thu, Oct 9, 2014 at 2:12 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>On 9/10/2014 01:59 am, Bill Cox wrote:<br>
> On Wed, Oct 8, 2014 at 7:00 PM, Dave Horsfall <<a href="mailto:dave@horsfall.org" target="_blank">dave@horsfall.org</a><br>
</span><span>> <mailto:<a href="mailto:dave@horsfall.org" target="_blank">dave@horsfall.org</a>>> wrote:<br>
><br>
> It's possible that I may have missed this (the list seems to have spiked<br>
> lately), but how would the device present itself to the host? A serial<br>
> stream of random bits (like a terminal or a keyboard), or some sort of a<br>
> structure with command and control etc?<br>
><br>
> -- Dave<br>
> _______________________________________________<br>
> The cryptography mailing list<br>
</span>> <a href="mailto:cryptography@metzdowd.com" target="_blank">cryptography@metzdowd.com</a> <mailto:<a href="mailto:cryptography@metzdowd.com" target="_blank">cryptography@metzdowd.com</a>><br>
<span>> <a href="http://www.metzdowd.com/mailman/listinfo/cryptography" target="_blank">http://www.metzdowd.com/mailman/listinfo/cryptography</a><br>
><br>
><br>
> No command/control. In fact, I feel a lot better not having a<br>
> microcontroller on there that could transmit nasty malware when being<br>
> plugged into a new system, or which could be reprogrammed to emit<br>
> non-random data.<br>
<br>
<br>
</span>My guess is that if you don't have an easy defined interface (file? tty)<br>
then it won't work in the marketplace.<br></blockquote><div><br></div><div>For now, I've got an application that reads from the USB using the existing serial interface driver that comes with the FT240X USB interface chip I'm using.<br><br></div><div>It normally whitens by reading 2X the amount of entropy requested and filtering it through the 1600 bit version of the Keccak (SHA3) sponge. It just writes the binary data to stdout for now, but it's simple to make that a file socket or whatever. There's a --raw flag which dumps raw data from the noise source without whitening. I have been doing some fun health checking stuff with that. A --debug flag causes it to print estimated entropy, gain in the op-amp, and a couple of other stats.<br></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">
In terms of the nasty malware, what would be nice would be a firewall.<br>
A device that has male & female and sits there and watches for naughty<br>
traffic. If this came with a good RN source as well, I'd reckon it<br>
would be a hit.<br></blockquote><div><br></div><div>Some sort of automated Internet traffic cop might be a hit. If it needs a source of random data, it's about $1 in extra components to an embedded system.<br></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">
...<br>
<span>> How important is the proper USB connector vs a raw connector with no<br>
> housing like the DigiSpark? Do we really feel we need to wrap this<br>
> thing in metal to keep it from radiating secret bits?<br>
<br>
<br>
</span>Yes, otherwise it will be noisy :) You don't want it interfering with<br>
random gear.<br>
<br>
You could probably get away without in a prototype device and encourage<br>
someone to do some testing...<span><br></span></blockquote><div><br></div><div>I added a real USB connector, and have nickle EMI paint I can use on the inside of the USB key housing. Hopefully that will keep it quiet.<br></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"><span>
> I figure if we<br>
> feed it into a whitener, an attacker would have to know *every* bit to<br>
> know the state of the whitener. That seems like a tall order for an<br>
> attacker trying to read bits from EMI.<br>
<br>
<br>
</span>Oh, no :) In the crypto world we deal with bit-rated paranoia. Even<br>
one bit leaked to an attacker will earn the device the BROKEN award.<br>
<span></span></blockquote><div><br></div><div>True enough. I'm shielding it with conductive paint on the inside of the plastic housing. I am tempted to leave the housing un-glued so that users can take it apart if they like and poke at the internals. I saw at least one TRNG company that encases their electronics in potting material. That's no better than Intel asking us to just trust that their TRNG circuit is secure. If we can't open it up and see for ourselves, why should we trust the manufacturer?<br><br></div>Bill<br></div></div></div>