Comments on Helping The Random Number Generator To Gain Enough Entropy With rng-tools (Debian Lenny)

I would take it a step further, calculated random looking numbers are a bad idea altogether.

I had an idea that you could just sample the environment. For a web encryption application where you dont have access to much random bits from the user. Why not utilize the noisy webcam to get a one time hash of a picture or a video. Taking a series of hashes from the pictures you could make sure the are not static.

 This could be used for encrypting mail over a webform, gpg.

There's a reason it doesn't pull from /dev/urandom by default (like the other commenters mentioned). Can you really not afford to move your mouse around a little?

What mouse?!!

/urandom is an algorithm based on, and used when /random is out of entropy. Strictly speaking, it is not a source of entropy, nor is it a 'true random number generator'. So your generated keys may not be truly secure.

This hack would get the job done, more quickly too, but should only be used for less-secure items. Though I suppose, using this only depends on your paranoia level :)

I had a feeling that it was a bad idea too.

This is a BAD IDEA!  /dev/urandom is not a good source of entropy; the keys you will create by this method cannot have more entropy than the random seed used to generate output from /dev/urandom.

 You might think that's not a problem; that your key will be "good enough".  However, I would argue that anyone who wants GPG wants a crypto solution that you can't break easily, and generating keys from /dev/urandom simply doesn't cut it.  The folks who wrote GPG knew this, which is why they didn't just pull pseudorandom bits from /dev/urandom in the first place.

/dev/random is designed to block when the system is short of entropy; /dev/urandom simply pulls from that same entropy pool but will use a PRNG rather than block when available entropy is exhausted. Feeding the data from /dev/urandom back into the system will give you a false sense of security, as your "random" numbers won't be. You really don't want to be doing this for security-conscious applications like generating gpg keys...

If you really want fast, reliable, random randomness then find a real hardware RNG. Some motherboards have them on-board, otherwise try an Entropy Key, developed by friendly Free Software geeks (Debian developers) and well supported for a variety of platforms.

It's a real problem unable to create gpg keys on any headless debian/ubuntu servers.  Some people believe servers hosted in datacenter can't be trusted to host private key anyway, but if you are that paranoid your house may not be safer from spies either. 

Anyway on other headless servers (such as centos) there is no such problem creating gpg keys at all.  The Entropy Key solution mentioned above is not open source so who knows it's better than /dev/urandom?

I got an idea, is it possible to draw entropy remotely from another centos server to a debian server?   I don't know how to do that though.

I was just going through this yesterday.

What I did was take a random DVD / CD (DVD has more data) off the shelf and issue this command:

dd if=/dev/sr0 of=/dev/null 

It may or may not solve some of the security concern due to the fact that no-one knows what I did to generate the random bits needed.

Another option that worked for me was installing audio entropy daemon from http://www.vanheusden.com/aed

Make sure you have the alsa lib dev package installed

run: make && install -g 0 -o 0 -m 755 audio-entropyd /usr/sbin/audio-entropyd

Or you can run it from where it is.

For the init.d script included in the download, run it to tweek the errors (very simple, trust me it will work)

To test, run this command: cat /dev/random | rngtest -c 1000

I fully agree with most of the comments: using /dev/urandom to feed /dev/random is a bad idea in terms of security. If your servers block because of a lack of entropy, you should use a hardware RNG to fill your entropy pool.

While Entropy Key is a good solution if you have a small number of servers, our company is currently developping a Harware RNG appliance that can provide good random numbers to many servers simulltaneaously. If you have a large datacenter with a lot of crypto applications running on your severs, you might want to give it a look at www.sqrtech.com. 

Entropy Key is not only a good idea, it's a great idea. It maintains a constant stream of data at about 30 Kbps for a single key. Unless you have a cryptographic data farm, even some of the most busiest HTTPS servers won't be able to exhaust it.

Besides, you don't need to send the random data to every server in the datacenter, only to the servers which actually have exhausted entropy pools.

The Debian project currently has 5 for the entire debian.org infrastructure. It's hard to imagine the average datacenter load would need more than that.

Hello,

I don't like the idea as a whole, but I must say I used this hint once on remote server, where there's really not a chance to do much random actions. 

I tried to simultaneously:

- dd whole partition to /dev/null PLUS something like find / -t file -name *.gz -exec gunzip \{\} >/dev/null \; PLUS some watch PLUS some ps... PLUS grepping few maildirs for some keywords in a loop PLUS I was typing on keyboard, which means also some actions on network card...

Still, I didn't gain enough entropy, so finally I had to use this trick.

 ( Later, I regenerated the key on other machine, but as instant solution mainly for testing, this was good.)

 I have an idea - if anyone knows processes that generate lot of random numbers and can help popullate /dev/(u)random, maybe you could write them here..?

Yes, but can it be reversed?

You need to turn this around. The question is: Can't it be reversed? Using this method can potentially compromise the complete entropy pool and reduce the entropy in the generated keys. Example: If I generate a 1024 bit key using real random numbers, the probability of guessing this key is 1:2^1024. If I generate the same key using a PRNG with an internal state of 32 bits, the key will look random but I only need to check 2^32 keys to break it. Further: If I manage to observe enough keys, I can recover the initial value of the PRNG and guess every further key instantly. So: why run the risk of compromising the system when there are cheap and secure ways around that? The entropy key has been mentioned repeatedly. I like to add a few more: 1. Recording from a microphone inside the server. Cost: 2$ for the mic. Entropy gathered: >20kBps 2. Building your own Hardware RNG connected to a sound card (google will help you to find good circuits). Cost: 5-10$. Entropy gathered: >40kBps Again: Why do the wrong thing, when the right one isn't difficult to do?

As others have pointed this is a pretty bad idea. Just flood pinging the server in question with ping -f will fill the entropy pool eventually as linux randomness generator also takes entropy from the least significant bits of network packet timestamps.

 This isn't quite accurate. Both /dev/random and /dev/urandom use the same CSPRNG. The only difference is that /dev/random blocks waiting for new entropy: http://www.2uo.de/myths-about-urandom/

This is extremely irresponsible advice, for many of the reasons discussed below. A must less dangerous option that would have the desired effect would be just to install haveged, which does a pretty good job at finding real entropy from other sources.

Thx for advice against the proposed method because of security issues, and especially for the hint that some entropy could be gathered from network activity. This was particualarly helpful in my case, when I wanted to create a key pair on a remote server, being not a priviledged user, having no access to the server's hardware, and no HW-RNG being installed on that system

Thanks! Quite helpful.

This is also extremely irresponsible advice. Do not use haveged as a source of secure entropy, only if you have a hardware RNG, but then why even use haveged at all?https://lwn.net/Articles/525459/ http://security.stackexchange.com/questions/34523/is-it-appropriate-to-use-haveged-as-a-source-of-entropy-on-virtual-machines

Passing pseudo-random data to random is not a good idea (security vulnerability). It's better to get a hardware Random Number Generator device instead.

/dev/urandom is secure.

There's great misconception regarding that urandom device is insecure, but it's secure, for your info, random and urandom both use the same randomness generator.I'm not going to say much analyses, but you can securely use urandom, if you have any doubt, check the resposible kernel source code to see how the randomness is being generated.If you're interested in more info, there's a study about the myths of urandom here:https://www.2uo.de/myths-about-urandom/

This article should be removed from the internet, this is a terrible idea.