Let's say I want a gigabyte or so of random data from /dev/random, suitable for a one-time pad (so /dev/urandom is out.) How do I seed my /dev/random with enough entropy to do this? I am looking for specific commands and programs for this. I do not want to buy anything. I am using Arch Linux, if that makes a difference.
Two programs that can increase the entropy pool without requiring extra hardware are
rng-tools uses RNGs available in modern CPUs and chipsets,
haveged uses modern CPU randomness (cache behaviour etc.). Both are available in Arch, and the Arch wiki has an interesting page discussing them. I haven't tried using them to generate a gigabyte of data but it should be possible in a sensible amount of time.
You explicitly exclude buying anything, but just for completeness' sake there's an interesting article in LWN about entropy with NeuG, which includes discussion of
haveged and various other approaches. You can buy an STM8S board capable of running NeuG for less than $10, or a FST-01 for $35.
Unfortunately /dev/random is also not suitable for use in a one-time pad, at least not the kind of one-time pad (with provable security guarantees) that most people imagine when they think of or implement one-time pads. Most of the information below is summarized from the (very long) article at http://www.2uo.de/myths-about-urandom/
The problem is that /dev/random is not truly random; it uses a CSPRNG to generate its output. In fact, /dev/random uses the exact same CSPRNG as /dev/urandom. The only difference is that /dev/random blocks if its internal estimate of entropy is insufficient.
The word "estimate" in the previous sentence is key. Most people think that this estimate is always accurate and perfect, but in reality it's not at all accurate. The instant the estimate is wrong, you lose all the provable security guarantees of the one-time pad, and all you have left is computational security -- no better than if you had used /dev/urandom!
Getting the entropy estimate just a little bit wrong does not make your one-time pad just a little bit insecure. The provable security guarantee of a one-time pad is all or nothing.
The premise of this question is that the problems with /dev/random can be "fixed" by adding more entropy. Unfortunately, this premise is wrong. A malicious source of entropy is much worse than no entropy at all, because entropy sources often have access to internal data and can export this data covertly using RNG output -- see http://blog.cr.yp.to/20140205-entropy.html for a full discussion (too long to summarize here). In particular, a hardware source of entropy (as recommended by several other answers) is a very bad choice from a security perspective, since that hardware is in prime position to do malicious things, and it is essentially unauditable.
Seems like an HW component is the best idea. There are some HW generator IC out there, but you have to trust them as they come.
Two probably good solution are to induce component to create noise; two major solution seems to be temperature bias and the avanche noise created with a diode (see http://web.archive.org/web/20061117145903/http://willware.net:8080/hw-rng.html)
As the components like gyro and accelerometer has becomed more sensible, making them work at highest sensitivity and using their LSB value can also a nice solution, but AFAIK nobody as audited it.
Is funny as there are a lot of paper on NOT do RNG, but not an HW implementation open and verified
You could use pycsprng.py. Cryptographically secure? I'm not quite sure, but I would like some peer-review.
python pycsprng.py | pv | dd of=data.file bs=1024 count=1000
The pipe to
pv is optional, and will just help you know how much data has been transfered.
You may find that larger block-sizes (bs) increase perfomance. You will have to adjust the count to not generate too large of a file if you increase the block-size.
What you get from an analog microphone channel when you don't plug in a microphone is usually just static. Pipe that through bzip2, for example, for whitening, mix it with another source of randomness (urandom or another microphone jack), maybe pipe the result through openssl for good measure and what you get should be pretty random.
It would be difficult to prove any hard and fast security properties about the randomness of the result, though.
To generate 100 MB of hardware-generated random data, you can:
Record 20 minutes of audio (96khz 16bit mono) with your computer's built-in microphone (available on a laptop). You will get a ~ 220 MB WAV file.
Discard the non-useful bits, and shuffle the bits of binary data (many ways to do this) with some math
Export the shuffled bits as a ~ 100 MB binary file
Here is an article about this: An attempt to generate true entropy and random data with audio (and your computer's built-in microphone).