Need non-writable --homedir

Robert J. Hansen rjh at
Tue Sep 12 21:10:57 CEST 2006

Hash: SHA512

I apologize if this email seems snarky.  However, I'm getting tired of
repeating the same answers over and over again.

Josef Wolf wrote:
>>> Don't most unices have /dev/random nowadays?  I never planned to
>>> run this thing on a windows box :)
>> GnuPG has been ported to many platforms.  BeOS, OpenVMS, Win32, and
>> many more that have no /dev/random.
> I know.  And this is good.  But I am asking as a gnupg user, not as a
>  developer.

Your question is predicated on a "well, I'm on UNIX with a /dev/random,
so why doesn't GnuPG just use /dev/random for everything?"

You got an accurate answer to your question.  If you can't understand
the answer, then perhaps you should re-think the questions you're asking.

> I know that my application will run only on unix-like systems.

Ah, yes, UNIX Programmer's Disease.  I suggest you look into getting cured.

If you care only about UNIX systems, that's your lookout.

It's not the lookout of the GnuPG developers.

>> GnuPG may fail well in that situation.  But will _all_ your
>> applications fail well in that situation?  Especially ones which
>> can't afford to block for minutes until the /dev/random pool
>> replenishes?
> Well, that's why I asked how many random data gnupg consumes when 
> encrypting.

Please re-read my answer.

GnuPG _doesn't_ diminish /dev/random when encrypting, because it uses
its own pseudorandom number generator, which is why it uses random_seed.

The reason why it doesn't use /dev/random is because it's being a good
citizen and not using up limited resources, when it can do the same job
without using up any of that limited resource.

> AFAIK, having random_seed be accessible to unauthorized people is not
> acceptable.  Thus I have no choice

You always have a choice.  I'd suggest rearchitecting your solution.
Your current solution does not strike me as particularly sound.

> I never had a radioisotope RNG and I will probably never have such a 
> beast.  On an average system /dev/random collects entropy from
> keystrokes, mouse events, network traffic and such things.

Please consider this very carefully:

_GnuPG has absolutely no way of knowing the internals of /dev/random._

None.  Nada.  Zilch.  Zero.  GnuPG doesn't know, doesn't care.

Also, please consider this very carefully, too:

_There is no such thing as an 'average' GnuPG system._

What's an average GnuPG system?  Is it BeOS?  Win32?  Debian GNU/Linux?
 Fedora?  FreeBSD?  OS X?

>> GnuPG has no control over how each UNIX handles /dev/random.  If
>> GnuPG has no control over that, then GnuPG isn't going to rely on
>> that.
> On my system gnupg relies on /dev/random when keys are generated.

Because it has no other choice.  It needs highest-quality random values,
and it can block indefinitely until those values are available.  (In
fact, it warns you it might block for a while.)

When encrypting messages it _does_ have a choice, and so it chooses the
option with the least impact on limited system resources.

> So it relies on /dev/random when generating keys but can't rely on it
> when actually encrypting?  Doesn't sound very consequent to me.

See above.

> I have no doubts about this.  But I still don't have any clue what 
> consequences --no-random-seed-file has.  Will encryption process
> block? Will the random data be of bad quality?

While I am certain answers exist to be found, I am not certain the
answers will do you much good.

Version: GnuPG v1.4.5 (Darwin)
Comment: Using GnuPG with Mozilla -


More information about the Gnupg-users mailing list