94

I've got a ton of processes running in the background to try and get enough entropy, but I am still failing.

**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 210 more bytes)**

I need a method to generate the key that works, cause what I'm trying to do is failing apparently.

Glorfindel
  • 1,213
Joey BagODonuts
  • 1,635

9 Answers9

123

Have you had a look at RNG?

Fedora/Rh/Centos types: sudo yum install rng-tools

On deb types: sudo apt-get install rng-tools to set it up.

Then run sudo rngd -r /dev/urandom before generating the keys.

Reference: http://it.toolbox.com/blogs/lim/how-to-generate-enough-entropy-for-gpg-key-generation-process-on-fedora-linux-38022

Danny Staple
  • 1,494
  • 4
    Also, on a more serious note, you can use sudo apt-get install rng-tools if you're on Ubuntu instead of sudo yum install rng-utils like they have for Fedora, since no rng-utils package exists for Ubuntu. – Jason Swett Jan 17 '11 at 17:50
  • I tried this as root and got "can't open /dev/random: Permission denied" any thoughts on that? – Darren Newton Mar 12 '11 at 21:40
  • 4
    The package is named rng-tools on both Fedora and EL6, so I suspect a typo in the linked article. BTW, it is a good idea to provide the essential parts of the answer here, and the link for reference, in case the link goes dead in the future. – Michael Hampton Dec 31 '12 at 02:40
  • Perfect, thank you! I was trying to add entropy manually by feeding things into /dev/random, but the kernel entropy level in /proc/sys/kernel/random/entropy_avail was just hovering around 50 bits and not moving. Running rngd immediately boosted it to 3000 bits. Perfect for a class of 10 people generating 4096-bit gpg keys at the same time. Thanks again! – qris May 29 '15 at 09:50
  • 11
    There is no "low-quality entropy" or "fake entropy" in urandom. urandom calls the same code as /dev/random. There is no need to feed additional randomness into the CSPRNG (except at boottime, and there your distribution should take care of it). This is a myth and should not be propagated. See for example sockpuppet.org/blog/2014/02/25/safely-generate-random-numbers or this video: media.ccc.de/v/32c3-7441-the_plain_simple_reality_of_entropy – Sebastian Wiesinger Dec 30 '15 at 11:30
  • 7
    Here's another good one on the urandom myth. – Andrew B Dec 31 '15 at 15:46
  • 2
    Most high voted comment is nonsense; unfortunately I see this a lot on SO. Warnings (even when completely wrong) will get a lot of votes and no way to correct them (no comment downvote option) means we can't get rid of the myths. – Stijn de Witt Jun 27 '17 at 08:04
  • 3
    Basically GPG is broken for reading from /dev/random, then blocking, i.s.o from /dev/urandom which never blocks. The web is filled with questions about it. – Stijn de Witt Jun 27 '17 at 08:06
  • works like a charm. whereas my attempts to do it with stress and dd failed. – Michael Martinez May 15 '19 at 23:52
29

I was able to generate the key by

apt-get install rng-tools

In another SSH window open

 gpg --gen-key

Go back to your first SSH session and run 

sudo rngd -r /dev/urandom

Let this run till gpg generates your keys!

user123456
  • 583
Joey BagODonuts
  • 1,635
  • 9
    I would definitely recommend against ever using /dev/urandom for generating keys of any importance. – Andrew Barber Dec 21 '10 at 07:09
  • 14
    @AndrewBarber Nonsense. It is the recommended method. – David Schwartz May 25 '16 at 19:39
  • 3
    @AndrewBarber It's explicitly designed for that purpose. Basically, /dev/random is a design mistake. It should only ever block on first (ever) invocation (on first boot) when no entropy whatsoever was collected yet. Like it does on other OS. Instead we got two pools now. Just never use /dev/random it has no advantages. – Stijn de Witt Jun 27 '17 at 08:09
  • 1
    @AndrewBarber what would you recommend instead? – qodeninja Aug 14 '18 at 22:23
14

To check the amount of bytes of entropy currently available, use

cat /proc/sys/kernel/random/entropy_avail

The entropy bucket is 4096 bytes large, which can very quickly be depleted.

