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 Touch seeded packages, 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 -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
