1e31 Talk:One Time Pad - Telecomix Crypto Munitions Bureau

Talk:One Time Pad

From Telecomix Crypto Munitions Bureau

Jump to: navigation, search

The One Time Pad article presents code for creating OTP keys using /dev/random as the sole entropy source. The quality of entropy from /dev/random has been the subject of a lot of debate, but it boils down to this: The larger the "random number" created by /dev/random, the less "random" it really is. A one time pad file large enough to support meaningful communication should be derived from a physical RNG if "unbreakable" message traffic is the objective.

/dev/random collects data from (relatively) unpredictable system events on the host machine. It aggregates and hashes this data, using previously collected and hashed data as a "random seed" to guarantee a minimum amount of entropy per iteration. Pulling 256 bits of data from /dev/random to create an AES key for a GPG message is a typical use case. In this case, /dev/random provides more than adequate entropy, because it has been collecting and hashing data for a "long time" in machine terms between key creation events.

But if you are generating a one time pad key file that can be used to encrypt a meaningful amount of communication between two (or more) parties, say 10 MB, the pool of bits stored by /dev/random is immediately exhausted and it has to start grinding out new key material as fast as it can, using whatever entropy it can grab from system events during the process. The final 10 MB file will be many orders of magnitude "less random" because the amount of actual entropy (unpredictable events) sampled during this process will be a small fraction of the bits delivered. Long story short: /dev/random is "random enough" for its intended uses but it is not a magic wand that makes random bits in any amount on demand.

An ideal physical RNG for use with a one time pad system would deliver mechanically created entropy through a process that has been well studied and found to be "computationally infeasible" to model and predict. It should deliver very large quantities of chaotic data to the users' machines on demand.

An example: Wrap a microphone in plastic and run water from an aerated faucet over it. Save the resulting stream of noise as an uncompressed audio file, remove the header from the file, and run the remaining bits through a series of hash functions to "shuffle away" any non-random content into the entropy of the original sound source. Although this method does not produce "perfect" entropy, it provides any quantity of key material desired, with many orders of magnitude more entropy than a process like /dev/random can generate.

Personal tools
0