[Cryptography] The ultimate random source

Phillip Hallam-Baker hallam at gmail.com
Sat Feb 15 13:02:19 EST 2014


On Fri, Feb 14, 2014 at 2:30 PM, Tom Mitchell <mitch at niftyegg.com> wrote:

>
>
> On Thu, Feb 13, 2014 at 8:08 PM, Joseph Ashwood <ashwood at msn.com> wrote:
>
>>
>> From: Phillip Hallam-Baker
>
>
>
>>  I have a solution to the random number generator problem that can be
>>> built for about $50 and is completely verifiable.
>>> [shake a flask of candy, take a picture]
>>>
>>
>> I'm not confident it will have as much entropy as you think. The design
>> is a fairly basic modification of the lavarand design.
>>
>
> Joe is correct yet a strategy like this removes the ability of a remote
> party to predict your RN data stream.
>
> Color saturation of candy will prove to present very clear bias.   Post
> processing as is done on Lavarand
> is a good start at addressing this.   The papers on Lavarand including the
> critical papers are worth
> a look.  These papers outline how little, how much entropy you might
> expect.
>

I was certainly planning to use post processing!

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.

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.

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.

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.

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...


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.

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.


-- 
Website: http://hallambaker.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20140215/6d1d4778/attachment.html>


More information about the cryptography mailing list