Feeding /dev/random entropy pool?

Question

Which way of additionally feeding /dev/random entropy pool would you suggest for producing random passwords? Or, is there maybe a better way to locally create fully random passwords?

Answer 1

You can feed it with white noise from your sound chip, if present. See this article: http://www.linuxfromscratch.org/hints/downloads/files/entropy.txt

Answer 2

You should use /dev/urandom, not /dev/random. The two differences between /dev/random and /dev/urandom are (I am talking about Linux here):

• /dev/random might be theoretically better in the context of an information-theoretically secure algorithm. This is the kind of algorithm which is secure against today's technology, and also tomorrow's technology, and technology used by aliens, and God's own iPad as well. Information-theoretically secure algorithm are secure against infinite computing power. Needless to say, such algorithms are pretty rare and if you were using one, you would know it. Also, this is a "might": internally, /dev/random uses conventional hash functions, so chances are that it would have weaknesses anyway if attacked with infinite power (nothing to worry about for Earth-based attackers, though).

• /dev/urandom will not block, while /dev/random may do so. /dev/random maintains a counter of "how much entropy it still has" under the assumption that any bits it has produced is a lost entropy bit. Blocking induces very real issues, e.g. a server which fails to boot after an automated install because it is stalling on its SSH server key creation (yes, I have seen that). /dev/urandom uses a cryptographically strong pseudo-random number generator so it will not block, ever.

So you want to use /dev/urandom and stop to worry about this entropy business.

Now you may want to worry about entropy if you are writing the Linux installer. The trick is that /dev/urandom never blocks, ever, even when it should: /dev/urandom is secure as long as it has received enough bytes of "initial entropy" since the last boot (32 random bytes are enough). A normal Linux installation will create a random seed (from /dev/random) upon installation, and save it on the disk. Upon each reboot, the seed will be read, fed into /dev/urandom, and a new seed immediately generated (from /dev/urandom) to replace it. Thus, this guarantees that /dev/urandom will always have enough initial entropy to produce cryptographically strong alea, perfectly sufficient for any mundane cryptographic job, including password generation. The only critical point is during installation: the installer must get some entropy from /dev/random, which may block. This issue also occurs with live CD and other variants with no read-write permanent storage area. In these situations, you may want to find some source of entropy to ensure that /dev/random will be well-fed, and will not block.

The operating system itself, and more precisely the kernel, is at the right place to gather entropy from hardware event, since it handles the hardware. So there is relatively little that you can use for entropy that the kernel does not already use. One of those remaining sources is Webcam data: a webcam, even facing a blank wall, will output data with thermal noise, and since it outputs lots of data, it is a good entropy gatherer. So just grab a few frames from the webcam, hash them with a secure hash function (SHA-256), and write that into /dev/urandom. This is still big overkill.

Answer 3

1) You don't need to add any more entropy to /dev/random, to use it for passwords. The system already does that for you.

2) To generate a random password, it's better to use /dev/urandom, not /dev/random. (/dev/random has some issues: it blocks, it depletes the entropy pool in a way that may cause other users of /dev/random to block. /dev/urandom is the better general-purpose interface.)

3) Here's a simple script I use to generate a random password. You're welcome to use it.

#!/bin/sh
# Make a 48-bit password (8 characters, 6 bits per char)
dd if=/dev/urandom count=1 2>/dev/null | base64 | head -1 | cut -c4-11 

Answer 4

The best value I've seen in a HW randomness device is the simtec entropy key.
Has a number of safeguards built in to protect against failure and attacks. For example, it runs the FIPS 140-2 randomness tests on each batch of 20Kb, shutting itself off if a statistically significant number of tests fail. I got one when I was doing a lot of key generation for DNSSEC research, and it greatly sped up my work. It passes all the dieharder tests. (note, always test your randomness streams periodically, no matter what the vendor tells you ;-)

Answer 5

I know of audio entropy daemon and havege which is used by haveged daemon, try them out.

Answer 6

GUChaos.c retrieves random numbers from random.org, and changes them on-the-fly through a substitution cypher before feeding /dev/random.

Answer 7

You can use random.org's api and use the number to create passwords.

Answer 8

Passwords, if they are short, are always crackable by brute force if the speed or count of tries is not limited. If, on the other hand, tries are limited (eg. interactive login), even a small amount of entropy basically uncrackable - the amount of tries required becomes prohibitive really soon.

So, there should be no cases where getting really good entropy for passwords would matter.

So just use /dev/urandom, it's more than good enough.

The other answers given here are good comments on how to keep your /dev/random supplied with enough entropy, though, if you need it.