[Bug 706011] Re: gpg --key-gen doesn't have enough entropy and rng-tools install/start fails

Yoha yoha at sinon.org
Thu May 5 20:28:34 UTC 2016


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 should be an option to opt-in `/dev/urandom`.

[1] http://www.philandstuff.com/2013/03/14/why-does-gpg-need-so-much-entropy.html
[2] https://lwn.net/Articles/184925/
[3] https://www.blackhat.com/presentations/bh-usa-06/BH-US-06-Gutterman.pdf
[4] https://lwn.net/Articles/185209/
[5] https://lwn.net/Articles/190070/
[6] `man 4 random` or http://man7.org/linux/man-pages/man4/random.4.html
[7] https://www.schneier.com/blog/archives/2013/10/insecurities_in.html
[8] http://www.2uo.de/myths-about-urandom/
[9] https://security.stackexchange.com/questions/3936/is-a-rand-from-dev-urandom-secure-for-a-login-key

---

Since I am at at, I will answer texadactyl regarding improvement of the user
interface.

Basically, GnuPG needs to find a number (well two) with a nice property (being
prime). We virtually have no better way than just picking a number at random
and testing whether it does match the property.

It works like for lottery probabilities: even after losing numerous times, you
are no more likely to win. With GnuPG, say you expect the key generation to
take roughly 2 minutes ; if after 2 minutes you sill have found no such number,
the expected remaining time is *still* 2 minutes.

If you look at the output of `openssl genrsa 4096 > /dev/null`, you will see
one like for each of those prime numbers. A dot `.` represents a candidate and
a double plus `++` indicates a find. GnuPG creates two RSA pairs by default
(primary and encryption), which means four prime numbers, or four lines of
output; it prints fives pluses `+++++` for a find.

Remark: each plus `+` actually represents a probabilistic test of primality;
using deterministic testing would take much more time

---

**tl;dr:** please, allow common people to use /dev/urandom

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to gnupg in Ubuntu.
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:
  Confirmed

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

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnupg/+bug/706011/+subscriptions



More information about the foundations-bugs mailing list