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.

9 Answers 9


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

  • 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. Jan 17, 2011 at 17:50
  • 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. Dec 31, 2012 at 2:40
  • 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 Dec 30, 2015 at 11:30
  • 7
  • 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. Jun 27, 2017 at 8:06

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!

  • 9
    I would definitely recommend against ever using /dev/urandom for generating keys of any importance. Dec 21, 2010 at 7:09
  • 14
    @AndrewBarber Nonsense. It is the recommended method. May 25, 2016 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. Jun 27, 2017 at 8:09
  • 1
    @AndrewBarber what would you recommend instead?
    – qodeninja
    Aug 14, 2018 at 22:23

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


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

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.

  • 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. Oct 18, 2018 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, 2019 at 19:45

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:


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


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

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

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


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


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

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .