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

Version 1.0
Author: Falko Timme
Follow me on Twitter

You might know this situation: you want to generate a GPG or SSL key, and during that operation, your system tells you that no more random bytes are available and that it needs to collect more entropy, and you are stuck. This short guide tells you how to solve this problem with the package rng-tools on Debian Lenny.

I do not issue any guarantee that this will work for you!

1 Preliminary Note

Let's assume you want to generate a GPG key:

gpg --gen-key

If you are unlucky, the command might stop in the middle with a message like this:

Not enough random bytes available. Please do some other work to give
the OS a chance to collect more entropy! (Need 284 more bytes)

So we have to increase entropy somehow. This can be done with rng-tools, a package to use a hardware true number generator (TRNG). Don't worry, you don't need any extra hardware, we will use /dev/urandom as our true number generator.

2 Installing And Configuring rng-tools

The rng-tools package can be installed as follows:

apt-get install rng-tools

Next open /etc/default/rng-tools...

vi /etc/default/rng-tools

... and add the line HRNGDEVICE=/dev/urandom:

# Configuration for the rng-tools initscript
# $Id: rng-tools.default,v 1.1.2.5 2008-06-10 19:51:37 hmh Exp $

# This is a POSIX shell fragment

# Set to the input source for random data, leave undefined
# for the initscript to attempt auto-detection.  Set to /dev/null
# for the viapadlock driver.
#HRNGDEVICE=/dev/hwrng
#HRNGDEVICE=/dev/null
HRNGDEVICE=/dev/urandom

# Additional options to send to rngd. See the rngd(8) manpage for
# more information.  Do not specify -r/--rng-device here, use
# HRNGDEVICE for that instead.
#RNGDOPTIONS="--hrng=intelfwh --fill-watermark=90% --feed-interval=1"
#RNGDOPTIONS="--hrng=viakernel --fill-watermark=90% --feed-interval=1"
#RNGDOPTIONS="--hrng=viapadlock --fill-watermark=90% --feed-interval=1"

Now start the rng-tools daemon:

/etc/init.d/rng-tools start

That's it! Now try to generate your key again, e.g.

gpg --gen-key

... and it should finish successfully:

We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
.++++++++++++++++++++..+++++++++++++++++++++++++++++++++++++++++++++++++++++++.+++++
.+++++..+++++.+++++++++++++++++++++++++++++++++++++++++++++.....>.+++++<+++++.....
...>+++++................................+++++
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
+++++.++++++++++..++++++++++...++++++++++...+++++.+++++..+++++.+++++..+++++++++++++++.+++
++++++++++++..+++++++++++++++..++++++++++..+++++++++++++++++++++++++...+++++..+++++>+++
+++++++>.+++++>+++++......................+++++^^^
gpg: key 1F6C9247 marked as ultimately trusted
public and secret key created and signed.

gpg: checking the trustdb
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0  valid:   2  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 2u
pub   1024D/1F6C9247 2010-12-06
      Key fingerprint = FC81 D8E3 8090 EEE3 1D98  E000 045C D80E 1F6C 9247
uid                  Falko Timme <[email protected]>
sub   2048g/12D6A5B0 2010-12-06

server1:~#

3 Links

Debian: http://www.debian.org/

view as pdf | print

Share this page:

24 Comment(s)

Add comment

Comments

By: perrabyte

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.

By: Anonymous

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?

By: Anonymous

What mouse?!!

By: moonlitdog

/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 :)

By: hulk

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

By: Anonymous

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.

By: Steve McIntyre

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

By: Anonymous

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.

By: Anonymous

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.

By: DayLove

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

By: Julien

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.

By: Aaron Toponce

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.

By: a-non.Y.mouse

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

By: Multivac

Yes, but can it be reversed?

By: Anonymous

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?

By: Anonymous

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.

By: Jack O'Connor

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/

By: Tom

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.

By: Murks

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

By: irv

Thanks! Quite helpful.

By: Hydranix

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

By: hunter86_bg

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.

By: DonMcCoy

/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/

By: [OvO]wl

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

Log in or Sign up

On this page