gpg --key-gen doesn't have enough entropy and rng-tools install/start fails

[Jon Stevens]

Binary package hint: gnupg

Description: Ubuntu 10.04.1 LTS
Release: 10.04

If you install gpg and then type: gpg --gen-key, it 'freezes up' during the entropy gathering phase.

....
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 278 more bytes)
....
(freeze here)

I found some reference on the interwebs suggesting to install rng-tools so that the rngd daemon can gather more entropy for the system because by default cat /proc/sys/kernel/random/entropy_avail has a very very low number.

Thus, installation of rng-tools, fails to start the rngd daemon...

Setting up rng-tools (2-unofficial-mt.12-1ubuntu3) ...
Trying to create /dev/hwrng device inode...
Starting Hardware RNG entropy gatherer daemon: (failed).
invoke-rc.d: initscript rng-tools, action "start" failed.

It is then required to do this: echo "HRNGDEVICE=/dev/urandom" >> /etc/default/rng-tools
and then start rngd: /etc/init.d/rng-tools start

After this process is done, gpg --gen-key is immediate...

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

And cat /proc/sys/kernel/random/entropy_avail has a much higher number.

All in all, I think this process should be simplified by maybe making gpg depend on rng-tools. The whole reason why I need to generate a gpg key is because I want to sign the .deb debians that I'm creating for my repository.

Thanks for your time.

[Daniel Leidert (dleidert-deactivatedaccount)]

gpg does not freeze, even if you think so. It just waits until enough entropy has been collected and this might take some time depending if you follow the instructions or not.

We won't depend nor recommend rng-tools (see 7.2 in the Debian policy) - hundreds and thousands of people created their keys without rng-tools. There might be a chance, that we suggest it. We'll check it.

[Daniel Silverstone (dsilvers)]

The method described here thoroughly and completely misses the point of entropy.

urandom is not a source of entropy, and using it to seed random via rngtools is a dangerous activity to recommend; let alone to default to.

Better that the user follow the instructions and wiggle their mouse/keyboard if they have insufficient entropy. It's not like gpg doesn't tell the user what to do.

gpg shouldn't even suggest rng-tools, because the vast majority of people do not have a true hardware RNG which it can properly take advantage of.

If you want a more thorough understanding of why this method is bad, please learn about entropy and random numbers properly, and then read about the internal architecture of Linux's random/urandom pair.

[Jon Stevens (latchkey-gmail)]

Wow, I feel like there is a lot of hostility in these responses. Is that really necessary?

I'm sorry, but I've tried this on both a vmware esx server instance and a VM (in VMware Fusion) on my local desktop in a shell window. In both cases, the result was the same. I let it sit for *hours* and nothing happened. Ask google, other people are having the same issue.

Since this is in a shell console, there is no mouse to move. Typing in data does nothing despite the message suggesting that it would. If that was a valid suggestion, I would have not bothered posting an issue here.

It takes only a few minutes to boot up an Ubuntu 10.4.1 image in vmware to duplicate this issue. Did you try that before suggesting that it works for 'hundreds and thousands of people' (btw, where did you get that metric from)?

If you have a better solution than using, I'm all ears, but simply saying "learn about entropy" is not being part of the solution. I'm just reporting on what worked for me. I don't really care if my key isn't perfectly random as all I'm doing is trying to sign debian packages that I'm creating and I'd like the process for creating these keys to be a bit easier to document.

Have a nice day.

[Steve McIntyre (steve-mcintyre)]

If you don't care about randomness when creating a GPG key, then you should not be using one. Reducing the entropy used when creating a key makes it *much* weaker. Are you planning on uploading your signed packages anywhere?

[Jon Stevens (latchkey-gmail)]

No. It is an internal corporate repo sitting behind a firewall. In my eyes,
the only point of creating the key and signing the packages is so that
apt-get/aptitude doesn't cry like a baby (require me to type 'Yes') when I'm
installing software on the servers.

Anyway, way to miss the whole point of this issue which is that, out of the
box, Ubuntu doesn't produce enough randomness on its own for gpg --gen-key
to work properly. It is also amazing to me that a package called rng-tools
doesn't produce the 'correct' type of entropy. Why is it included in the
repositories then? Maybe you can enlighten me with your infinite wisdom
about how this daemon doesn't do the job well enough. I mean, is it
outputting all AAAAAAAAAAAAAAAAA or something?

jon

On Sat, Jan 22, 2011 at 4:04 AM, Steve McIntyre
<email address hidden>wrote:

> If you don't care about randomness when creating a GPG key, then you
> should not be using one. Reducing the entropy used when creating a key
> makes it *much* weaker. Are you planning on uploading your signed
> packages anywhere?
>
> --
> You received this bug notification because you are a direct subscriber
> of the bug.
> https://bugs.launchpad.net/bugs/706011
>
> Title:
> gpg --key-gen doesn't have enough entropy and rng-tools install/start
> fails
>
> Status in “gnupg” package in Ubuntu:
> New
>
> Bug description:
> Binary package hint: gnupg
>
> Description: Ubuntu 10.04.1 LTS
> Release: 10.04
>
>
> If you install gpg and then type: gpg --gen-key, it 'freezes up' during
> the entropy gathering phase.
>
> ....
> 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 278 more bytes)
> ....
> (freeze here)
>
> I found some reference on the interwebs suggesting to install rng-
> tools so that the rngd daemon can gather more entropy for the system
> because by default cat /proc/sys/kernel/random/entropy_avail has a
> very very low number.
>
> Thus, installation of rng-tools, fails to start the rngd daemon...
>
> Setting up rng-tools (2-unofficial-mt.12-1ubuntu3) ...
> Trying to create /dev/hwrng device inode...
> Starting Hardware RNG entropy gatherer daemon: (failed).
> invoke-rc.d: initscript rng-tools, action "start" failed.
>
> It is then required to do this: echo "HRNGDEVICE=/dev/urandom" >>
> /etc/default/rng-tools
> and then start rngd: /etc/init.d/rng-tools start
>
> After this process is done, gpg --gen-key is immediate...
>
>
> 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, ut...

[aporter (aporter)]

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

I, like Nick, am trying to use gpg remotely. So I can't move my mouse or use my keyboard. Also, like Jon, I'm sitting here for minutes (hours?) waiting. For some reason, the "ls -R /" trick isn't working for me. Maybe something changed about /dev/random or gpg? Since the software says "utilize the disks" and that doesn't work, this is probably a bug or a misconfiguration, right?

adrian

[Steve McIntyre (steve-mcintyre)]

If you want to create a useful, valid (i.e. secure) gpg key, then you need a good source of entropy. There is no way around that. If you're working on a remote or virtual machine or with limited inputs into the random pool, then there are a couple of ways of improving that:

1. Generate the key on another machine that *does* have good entropy sources (e.g. on a desktop machine)

2. Find another way to add more entropy to your machine, for example a hardware RNG such as the entropy key (http://www.entropykey.co.uk/) The rng-tools package is explicitly designed to interface with this kind of hardware, to cope with the case where the hardware might not be usable directly with the kernel random pool. When used that way, rng-tools will provide the right kind of entropy; it's not capable of generating entropy where none exists already.

It's unfortunate that your systems are not generating enough entropy for gpg to work well for you these days; you may be able to make it work better by explicitly choosing a smaller key size. Recent linux systems use entropy more than ever before due to ASLR (http://en.wikipedia.org/wiki/Address_space_layout_randomization) which won't be helping you.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Thijs Kinkhorst (kink)]

As per bug log, I don't think this is an issue in GnuPG

[Jon Stevens (latchkey-gmail)]

Please re-open. Per the original report and the discussion, this isn't a bug in gnupg, it is a bug in Ubuntu.

[Marc Deslauriers (mdeslaur)]

This isn't an issue in gnupg, and this isn't an issue in Ubuntu.

To generate a key, you need to have entropy. To get kernel entropy, you need to perform activity. There is no way to generate a key on a machine that doesn't have any entropy. Either generate entropy by generating disk activity, typing at the keyboard and moving the mouse, or generate your keys on a machine that _does_ have some entropy. Alternatively, you may use a hardware entropy gathering device.

[Jon Stevens (latchkey-gmail)]

Wow Marc, I'm not going to repeat the discussion above, but clearly you haven't read it.

[Marc Deslauriers (mdeslaur)]

What part didn't I read?

[Steve Beattie (sbeattie)]

aporter,

The likely reason 'ls -R /' doesn't generate enough entropy for you is that the only thing going to be read from the filesystem is the contents of all the directories and perhaps some metadata on the files themselves, which in a minimal filesystem may not generate sufficient disk activity to capture enough entropy. Furthermore, your system may have enough RAM that your system may have already cached most of the directory tree into kernel memory, meaning that little disk activity is generated by this command.

When I need to generate entropy in one of my remote vms and I don't have access to an entropy key device, I usually do something like

  find /var/ /usr /lib /srv -type f -print0 | xargs -0 cat > /dev/null

possibly within a loop (but the contents of my disk will be larger than the memory allocated to the VM, ensuring that performing the find command multiple times will continue to generate disk activity; the VM won't be able to cache all of the disk's contents in memory).

[aporter (aporter)]

Steve,

This bug ticket is from over a year ago. But I tried "ls -R /", and it still doesn't work. I.e. I'm still sitting at "Need 277 more bytes" indefinitely.

I also tried your line: "find /var/ /usr /lib /srv -type f -print0 | xargs -0 cat > /dev/null"

Well, actually my /var /usr /lib and /srv can fit into my disk cache, so that line ran in <1second after the first run.

So I tried find ~ -type f -print0 | xargs -0 cat > /dev/null

My "~" directory is pretty big so it sits at that for a while, but "gpg --gen-key" still sits.

I'm pretty sure something is wrong. I can run strace if you think it would help.

thanks,

aporter

[aporter (aporter)]

Guys,

I see the same problem with "cat -v /dev/random" when on a remote shell. It doesn't print out much, and all of the "find" "ls" and "ping" lines I call don't change that.

aporter

[JoePete (mrzx4l98d4tp89jab6giohdrjqysbyjs4npz2ccq25kvjmf5h8u4c-ubuntu-hwbqs6tox1bv6csee9psn5309v7488f3dugifm692db2xfq8n1fsz)]

Just a simple:
$find / > /dev/null

I think this might do the trick.

Just to add three cents to the question of entropy vs. bug, bear in mind here that whatever goes into generating that key is as strong as its weakest link. Someone might go to a great deal of effort to generate the key pair in question but eventually it will reside on a filesystem whose controls likely do not rely on such a high degree of entropy. To analogize, the safe in your home may be protected by an unguessable combination, but since it is so complex, so entropic, it must be recorded somewhere. So the thief doesn't try to guess the unguessable; he simply seeks the place in which the key has been recorded. And while that key may be protected with its own combination, it intrinsically has to be one easily remembered (and that means easily guessed).

I do lean toward identifying this as a bug as there are ways of a system generating the necessary entropy for the keys. These typically are more or in addition to the guidance of moving the cursor or typing random keys. One should remember as well that not all users have a mouse, keyboard or or full (or any) use of hands and fingers for that matter. Hence, sound development practices would seek out such routines rather than simply ask the user to do something random - after all if the user were truly random we wouldn't need key-pair generation to begin with ;-)

[Lev (lev-v-kuznetsov)]

# find / -type f | xargs grep blahblahblha

works every time for me.

[Rookcifer (rookcifer)]

Wow, thank goodness this bug is invalid. The original poster, with all due respect, was simply ignorant of how things are supposed to work. Remember the Debian SSL bug? That was due to some code maintainer who thought he knew more than the crypto coders. As a result he broke thousands of keys across the Internet and severely embarrassed the Debian developers.

People have already given you solutions:

1) Generate the key on a device that has a mouse and keyboard and then transfer the key to the other device.

2) Go buy yourself a hardware RNG like the entropy key. It is cheap and fits into any USB slot.

3) Go download HAVEGED from the repository. It likely gives "good enough" randomness and will keep your random pool full at all times. However, since it hasn't been well studied, use this only as a last resort! (It was developed by PhD's, so it's probably good enough, but it still needs peer review).

If you can't do either of those then you shouldn't be generating keys on the device. There was a recent study that collected millions of keys across the internet and found that many thousands of them were easily broken. Why? Because they were generated with crappy entropy (and mostly generated on devices like routers, vpn's, etc.) Is this what you want? An easily broken key?

If your system doesn't have any inputs or you have no way of generating entropy, that's *your* problem to figure out. Don't go suggesting that Ubuntu should make us all insecure because of you. Again, if you don't have a keyboard or mouse hooked up to the machine, go find a machine with them and generate the keys there. If the machine is remote, then simply generate the keys locally (with a strong password) and then send them over the wire to the remote machine. This should not present any security issues since the private key is itself encrypted.

Bottom line: the GnuPG RNG is working as it is *supposed* to work. If it didn't work the way it did I would not use it. This is *not* a bug with Ubuntu and it's not a bug with GnuPG. Also rng-tools is *not* meant to be used unless you have a hardware TRNG, so it is working as intended as well. Whoever suggested pointing it at /dev/urandom is a complete amateur at cryptography and should be ignored. There's a lot of people out there who just don't know what they're talking about when it comes to crypto and they should be ignored just as much as this bug report should be ignored.

@JoePete

There are no processes on an OS that are sufficient for entropy gathering *besides* keyboard, mouse and disk movements (and even they have problems, but are probably good enough). So what the developers are doing now *is* sound development practice. They don't need amateurs trying to tell them how to do crypto.

I think part of the problem with people trying to get entropy from disk seeks is they don't understand how /dev/random works. It estimates the entropy before it hashes it and outputs it. Since disk seeks have much less entropy than say a random mouse or keyboard input, this is why it takes forever to generate any output. /dev/random is designed with entropy measurement in mind and it simply wont output anythi...

[Jon Stevens (latchkey-gmail)]

It is people like you that make novices hate computers. You get all uptight about stupid security restrictions and then go on a random diatribe on an issue that is more than a year old and is marked as 'invalid'. This is exactly why Linux will never be a desktop os for the masses.

Anyway, my usecase doesn't need strong crypto... all I need f*cking keys for is to sign debians which are behind a f*cking firewall so that I don't have to deal with the f*cking 'this package isn't signed' warning. I'm running in a VM... not even real hardware... I certainly am not going to buy a piece of f*cking hardware just to generate some keys I don't give a sh*t about. You're absurd to even suggest that.

Maybe the bigger issue with with the way gnupg works... the user experience is terrible. Just freezing up and not doing anything isn't useful for anyone. If Ubuntu cared about user experience, then they'd work with the gnupg group to find a better solution to this issue. Even if I got a warning that this key isn't 100% secure and then pop out an insecure key, that would be better than just freezing up waiting for input.

[Rookcifer (rookcifer)]

@ Jon Stevens

So if we care about security we are stupid? This isn't just some random security issue in code that are a dime a dozen. If we implemented what you suggested we would be breaking the entire web of trust of people who use Ubuntu to generate GPG keys. We would literally be making the whole GPG system completely insecure for hundreds of thousands if not *millions* of people. Ubuntu would become a laughing-stock on all the big tech websites. Blogs world wide would be saying "Ubuntu generates insecure GPG keys." I can see the headlines now.

 Whoever runs this bug list should *never* have made this a valid big in the first place. Luckily they have since made it invalid. Now they need to close it for good.

And if you are developing or packaging, why are you not doing it on a local machine? Why are you doing it on some random VM remotely? Besides, I gave you a good solution already. Run this in the terminal on your VM:

sudo apt-get install haveged

That is an entropy generator that will keep the entropy pool full at all times. You should be able to generate your keys in seconds. Even though it might not be as secure as using /dev/random directly, it is probably good enough for your needs, and certainly much faster. If you want a fast solution, fine. But don't ask Ubuntu to break our security for your one weird corner case.

Lesson to be learned: Unless you are a cryptographer or someone *very* experienced in crypto coding, do not *ever* mess around with crypto code or suggest people change it because of something you don't understand. Debian learned this lesson the hard way several years ago.

[taligent (taligent)]

Firstly. I have fully read and understand all of the comments. However there is absolutely something wrong with the way entropy is captured for REMOTE sessions.

It asks me to do some work e.g. type on the keyboard. So I do so for literally about 5 minutes generating pages of text and it still looks like it has frozen. The only way to get it to work was to open another remote session and use that find command listed here.

THE ISSUE IS AS FOLLOWS:

- There is poor user interface guidance about what to do in particular for remote sessions.

- It should provide some sort of progress indicator that you are (a) indeed generating bytes and (b) how far I have to go before it is finished.

[Steven Ayre (steveayre)]

@taligent

"something wrong with the way entropy is captured for REMOTE sessions."

There's only a single way to generate entropy, and it's the same whether you're running gpg locally or remotely. It must come from an external source (eg keyboard/mouse/disk). Anything triggered by the machine itself is predictable due to the schedulers, it must come from user/disk activity instead.

The only issue with generating it remotely is that it's harder to generate external entropy when you do not have physical access to the machine. Local keyboard/mouse input provides more noise than anything you can easily generate remotely.

The find everything piped into cat trick in another session should be sufficient on most systems. If it is all cached this would allow you generate disk access bypassing the cache:
  dd if=/path/to/large/file of=/dev/null iflag=direct

Personally I would suggest that you generate GPG keys *locally* where it's possible to generate plenty of entropy since you have keyboard/mouse access, then transfer the keys to the remote server(s) where it's required.

Yes, perhaps the message could be improved with advice targeted at remote users and a progress indicator if the kernel allows it, but that does not describe the original poster's report and might be better with this bug closed and that suggestion raised as a separate bug.

Otherwise it may be dangerous for people Googling this issue to find this bug and follow the original posters advice without reading any further.

[Ads20000 (ads20000)]

If it should be moved, change it to Invalid but it is officially 'Confirmed' because it should be improved and several people have had this problem.

[Alvaro Gonzalez (andor)]

Both parts have some reason.

In one hand, you shouldn't generate any kind of crypto key if you don't have enough entropy, it defeats the whole purpouse of it.

On the other hand, with all this virtual environments we use today, and the lack of detail on the message, you feel helpless:

Where is my entropy?
I keep poking keys in my ssh terminal (as mandated by the software) but no entropy is generated
Can I get entropy from another host?
How do I press keys or move a mouse on a virtual machine if there's no hardware to plug a mouse?

Probably everybody needing a quick cert for doing some testing or authenticating packages locally is getting some headaches with this, especially if they don't use the same OS on their desktops than on the servers.

So my proposal is expanding a bit the explanation message when generating a new key, stating that, if connected remotely or to a virtual host, they won't get entropy ever pushing keys, and maybe giving an option or two.

Maybe even a timeout, so if the key is not generated in XX minutes, it stops and gives some explanation to the user, with a --force-wait option to avoid this timeout.

[Steve Meadows (z-launchpad)]

Same problem and I concur that

find / -type f | xargs grep blahblahblha

was the special sauce that solved it.

[Christopher Swanson (cswanson)]

Hey everyone,

This may be an old topic and I didn't read the whole thing, but:

sudo tcpdump

ought to create enough juice to generate a key.

It did for me.

[Hector Oron (zumbi)]

apt-get -y install rng-tools

Edit /etc/default/rng-tools:
  HRNGDEVICE=/dev/urandom

/etc/init.d/rng-tools restart

That got me going with a test key...

[Hector Oron (zumbi)]

Note the above trick/hack is *only FOR TESTING* purpose, as it gives false sense of entropy, hence not very good gpg key.

If you plan to create a key for production use, as signing emails, packages, etc... you better find a good source of entropy as explained at: https://bugs.launchpad.net/ubuntu/+source/gnupg/+bug/706011/comments/7

[Brylie Christopher Oxley (brylie)]

I have this issue when generating GPG keys on a remote server. It seems like generating GPG keys on remote web servers is a relatively common use case, and might deserve another look by the GPG developers.

[Jay R. Wren (evarlast)]

I think that this is a real bug.

http://www.2uo.de/myths-about-urandom/

Says that /dev/urandom is the correct source and that there is no reason to not use it.

[J Phani Mahesh (phanimahesh)]

Then please do not believe that blog post. Because /dev/urandom is not a source of entropy and can not be relied upon for any serious business. It is in a sense a consumer of entropy available from /dev/random, that does an expansion to provide pseudo random data even when there is no entropy to produce good random data.

@Jon Stevens:

Crypto should not be messed with. Period. But your frustration is understandable. Developers do not intend to be hostile to novice users as you claim, but we have concerns that not all users will not be able to appreciate. rng-tools has a valid use case, but the workaround suggested in some comments to use /dev/urandom would scare the crap out of any cryptographer. I wish it is disallowed altogether.

The most sensible suggestion comes from Alvaro in #25. Why hasn't there been more discussion on this? Security can't be compromised, but a better explanation to users doees no harm. I am skeptic of allowing a flag, it will be suggested as a workaround when it should not be, and users will follow the advice.

Rather, only when being run interactively, the user can be prompted after a timeout if they want to reduce the key size and/or proceed with just the available entropy, since it is taking long to collect enough entropy. This option should be unavailable when being run non-interactively, since I don't see the need and IMO allowing it does more damage in the long run.

On a sidenote, rng-tools should atleast spit out a warning when /dev/urandom is being used as a *HARDWARE* random number generator, which it is not. Does not prevent anyone from creating a new device node for urandom and using it, and circulating sequence of commands to be run to accomplish that, but all user stupidity can not be safeguarded against.

[J Phani Mahesh (phanimahesh)]

I should have read the blog post you linked to before posting the comment. There are no factual errors in the blog post to my knowledge (I'm no professional cryptographer, just an enthusiast who took a couple formal courses and tinkered a bit), and the argument is compelling.

My previous comment actually looks silly now, since I talk of "good" random data that the post disputes. But I stand my ground that using /dev/urandom for serious business like GPG keys is a bad idea. /dev/random providess a better guarantee than /dev/urandom regarding the randomness of data you extract, and many including me are not happy to give up this guarantee.

[bobafetthotmail (starshipeleven)]

I quite frankly don't understand the rationale of all this bug report nor why anyone has not thought of this.

You are pissed off by apt crying when there are unsigned packages? I understand your pain. I develop stuff too, and it's annoying.

What I don't understand is the rationale for blaming the key generation system and ask mantainers to add a "make it all fake" option. That's... just going to attract flak because it breaks security (the whole point of the key generator system).

It's beyond obvious.

There is a simple solution though that does not involve breaking encryption system, so keep reading.

Disable package signature checking. Boom, problem solved, no need to compromise encryption for everyone else.

this command is of course "disable for this package"

sudo apt-get --allow-unauthenticated install mypackage

If you want to disable for EVERY package which is NOT SAFE AT ALL thus NOT RECOMMENDED for most systems (but it is probably fine for a development VM)

drop a file called 99unsigned or whatever in /etc/apt/apt.conf.d/

and write this inside:

APT::Get::AllowUnauthenticated "true";

in either case apt will show a warning about unisgned packages but will proceed anyway without requiring user input.

Now can this bug be closed? This solves the opener's issue.

[bobafetthotmail (starshipeleven)]

Maybe this info can be added to the manual or the help text of gpkg. "if you are a developer you can also disable package signature checking from apt, see man apt for details" or something like that.

[Jon Stevens (latchkey-gmail)]

@bobafett

The signatures are a nice feature for ensuring that the package is valid. It doesn't have to be totally 'secure' as it is a private internal network.

If you go back and read ALL of the comments, I think you'll note that I'm not requesting that things are made less secure, but that things are secured correctly.

If anything, this issue should be closed because it has been open for so many years and clearly pisses people off enough to create a fake account and make wild comments.

[Richard Elkins (texadactyl)]

I am sympathetic with both sides of this (developer and user).

Suggestion: Add a guided entropy creation option such that gnupg would start a background thread or process that generates sufficient entropy. The user is warned about time needed variability which depends on hardware and other factors.

Periodically, the % accomplished to goal is updated. Would be nice: an ETA (time) update along with the % update.

This would enable the package maintainer or other type of end user to start up key generation and go off and eat dinner, go to sleep, whatever. And, the developer stops getting distracting reports due to lack of understanding by users on the nuances of randomness.

[qsantos (qsantos)]

First, this is a critical flaw for usability. Second, usability flaws translate
into security issues.

For instance, the widespread myth of “high entropy password” using mixed-cased
letters, digits and “special characters” is a disaster. Sure, having complex
passwords does theoretically allows for high entropy but, in practice, it
means:

* users will not use passwords chosen uniformly at random (famously “123456”,
  “password” and “qwerty”, see [1] for more)
* users will forget them (which lead to “security” questions and numerous
  compromises [2]; see demo [3])
* users will write them down in obvious places (pentester presentation at
  Defcon [4])

On the other hand, if you get people to use easy-to-remember passwords actually
chosen uniformly at random [5], you can mitigate these situations. Note also
that even just *two* actually random words would already be quite better than
the current situation.

[1] https://wpengine.com/unmasked/
[2] http://www.wired.com/2012/08/apple-amazon-mat-honan-hacking/
[3] https://www.youtube.com/watch?v=opRMrEfAIiI
[4] https://www.youtube.com/watch?v=4-qnYaw7VGo&t=28m58s
[5] https://xkcd.com/936/

---

Now, regarding GnuPG, there are multiple usability flaws. This bug focuses on
one.

Obviously, if you want to use it for yourself or in a highly tech-literate
community, that should not be to much of a problem. However, many of us are
trying to get common people to embrace some decent security.

First, in most cases, the difference between /dev/random and /dev/urandom do
not even really matter. The only I can think of right now are (feel free to
suggest others):

* fresh install
* generating many keys in a row that are all going to be security relevant
  (i.e. n-1 tests and 1 real does not count)

This is the reason for proposals for having /dev/random stop blocking once
enough entropy have been gathered [1].

Second, attacks are few and far between and still very theoretical. One dates
from 2006 and does not do much [2] (slides at [3]). Note the comments,
especially zooko [4] highlighting the importance of usability and unruh [5] who
already complains about the poor man page [6]. Another one is [7] which does
look somewhat more interesting but still does not go very far.

Third, GnuPG requests an absurdly high amount of entropy. It seems to want more
than 2352 bits of entropy, even though security will only be a few hundred bits
at best. Even without considering /dev/urandom, it does mean that GnuPG is
running ten times too slow. I suspect the prime number generator naively eat
more entropy for each new random number it needs, rather than using a CSPRNG.

All this results in a critical usability flaw for no good reason. I want to
underline that, for many users, we are not debating “extremely high security”
(/dev/random) versus “very high security” (/dev/urandom) but “no security” (not
using GnuPG) versus “very high security” (using GnuPG).

Of course, [8] is a very good read, as have been before. I would add [9] (which is mentioned in [8]).

In my opinion, the best course of action would be to make `/dev/urandom`
opt-out (situation actually requiring `/dev/random` might opt-in). At the very
least, there shou...

[Pheeble (enpheebled-git)]

I have the same problem with 'gpg2 --full-gen-key' (with all default options) hanging indefinitely on Xubuntu 16.04.1.

In another terminal I'm running 'cat /proc/sys/kernel/random/entropy_avail' on a loop every 5 seconds, and the available entropy value never gets below about 2900, and gets up to about 3100.

So how much entropy does this thing need?

I've tried running all of the other suggestions, with no success.

[Seth Arnold (seth-arnold)]

Pheeble, this bug is ancient and grown far too many complaints to be usefully addressed. Please file a new bug with ubuntu-bug gnupg2.

Thanks