I'm logged onto a VM remotely and trying to generate a 4096bit PGP key, it just hangs forever because there is no entropy and since I'm working through remote desktop it probably does not detect the mouse movement as entropy.
How can I generate some?
I tried cat /dev/urandom > /dev/null but that doesn't help.
Getting data out of /dev/random or /dev/urandom is definitely not going to help, all it will do is deplete your entropy pool, making the issue even worse. The main difference between these two files is that even when the kernel runs out of entropy urandom will keep generating random data of lesser quality, while random will block until it can gather fresh high-quality random data. PGP requires the highest possible random data to generate secure keys, so it will always use /dev/random.
If you have good random data around, or export some from another server's /dev/random, you can cat it into your server's /dev/random to get more entropy. You should never cat the same file twice into /dev/random though.
If you often find yourself running out of entropy you can also consider installing something like haveged, a daemon that re-generate entropy in the background and re-fill /dev/random as needed.
Also it can be tempting to symlink /dev/random to /dev/urandom, but this should be considered a security risk as any key generated using it may be less secure than they should. While it may help for one less critical applications, you have to consider every other possible use of /dev/random, including other users generating their own keys, CSR, etc.
/dev/random is a high-quality PRNG, and should not normally block.
/dev/random are high quality PRNG on modern BSD and Linux, sure. But it will block if there is not enough entropy available. On the other side, /dev/urandom will not block if there is not enough available but its randomness quality might suffer in this case. In the details there are many subtleties between random and urandom implementations between Linux and the various BSDs, but the above should be true on all AFAIK.
ping 8.8.8.8) if you own another network host try to have pings every 100ms (if your RTT is <100ms of course ). And/or use find to look for files on your hard disk and flush the RAM cache between each file search.
/dev/random does not block on FreeBSD.
dd if=/dev/random of=/tmp/rndtest bs=64M count=1 after a fresh boot, it took 2 consecutive runs to see the time to generate the 64MB file increase. I thought I would not see this effect with urandom as input, but FreeBSD seems to be blocking as well with it, unlike Linux.
You can use haveged.
haveged is a daemon that generate entropy when needed.
I would recommend to generate your gpg keys on your local machine which will have much better randomness than the remote one. And then migrate the keys using SSH to your remote machine.
Generating locally will be faster (more source for entropy), more secure (no one can spy on the process if your machine is not infected, better randomness).
If you still want to generate those remotely: On Linux you can generate more entropy by simply pinging a host (e.g. ping 8.8.8.8) if you own another network host try to have pings every 100ms (if your RTT is <100ms of course ). And/or use find to look for files on your hard disk and flush the RAM cache between each file search.
You could also installed haveged but read the limitations if you are running it in a virtual environment: https://wiki.archlinux.org/index.php/Haveged#Virtual_machines
On Debian based systems, you can install the rng-tools package using atp-get, and then start the daemon to generate entropy:
echo HRNGDEVICE=/dev/urandom >> /etc/default/rng-tools && service rng-tools restart
On CentOS-6 servers, the rng daemon is installed as one of the base tools (at least on most systems I've worked on it is), and you can run the following command to start it, in order to generate entropy:
sed -i \'s|EXTRAOPTIONS=\"\"|EXTRAOPTIONS=\"-r /dev/urandom\"|g\' /etc/sysconfig/rngd && service rngd restart
sudo yum install haveged && sudo systemctl start haveged
definitely works on a CentOS 7.2 VM. Sometimes you want to create GPG keys on a vm if you're creating a bunch and want your keyring intact.
/dev/random and /dev/urandom are writable. If you write entropy to them, your entropy pool grows. cat /proc/sys/kernel/random/entropy_avail grows.
You may wirte any kind of data to /dev/urandom.# cat MyWordDocument.txt > /dev/urandom done as root! This is not a good source- but it is one source. If you write many of your documents (thousands of them) to /dev/urandom this will be a better source of entropy - but not a high quality type of entropy. If one would write .jpeg or .png or all his Data in /home to /dev/urandom it depends on the 'Mix' of the Data how good the generated entropy is.
ls -RU ~ | xargs -i cat {} > /dev/urandom will not work on bash- you need perl's <>. cp -RT ~ /dev/urandom will not work too. If you would do that in a script hourly with cron your entropy pool looks fine but it is poisoned with copies of the same thing, on and on.
If you write good entropy to /dev/random too (from your PC - generated with cat /dev/random > entropy.txt CTRL+C) you will get a good mix. But your PC is out of entropy then - dangerous on the internet. So never do this when being online.
Generate these .txt files offline and store them (I do that when my work is finished for the day). Your random seed may become poor - but if you play around with your mouse - put some CD's in your drive - play some of the build-in games (Tetris...) you generate new entropy. - The best solution is to buy a Geiger-counter and a radioactive source to do the job. Entropy sources for server farms. Up 10.000 bugs only.
So try to generate the pgp-key on a machine with good sources of entropy, like your PC in your office. Your /home on the virtual machine is empty - I think. If you got real change of data on that virtual machine, use that data in a intelligent way. Do a du -h "'/srv/Data~'" or something like that. List it with ls; cat ./* ; dd ; ... - Play around with it - and get some "good" entropy.
In professional hosting your hosting provider gives you a well tested and clean source of entropy - I hope so - do not cut this by extreme firewalling and isolating the virtual machine to that specially made source. You become a cryptographic Zombie on the internet. (Ask the hosting provider how it is done on their servers.)
