8

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.

camercu
  • 333
  • 3
  • 10
  • 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. – Mike Ounsworth Nov 06 '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! – camercu Nov 06 '15 at 15:00
  • 1
    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.) – sneak Nov 25 '15 at 09:42

1 Answers1

5

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.

SEJPM
  • 45,967
  • 7
  • 99
  • 205
  • +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. – Mike Ounsworth Nov 06 '15 at 18:11
  • 7
    /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). – Gilles 'SO- stop being evil' Nov 06 '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 06 '15 at 22:11
  • You can install rng-tools on Linux to refill the entropy pool faster. – daruma Nov 07 '15 at 09:38
  • 1
    @UnixJunkie That doesn't actually fill the entropy pool, it just artificially bumps up the entropy estimate. – forest Mar 17 '18 at 04:59
  • And how about haveged? I think it adds to the entropy pool. – daruma Mar 18 '18 at 23:56
  • @daruma, it adds bits to the entropy pool. How good those bits are depends on many factors. What you have in the kernel is vetted by far more people than what you get with haveged. So you decide whether it is a benefit or a false sense of security. – akostadinov May 16 '18 at 11:55
  • @akostadinov haveged is just one more source of entropy. I trust the kernel to not rely on a single source and blend those it knows of in a right way. – daruma May 17 '18 at 01:26
  • @daruma, so you trust the kernel but you think you know better how to feed it entropy? If it was a good idea, wouldn't kernel devs gather entropy the way haveged does already? Basically you are telling the kernel this is good entropy and this is your decision you are responsible for for good or for bad. btw I don't say it is feasible with current kernel and haveged implementation but feeding bad entropy can also be an attack vector: https://blog.cr.yp.to/20140205-entropy.html – akostadinov May 17 '18 at 18:57
  • I trust the kernel and I trust the people behind the HAVEGE algorithm. – daruma May 18 '18 at 02:20