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 Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/706011 Title: gpg --key-gen doesn't have enough entropy and rng-tools install/start fails To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnupg/+bug/706011/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