Using this small 'readspeed' tool (http://1wt.eu/tools/readspeed/), you can measure how fast the entropy bucket is filled with different methods.

For example, launch :

$ ./readspeed < /dev/random

and move your mouse around. You will see that 'readspeed' empties the entropy bucket as soon as it is filled, and when you move the mouse, it fills up a bit.

Trying different methods, it seems that keyboard input and mouse movements are the most efficients to replenish that bucket. Network transfers and hard drive copies don't have much influence.

Finally, there are entropy generation devices available, such as this one: http://www.entropykey.co.uk/.

Julien Vehent
  • 3,017
  • 4
    There is no "low-quality entropy" in urandom. urandom calls the same code as /dev/random. This is a myth and should not be propagated. See for example http://sockpuppet.org/blog/2014/02/25/safely-generate-random-numbers/ or this video: https://media.ccc.de/v/32c3-7441-the_plain_simple_reality_of_entropy – Sebastian Wiesinger Dec 30 '15 at 11:29
  • This answer is 5 years old. We thought urandom wasn't as safe as random then, but things have changed since and urandom is considered safe. – Julien Vehent Dec 31 '15 at 15:10
  • 3
    Fact is it was safe from the beginning. The warnings were wrong 7 years ago as well. – Stijn de Witt Jun 27 '17 at 08:11
10

+1 for rng-tools

In case you are stuck in situation as I am - not having permissions to install new software (rng-tools) on a headless server with virtually no input hardware (sound card, keyboard, mouse) attached. You can run this simple code from another terminal connect to same server, to add to the entropy. It does not matters if you start running this before or after starting gpg --gen-key

$ nice -n 19 bash
$ until [ $COUNT -lt 1 ]; do
  let COUNT=`cat /proc/sys/kernel/random/entropy_avail`
  echo "`date` COUNTER $COUNT"
done

First line is to start a new bash shell, with lower priority (I needed to be nice on a server shared by many users). The until loop is infinite, so remember to break it once the key is generated. All it is doing is causing the network traffic to increase the entropy. It also monitors the entropy_avail counter to show how it gets filled and emptied on other side by gpg. In my case, the counter filled up quickly to 64 and got emptied back to 0 (guess gpg picks up in chunk of 64). I was waiting for 4096 bit key generation for over 3 hours on the server. After starting to run this script, it got finished in under 5 min.

Patrick Mevzek
  • 10,181
Raj
  • 101
  • I too didn't have root access on the remote server and this worked in creating some entropy. I think the condition should be changed to [ $COUNT -lt 0 ]. Because for a system with really less entropy, it reaches 0 sometimes and stops. GPG is really entropy hungry. – Ajay Brahmakshatriya Oct 18 '18 at 23:58
  • Thanks, this should be plenty for me to make some entrophy generation on an airgapped box. Except I won't use date since that's predictable – grepsedawk May 24 '19 at 19:45
7

I was bound and determined to generate entropy on my headless Ubuntu 14.04 server in order to generate a 4096 key with gpg --gen-key

There is a package for generating entropy called haveged. Example of install:

sudo apt-get install haveged

I had to sudo apt-get install rng-tools since it is a dependency in the following test.

Example of a test to see if entropy is generated by haveged:

cat /dev/random | rngtest -c 1000

A very small amount of failures is acceptable in any random number generator, but you can expect to see 998-1000 successes very often when using hovered.

I found out about it in a tutorial here:

https://www.digitalocean.com/community/tutorials/how-to-setup-additional-entropy-for-cloud-servers-using-haveged

I now have keys after running gpg --gen-key

dmmfll
  • 171
4

haveged is the best way, but if you cannot install anything, then you can manually generate entropy. This method allowed gpg --gen-ken to complete in 1-2 mins on my machine (compared to 10s with haveged). So it's about 10x slower.

Run this in another terminal while gpg --gen-key is running:

while true; do
    # print entropy available
    cat /proc/sys/kernel/random/entropy_avail
    # write a 1 MB stream of zeros to /tmp/foo
    # "conv=fdatasync" flushes the disk cache
    dd bs=1M count=1 if=/dev/zero of=/tmp/foo conv=fdatasync
done

One liner:

while true; do cat /proc/sys/kernel/random/entropy_avail; dd bs=1M count=1 if=/dev/zero of=/tmp/foo conv=fdatasync; done
wisbucky
  • 1,129
1

Well, seems easier than it seems:

ls -R /

The random bytes provided by the command above, are sufficient to provide the required entropy for generating a RSA/4096 key pair.

Taken from: https://www.thingy-ma-jig.co.uk/blog/22-01-2010/generate-entropy-gnupg

ivanleoncz
  • 1,721
0

(Please consider other answers first.)

The real reason can be covert: A GUI window pop up to ask for the passphrase, which can't be seen through SSH. You don't react and time is out.

Detail: I gpg --full-generate-key on Raspberry Pi OS (a Debian-based Linux) through SSH, but get stuck at key generation timeout. Finally, I connect to it by VNC (Virtual Network Computing), and everything becomes clear.

To install VNC, you can follow Raspberry Pi Documentation:

$ sudo apt update
$ sudo apt install realvnc-vnc-server realvnc-vnc-viewer
$ sudo raspi-config  # And navigate to Interfacing Options → VNC → Yes.
Y.D.X.
  • 1
0

I ran into this issue when running pacman-key --init in arch. The other solutions here didn't work well for me, but I found that simply flood-pinging my router worked nicely: ping -f ip.of.my.router

Yona Appletree
  • 121