Take the 2-minute tour ×

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?

share|improve this question
I just faced this problem while trying to generate GPG keys on a virtual server. I found that downloading a large ISO (say a linux distribution DVD) adds entropy pretty quickly. –  mehaase Jul 31 at 18:06

9 Answers 9

up vote 13 down vote accepted

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

share|improve this answer
You could do that, I suppose, but why bother? There is no reason to. It's unnecessary. The kernel already feeds /dev/random and /dev/urandom with sufficient entropy for these purposes. Save your time for something that will actually improve security. Or, to put it another way, the question asked whether we would suggest adding extra entropy. The best answer is: No, there's no need to add extra entropy. Just go ahead and use /dev/urandom as is. –  D.W. Jan 17 '11 at 5:57
@D.W. from my experience with VPS servers, where there is no real external entropy source like keyboard, mouse etc, the entropy pool gets very low and it seems to affect things like SSL. It might still work but it feels like things are running slower. After installing haveged (see another answer below), things were running much more smoothly. Perhaps there was something else I could have fixed, or did something wrong, but I'm not sure you can always rely on your kernel as your entropy source... –  Yoav Aner Apr 30 '12 at 9:28
If I remember correctly, a few of the major entropy sources are CPU registers that get modified very frequently to reasonably random values. Unfortunately, virtualisation negatively impacts the randomness of those registers due to more predictable scheduling of threads. A solution is to have a HRNG on the bare metal server, then make it available to the VMs. –  Polynomial Apr 30 '12 at 10:21
@YoavAner, the reason you are having problems is probably because you are using /dev/random. Don't do that. You should use /dev/urandom. Then you won't have those problems -- and it will be secure. See Feeding /dev/random entropy pool?, Is a rand from /dev/urandom secure for a login key?, Pseudo Random Generator is not initialized from the (entropy pool)?. Short version: use /dev/urandom, not /dev/random. –  D.W. Apr 30 '12 at 22:18
Thanks @D.W. I know that urandom should solve this, but I'm not sure all components on my system use it necessarily. For example, it must be some component of lighttpd web server, or openssl or who-knows-what that were getting funny. –  Yoav Aner Apr 30 '12 at 22:31

I use a combination of data sources and a good hashing algorithm to generate random data.

On a web-server you can combine server data (HW, SW, performance), client data (user-agent, request-time, cookie, URL variables, whatever you can gather), some external data (like random.org), mix everything with let say sha1(mixed_data + time + some_secret_key) and you get fairly unpredictable bits of random data.

You could also consider using P2PEG to easily collect entropy from clients and server.

share|improve this answer

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

share|improve this answer

It is weird to see a bunch of recommendation to use /dev/urandom instead of using /dev/random cause when /dev/random depletes then /dev/urandom uses the last entropy repeatedly what is strongly unsecure for long term critical parameters.

share|improve this answer
You should read these recommendations! Especially Thomas Pornin's. You're misunderstanding entropy. Reading from /dev/random or /dev/urandom doesn't deplete entropy (at least not on a scale that would matter: reading 2^n bits depletes at most n bits of entropy). –  Gilles Aug 13 '13 at 20:40
Do you real think that the entropy an operating system may obtain is inexhaustible? –  Buktop Aug 13 '13 at 21:12
"Generating true entropy in a computer is fairly difficult because nothing, outside of quantum physics, is random. The Linux kernel uses keyboard, mouse, network, and disc activities, with a cryptographic algorithm (SHA1), to generate data for the /dev/random device. One of the problems with this is that the input is not constant, so the kernel entropy pool can easily become empty. The /dev/random device is called a "blocking device". This means if the entropy pool is empty applications trying to use /dev/random will have to wait, indefinitely, until something refills the pool." –  Buktop Aug 13 '13 at 21:13
"A read from the /dev/urandom device will not block waiting for more entropy. As a result, if there is not sufficient entropy in the entropy pool, the returned values are theoretically vulnerable to a cryptographic attack on the algorithms used by the driver." –  Buktop Aug 13 '13 at 21:15

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.

share|improve this answer
I should -1 you for having the audacity to suggest that any deity would use an iPad. Everyone knows God uses the Holy PSP. –  Polynomial Apr 30 '12 at 9:29
Your god, maybe. My god uses an iPad, and furthermore has instructed me that so should you. –  jakev Sep 30 '12 at 23:17
god has nothing to do with it, does any one see the problem of people booting from virtual machines that are the theoretical "seed" image running over a range of not that long –  James Andino Dec 11 '13 at 3:30

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.

# Make a 48-bit password (8 characters, 6 bits per char)
share|improve this answer
your 1) and 2) are opposite to each other -> /dev/random depletes... that is exactly why I asked how to additionaly feed it.. –  pootzko Jul 14 '11 at 12:56
You are confusing two things. /dev/random is secure enough for password generation without additional entropy - so feeding stuff in to /dev/random is not needed for security, but it might be needed for performance. /dev/urandom is also secure enough for passwords, but it does not have the performance problem /dev/random has, so it should be preferred. –  Nakedible Aug 3 '11 at 9:19

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.

share|improve this answer
This answer is not accurate in practice, or is worded in a confusing way. In practice, one can choose passwords with sufficient entropy that they are not crackable by brute force. Or, to put it another way, in practice attackers are always limited in how many tries they can make, simply by the limited time available to them. I agree with the advice to use /dev/urandom instead of /dev/random, but the justification isn't right. –  D.W. Jan 17 '11 at 5:48

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

share|improve this answer
Those are unnecessary. The kernel already feeds /dev/random and /dev/urandom with sufficient entropy for these purposes. –  D.W. Jan 17 '11 at 5:53
@D.W. it does not, they did someyhing with the (Linux) kernel so it's not working any more as it used to (gets depleted very fast)... –  pootzko Jul 14 '11 at 12:58
@pootzko, I don't believe it. I suspect you are misinterpreting what you are seeing. /dev/urandom never gets depleted. –  D.W. Jul 15 '11 at 5:57
first of all, I tested all this (monitoring entropy while using different methods, so when the entropy drops down rapidly to some very low values - it means it got depleted). second, I read a lot about it all at the time of asking the question - kernel handled all this differently some time ago. third - these are your words "/dev/random has some issues: it blocks, it depletes the entropy pool" :)) –  pootzko Jul 15 '11 at 6:38
+1 for haveged. From personal experience primarily with virtual servers, which do not have a keyboard or mouse attached, and can't have a microphone easily connected either, haveged really makes sure things are running smoothly. How strong its PRNG is, it's hard for me to say, but it sounds reasonably safe (particularly compared to just relying on urandom) –  Yoav Aner Apr 30 '12 at 9:22

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

share|improve this answer
HW randomness is probably overkill. /dev/urandom is perfectly adequate for this application, without anything else fed in. –  D.W. Jan 17 '11 at 5:53

Your Answer


