[Cryptography] cheap sources of entropy

[Bill Frantz]

On 1/20/14 at 9:54 AM, pinterkr at gmail.com (Krisztián Pintér) wrote:
>collecting entropy is easy. extracting entropy is also easy. providing
>a general solution that reliably produces entropy is hard. just as an
>example, take this camera project. the following questions come up,
>from the top of my head:

No hardware device should be trusted unless it passes periodic 
tests. Most computer hardware is tested automatically as part of 
its normal operation. Lets look at the following "what ifs" for 
random number generation with a camera pointed at streamers in a 
fan, or a fish tank, or leaves on a tree. Because these 
arguments apply to much simpler hardware random generators, I am 
going to assume no back doors in the camera.

One issue that is almost never revealed in these discussions is 
how random number generation fits into the specific situation. 
Ian's ceremonies are far different from someone building an OTP 
system because it is "theoretically perfect", ignoring all the 
major engineering difficulties that the theory ignores. The 
following tests should work for ID dongles, DSA signing, session 
key generation, etc.

Let's use one of the statistical random number tests. These will 
detect certain failure modes, e.g. all ones, reliably. They will 
also have a certain number of false positives. We deal with the 
false positives by not trusting the output after a test failure 
until a subsequent test has passed, logging the failure for 
human attention.

>- what if the camera breaks?
The result will be all ones or oll zeros, no problem.

>- what if the camera entropy production degrades with time?
This is an unlikely situation since aging generally results in 
more, not less, noise. However the test will fail due to too 
much repetition in the output.

>- what if lighting conditions change?
How is this situation different from "degrades with time"?

>- what if the driver is updated, and starts filtering noise?
Ditto.

>- what if the driver is updated, and stops producing data?
Ditto. No data should be easy to detect.

>- what if temperature variations affect entropy production?
Ditto.

>- what if an attacker can listen on in EM, and read your camera output?
You're hosed. Don't allow it.

>- what if another software on the same machine can read camera output?
Ditto. Get a good OS, or configure the one you are using correctly.

>- what if the janitor accidentally unplugs the camera?
How is this situation different from the camera breaking above?

If this approach isn't good enough, replicate it several times 
and combine the outputs.

Cheers - Bill


--------------------------------------------------------------
Bill Frantz        | There are now so many exceptions to the
408-356-8506       | Fourth Amendment that it operates only by
www.pwpconsult.com | accident.  -  William Hugh Murray