<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, Jul 26, 2015 at 10:53 AM, Rob Seward <span dir="ltr"><<a href="mailto:robseward@gmail.com" target="_blank">robseward@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div style="font-family:'Helvetica Neue';font-size:14px">1) Background:</div><span style="font-family:'Helvetica Neue';font-size:14px"></span><div style="font-family:'Helvetica Neue';font-size:14px"><br></div><span style="font-family:'Helvetica Neue';font-size:14px"></span><div style="font-family:'Helvetica Neue';font-size:14px">I’m building an Arduino shield mainly for educational purposes. I’m trying to keep it as simple as possible so that its internal workings can be easily understood. While I’m not creating something for serious cryptographic use, the project is less compelling if it cannot create cryptographic-quality output.</div></div></div></blockquote><div><br></div><div>My Infinite Noise TRNG is primarily meant as a means for educating the world about this architecture of TRNG.  If it is a good fit for your project, feel free to copy the Eagle files and simply delete the USB interface portion.  It's all open hardware/software.  This should make a nice tiny shield if you can deal with 6 pins:</div><div><br></div><div>- VCC - 3.3V, though the components should handle 3V to 5V.</div><div>- GND - 0V</div><div>- CLK1 - a 300 KHz square wave</div><div>- CLK2 - the inverse of the 150 KHz square wave</div><div>- OUT1 - output channel 1: sample this on rising edge of CLK1</div><div>- OUT2 - output channel 2: sample this on rising edge of CLK2</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><span style="font-family:'Helvetica Neue';font-size:14px"></span><div style="font-family:'Helvetica Neue';font-size:14px">2) What I’ve learned:</div><span style="font-family:'Helvetica Neue';font-size:14px"></span><div style="font-family:'Helvetica Neue';font-size:14px"><br></div><span style="font-family:'Helvetica Neue';font-size:14px"></span><div style="font-family:'Helvetica Neue';font-size:14px">2d) Avalanche noise from transistors is subject to failure.<br></div><div style="font-family:'Helvetica Neue';font-size:14px"><br></div><div style="font-family:'Helvetica Neue';font-size:14px">Correct me if I’m wrong, but it looks like without a health check, both approaches (2b and 2c) will produce random output even if the transistor fails and outputs all 0s. One thing I liked about my (flawed) algorithm is that it would pass statistical tests if the noise source was healthy, and produce poor, detectable results if the noise source failed.</div><div style="font-family:'Helvetica Neue';font-size:14px"><br></div><span style="font-family:'Helvetica Neue';font-size:14px"></span><div style="font-family:'Helvetica Neue';font-size:14px">With the above architectures, it seems some kind of internal health check would be needed. Running the stream through a Von Neumann filter might achieve this. Would a simple monobit test be a good (read: cheap) litmus test for the noise source’s health, or is something more sophisticated needed? Bill mentioned doing health checks on a host machine. Would this involve switching modes on the device? That is, stream unwhitened noise periodically to the host to check for health, and then switch back to encrypted output?</div></div></div></blockquote><div><br></div><div>I prefer to do whitening on the host side, with a pre-whitening health check.  Whitening in the shield is an iffy thing to do, for the reason you mention - you can't trust the data once it's whitened, if you have no way to verify the source.</div><div><br></div><div>Bill</div></div></div></div>