The GNU Privacy Guard manual pages have this to say about using the gpg --gen-random 0|1|2 count command:

Emit count random bytes of the given quality level 0, 1 or 2. If count is not given or zero, an endless sequence of random bytes will be emitted. If used with --armor the output will be base64 encoded. PLEASE, don’t use this command unless you know what you are doing; it may remove precious entropy from the system!

I am wondering what the "quality level" means. Is 2 "better" (i.e. more random) than 0? How much "more random" is one level over another?

BACKGROUND: I came across this command in an article in Linux Journal that illustrated using gpg's --gen-random command to generate a random password. I want to have as random of a password as possible, so I want to know what "quality level" is best for this purpose.

  • $\begingroup$ In regard to "PLEASE, don’t use this command unless you know what you are doing; it may remove precious entropy from the system!", that's good advice, make sure you're not running that command on a server, or any machine that does a lot of crypto, cause you may cause problems for other programs' random number generators. $\endgroup$ Nov 6 '15 at 14:48
  • $\begingroup$ @MikeOunsworth, how does that work? To formalize the question, I posted it here. If you could explain it in that post, I'd appreciate it! $\endgroup$
    – camercu
    Nov 6 '15 at 15:00
  • 1
    $\begingroup$ Good question, but for practical purposes you are better off (on Linux, anyway) reading bytes directly from /dev/urandom instead of using this. (e.g. dd if=/dev/urandom bs=1 count=n where n is the number of bytes you would like.) $\endgroup$
    – sneak
    Nov 25 '15 at 9:42

This is a really hard question to answer. The definitive answer can only be found in the source code of gpg. However I can still answer your question using a mail I found (from 2013, details may have changed).

Is 2 "better" (i.e. more random) than 0?

Yes, 2 is "better" than 0 and 1.
As per the linked mail the quality level determines the number of bytes being read from /dev/urandom and /dev/random for answering the query.

As it appears in the mail 0 and 1 are actually the same (this may have changed by now) and gpg will just answer your query with the requested amount of fresh bytes from /dev/urandom.

2 however is different. It uses /dev/random, meaning you have higher guarantees concerning the quality and entropy of the output (as you may have to wait some time, if this trade-off is actually worth it is another question). And more importantly it requests significantly more bytes from /dev/random than you query, namely nearly 19x as many and post-processes them somehow. So the entropy of the result is high even if /dev/random doesn't provide you with high-quality random bytes.

  • $\begingroup$ +1 wow. If it gobbles up 19x more bytes from /dev/random than you asked for, it'll deplete your entropy pool in no time. $\endgroup$ Nov 6 '15 at 18:11
  • 6
    $\begingroup$ /dev/random does not really have higher guarantees than /dev/urandom (it's only better in one specific case, which is a newly-installed machine). $\endgroup$ Nov 6 '15 at 21:57
  • $\begingroup$ @Gilles, I've added this to the answer as "the additional benefits of using /dev/random may not be worth the long delay", as the guarantees are still higher (as there's at least one case where /dev/random > /dev/urandom, meaning the quality is higher, explaining why the gpg devs chose to use it only for their highest security quality level) $\endgroup$
    – SEJPM
    Nov 6 '15 at 22:11
  • $\begingroup$ You can install rng-tools on Linux to refill the entropy pool faster. $\endgroup$
    – daruma
    Nov 7 '15 at 9:38
  • 1
    $\begingroup$ @UnixJunkie That doesn't actually fill the entropy pool, it just artificially bumps up the entropy estimate. $\endgroup$
    – forest
    Mar 17 '18 at 4:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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