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.

  • Wouldn't such a program turn /dev/random into something having the same problem as /dev/urandom that you don't want to use? Or are you referring to something that gets extra entropy out of some device or over the network? – Anthon Jun 16 '15 at 2:12
  • @Anthon I am talking about specific programs for extracting randomness from an entropy source, such as shot noise, thermal noise, some device, etc... The program would not make the randomness itself. – PyRulez Jun 16 '15 at 2:14
  • ... for example, a command or program that says Here — type something:, and then measures the inter-keystroke time deltas to a higher precision than a human can control? – G-Man Jun 16 '15 at 8:44
  • 1
  • 1
    It mentions a one-time pad as one of two exceptions to the assertion that _'... almost all of the cryptographic algorithms ... “only” offer computational security'. Unless you can quote something I missed where it says one-time pads can't use urandom? – Useless Jun 16 '15 at 16:28

Two programs that can increase the entropy pool without requiring extra hardware are rng-tools and haveged. 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.

  • I didn't say I was fixing it with more entropy, I just needed more for a bigger key. That is a good point though about it being faulty. Can you recommend any alternatives? – PyRulez Jun 16 '15 at 13:33
  • 1
    This is a good answer except for the last bit about hardware sources. Hardware sources of entropy are the only reliable, auditable way to get entropy. You (or someone you trust) do need to audit the source — that requires having design information and verifying that the manufacturing process respects the design information. You can even combine sources of entropy so that if at least one of them is fine then the result is fine (N.B. you need to combine them correctly for that). – Gilles Jun 16 '15 at 22:47
  • Gilles, read the second link I posted. It is completely false to claim that if at least one entropy source is fine then the result is fine. The entire purpose of that link is to refute this false claim! – djao Jun 16 '15 at 22:59
  • Moreover, it is not enough to audit the source and the manufacturing process. You need to audit your individual device to make sure that your device was manufactured according to the manufacturing process. This is a much harder task than the analogous task in software, which consists simply of checking a checksum. – djao Jun 16 '15 at 23:07
  • As for alternatives: there's no alternative magic way to get 1GB of random data out of a PC. You would need a hardware device for that (but then pay attention to what I said about hardware being difficult to audit). If you were willing to use /dev/random, then /dev/urandom is just as good; it's no worse than /dev/random for all cryptographic applications. – djao Jun 16 '15 at 23:55

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.

  • 3
    That just uses /dev/urandom... – Stephen Kitt Jun 16 '15 at 5:30
  • 1
    pycsprng.py is literally a 10 SLOC script that gets randomness from os.urandom. Docs say that "The returned data should be unpredictable enough for cryptographic applications [...] On a UNIX-like system this will query /dev/urandom". It actually does (it's outdated source though) and Security.SE says that it's okay for crypto. – gronostaj Jun 16 '15 at 10:09
  • Not one time pad crypto! – PyRulez Jun 16 '15 at 13:29

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.


If you are using linux kernel 2.6.9 or newer on amd64 / x86_64 processor, virtual or physical environment, you may try ncomputers.org/pandom a true random number generator, that offers 8 KiB/s entropy of 64 ubits/64 bits through /dev/random

sample output

  • Links busted, couldn't find a backup to it. – slm Oct 13 '18 at 5:21

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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.