# gpg --gen-random quality level: is higher "better"?

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.

• 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. Nov 6 '15 at 14:48
• @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! Nov 6 '15 at 15:00
• 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.) 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.

• +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. Nov 6 '15 at 18:11
• /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). Nov 6 '15 at 21:57
• @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)
– SEJPM
Nov 6 '15 at 22:11
• You can install rng-tools on Linux to refill the entropy pool faster. Nov 7 '15 at 9:38
• @UnixJunkie That doesn't actually fill the entropy pool, it just artificially bumps up the entropy estimate. Mar 17 '18 at 4:59