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

Want to support HowtoForge? Become a subscriber!
 
Submitted by falko (Contact Author) (Forums) on Fri, 2010-12-10 16:19. :: Debian

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

Version 1.0
Author: Falko Timme <ft [at] falkotimme [dot] com>
Follow me on Twitter
Last edited 12/06/2010

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:

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

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 <ft@falkotimme.com>
sub   2048g/12D6A5B0 2010-12-06

server1:~#

 

3 Links


Please do not use the comment function to ask for help! If you need help, please use our forum.
Comments will be published after administrator approval.
Submitted by Anonymous (not registered) on Mon, 2014-07-28 00:28.
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.
Submitted by Multivac (not registered) on Fri, 2013-01-04 22:49.
Yes, but can it be reversed?
Submitted by Anonymous (not registered) on Sun, 2013-09-29 00:04.

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?

Submitted by a-non.Y.mouse (not registered) on Sun, 2012-01-15 20:52.

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

Submitted by Julien (not registered) on Wed, 2011-04-06 11:18.

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. 


Submitted by Aaron Toponce (not registered) on Fri, 2012-08-17 03:08.

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.

Submitted by Anonymous (not registered) on Mon, 2010-12-20 22:44.

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.

Submitted by Anonymous (not registered) on Tue, 2011-01-11 16:22.

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.

Submitted by DayLove (not registered) on Wed, 2011-01-12 21:12.

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

Submitted by Steve McIntyre (not registered) on Tue, 2010-12-14 15:26.

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

Submitted by Anonymous (not registered) on Mon, 2010-12-13 23:46.
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?
Submitted by Anonymous (not registered) on Mon, 2013-04-22 15:15.
What mouse?!!
Submitted by moonlitdog (not registered) on Mon, 2010-12-13 17:55.

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

Submitted by hulk (not registered) on Mon, 2010-12-13 02:26.
I had a feeling that it was a bad idea too.
Submitted by Anonymous (not registered) on Fri, 2010-12-10 22:53.

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.

Submitted by perrabyte (not registered) on Tue, 2010-12-14 09:21.

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.