Looking at the strace output of GPG on my box seems to show that it uses /dev/urandom when encrypting a message without any access to /dev/random even when --no-random-seed-file is specified.

Are messages at risk of being encrypted with a low entropy session key? If so then how does one instruct GPG to not behave like this?

EDIT: I believe this is a different question than the possible duplicate which deals with more ephemeral data. My gpg encrypted messages will have a long lifetime and are easily subject inspection by an adversary.

  • 3
    This suggests that isn't a likely problem. – etherealflux Aug 4 '15 at 16:41
  • Sorry, but it is a problem. "As a result, if there is not sufficient entropy in the entropy pool, the returned values are theoretically vulnerable to a cryptographic attack on the algorithms used by the driver". Supposing I have high security requirements I would like to ensure a proper source of randomness is used. – CoderBrien Aug 4 '15 at 16:50
  • It's theoretically vulnerable, yes. It's also theoretically possible to guess your session key! Thomas's answer explains why urandom is practically always the better choice – etherealflux Aug 4 '15 at 16:54
  • You're free to have your opinions. Clearly gpg is in fact vulnerable to weak session keys if /dev/urandom is used. My question stands. How do I get gpg to use a strong random source (/dev/random)? – CoderBrien Aug 4 '15 at 17:04

On a general basis:

  • /dev/urandom is no less secure than /dev/random. In fact they both use the same algorithms and the same seeds. Occasionally, /dev/random just stops because someone, someday, read something about entropy, did not understand it, and now thinks that randomness is something that is burned upon usage and must be refilled regularly.

    (This page makes a rather nice job explaining things on that subject.)

  • There can be situations where there is not enough available entropy in the whole system. These situations do not occur with normal Linux distributions because they generate and save a random seed at boot time, to be used for the next boot, effectively ensuring that /dev/urandom is cryptographically secure all along. To get into one of these situations, you have to either play some weird games with VM snapshots, or use not a PC but some very limited embedded system; this is quite far from the contexts where you would use GnuPG.

  • It is very noteworthy that in the case of VM snapshots, the "entropy estimate" of /dev/random will gleefully report that it is full of the stuff, which is, in this case, very wrong. That is, not only does the blocking behaviour of /dev/random is scientifically unsubstantiated, but it also totally fails to be triggered in the one practical case (VM snapshots) were entropy loss could be feared.

  • Also remember that contexts where /dev/urandom is inappropriate are also contexts where /dev/random is inappropriate. Using /dev/random will not make things "more random"; at best, it will refuse to work instead of generating a key of theoretically lower security ("theoretically" because none of this has ever resulted in a practical break, even as a demonstration in lab-controlled conditions). As explained above, this is really an "at best" and it won't actually work that way with VM snapshots and reset.

    Fortunately, all the activity involved by a boot implies collection of enough entropy to achieve cryptographic security (for arbitrarily long /dev/urandom outputs, even). See this article for more analysis. GnuPG key generation is not done by the kernel in the early boot steps; it occurs much later, during normal operation, when the PRNG has been properly seeded.

None of this prevents some people from insisting on some ritual dancing with entropy. Apparently, the GnuPG authors are part of that specific theological interpretation -- either because they believe it or because they yield under the market pressure.

Summary: using /dev/urandom instead of /dev/random is not weak for GnuPG. GnuPG is used in a context where /dev/urandom is properly seeded and will achieve all the required unpredictability, and /dev/random will do no better (not in practice, not in theory either). In the one situation (VM snapshots) where the output of /dev/urandom could be inadequate for GnuPG, the output of /dev/random will be equally inadequate for the same reasons, and the blocking mechanism of /dev/random will not be triggered. The conclusion is that switching from /dev/urandom to /dev/random for GnuPG is completely useless.

... that is, from a technical point of view. Using /dev/random instead of /dev/urandom could induce some blocking that can help in persuading the weakly-minded that "serious cryptography is happening". It won't make things more secure, but it may make the user feel safer.

  • 1
    Wow, that's a whole lot of text which really just distracts from the issue. What you are arguing is that most of the time using /dev/urandom doesn't matter, but you must conceded that shortly after boot time there may not be enough entropy available. Do you have a source for your claim that /dev/random will not block? That would be suprising. – CoderBrien Aug 4 '15 at 18:11
  • 2
    How would it be surprising ? /dev/random blocks based on its internal "entropy counter". If you snapshot the machine, you snapshot the whole machine, including that counter. – Thomas Pornin Aug 4 '15 at 18:14
  • 6
    @CoderBrien Are you interested in an answer, or in ranting at people who don't share your opinion? Thomas makes some excellent points: 1) GPG is a user program, meaning that it can only ever run after boot, by which time both /dev/randam and /dev/urandom will have lots of entropy, and 2) none of this has ever been broken, even by researchers in a lab setting. Your data is fine. – Mike Ounsworth Aug 4 '15 at 18:20
  • 2
    He answered the first part, which is: No, using /dev/urandom does not in any plausible scenario result in the generation of weak GPG keys. In fact, systems like OS X and FreeBSD have gone as far as completely doing away with the distinction between either, where /dev/random is now just a symlink to /dev/urandom. – Stephen Touset Aug 5 '15 at 2:48
  • 2
    Hell, read the scathing comments by DJB, Thomas Pornin, and Thomas Ptacek on the debate (ironically, one of these people has already answered your question in this exact thread). – Stephen Touset Aug 5 '15 at 2:51

Answering my own question:

Eureka: FIPS mode causes /dev/random to be used for the session key and enables lots of other sane decisions to be made. Although it does look like Fedora may have decided to do away with it. So despite my stack being nearly overflowed by those who say settle for "good enough" there is actually a viable alternative.

  • Yeah I'm annoyed myself at Debian's default. Lots of programs rely on using gpg greater than version 1. So I rename /usr/bin/gpg to /usr/bin/gpgv1, and create a symlink for /usr/bin/gpg that poings to gpgv2. – RoraΖ Aug 4 '15 at 17:27
  • 2
    Do you have a reference for your statement that messages are vulnerable to a low entropy session key (with GPG 1.4)? AFAIK, there is no low entropy attack on 1.4. See Thomas's answer. – mikeazo Aug 4 '15 at 18:46

Not the answer you're looking for? Browse other questions tagged or ask your own question.