building a true RNG (was: Quantum Computing ...)

David Honig dahonig at cox.net
Tue Jul 23 15:15:04 EDT 2002


At 08:39 AM 7/23/02 +0200, Eugen Leitl wrote:
>On Mon, 22 Jul 2002, David Honig wrote:
>
>> Yes, it is a joke.  However, it is also a viable if low-bandwidth
>> entropy source.  I disagree that you need to be able to model
>
>I've got a framegrabber with a 640x480 24 bit/pixel camera. It doesn't 
>compress, is rather noisy, and since self-adjusting I get the maximum 
>entropy at maximum darkness.
>
>Is there any point in compressing the video before running it through a 
>cryptohash? How does e.g. SHA-1 fare with very sparse bitvectors?

Good question.  I'd say the answer depends on the computational requirements
of "compression" vs. SHA, assuming you're trying to save CPU cycles.

You can measure the entropy of your camera staring at a wall and use that
to estimate how much you need to digest.  Then add a generous engineering
margin,
of course.


Here's the type of experiment I've done, which separates the
bit-digestion from the crypto-hashing: 

Once you measure entropy in your raw data, you can put the data sample through
various distillers.  For instance, xor pairs of bits, reducing the
sample size by 2.  Measure the entropy of this.  Keep doing this
until your entropy-measure says you've maxxed out.

Then, to truly mess with Mr. Adversary, put it through a crypto function
(which here needn't be a digest, e.g., a block cipher).

The latter step achieves the 'mixing' (avalanche) which is built into 
SHA.  For a software implementation SHA seems like a good choice, though
you don't get to measure the entropy distillation before whitening.







---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com



More information about the cryptography mailing list