<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Feb 14, 2014 at 2:30 PM, Tom Mitchell <span dir="ltr"><<a href="mailto:mitch@niftyegg.com" target="_blank">mitch@niftyegg.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"><br><br><div class="gmail_quote">On Thu, Feb 13, 2014 at 8:08 PM, Joseph Ashwood <span dir="ltr"><<a href="mailto:ashwood@msn.com" target="_blank">ashwood@msn.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
From: Phillip Hallam-Baker</blockquote><div class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
I have a solution to the random number generator problem that can be built for about $50 and is completely verifiable.<br></div>
[shake a flask of candy, take a picture]<br>
</blockquote>
<br>
I'm not confident it will have as much entropy as you think. The design is a fairly basic modification of the lavarand design.<br></blockquote><div> </div></div><div>Joe is correct yet a strategy like this removes the ability of a remote party to predict your RN data stream.</div>

<div><br></div><div>Color saturation of candy will prove to present very clear bias.   Post processing as is done on Lavarand </div><div>is a good start at addressing this.   The papers on Lavarand including the critical papers are worth</div>

<div>a look.  These papers outline how little, how much entropy you might expect.</div></div></div></div></blockquote><div><br></div><div>I was certainly planning to use post processing!</div><div><br></div><div>Basically thats what shoving the data through SHA512 is about. But my interest here is in having a system that is verifiable end-to-end.</div>
<div><br></div><div>Relying on circuits etc has the problem that it is very hard to know is one is measuring noise or bias. I prefer to be measuring macro values that I can check independently and verify are part of the source.</div>
<div><br></div><div>If I take a 5MP image and squirt it through SHA2-512, I am going to take in randomness at both the macro and the micro levels. Instead of measuring the last bit on individual pixels, if the resolution of the camera is fine, it is essentially going to be unguessable as to whether the pixel is red or green or some other color.</div>
<div><br></div><div>Out of 5MP there are going to be plenty of sites that might be one side of an edge or the other. There are going to be many edge sites that are in-between. </div><div><br></div><div>512 bits is 64 bytes, which is a tiny fraction of a 5MP JPEG size. I don't think it very likely that there is an insufficient amount of randomness in the image. We can at any rate measure and see...</div>
<div><br></div><div><br></div><div>The sort of thing I was thinking of was using a camera on a Raspberry Pi ($40) to capture two frames of video during the randomness acquisition. It would store the data for each and provide a HMAC of both images under a specified key and a thumbprint of both images. The auditor could then request that the device reveal either the first or the second image. It would then provide the input to the hash function of the chosen image and delete the other.</div>
<div><br></div><div>The problem then becomes how to prove that the random number is calculated from both inputs... which is actually quite hard to do. A verifiably read once device would be nice.</div></div><br clear="all">
<div><br></div>-- <br>Website: <a href="http://hallambaker.com/">http://hallambaker.com/</a><br>
</div></div>