Need non-writable --homedir

[Josef Wolf]

On Mon, Sep 11, 2006 at 05:28:25PM -0500, Robert J. Hansen wrote:
> 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.  That's why I asked on the gnupg-users list instead of the
developer list ;-)  While gnupg runs on many platforms, I know that my
application will run only on unix-like systems.  At least in the next
couple of years.  I don't think I need to bother about systems I never
used and probably will never use.  (I've never seen BeOS, I played a little
bit with VMS at high school about 20  years ago, I use Win only at work,
because that's company-policy)

> > Hmm, the only drawback I see is a slowdown.  The application will
> > just hang and wait for more entropy to arrive.
> 
> As Daniel Keys Moran wrote in _The Last Dancer_, the mark of a
> half-assed software design is its inability to fail gracefully.  Most
> software today would be lucky to be even half of that.
> 
> 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.

AFAIK, having random_seed be accessible to unauthorized people is
not acceptable.  Thus I have no choice, I just _have_ to use the
--no-random-seed-file option.  Unfortunately, the man page don't
explain where the random data comes from when this option is used
and what are the consequences to randomness quality.  This is why I
asked how gnupg will behave with this option.  I still have no idea

> Being a good software citizen means being sparing in your use of limited
> systemwide resources.  Thus, apps should avoid using /dev/random unless
> there's a clear and critical need.

For one, I still don't know whether --no-random-seed-file will cause
/dev/random to be used at all.  Further, it would be good to know how
many data will be consumed.

> >> 3.  /dev/random is, as I understand it, an ad-hoc design.  Many
> >> people who need crypto software need vetted, certified designs
> >> (even if the software itself isn't certified).  E.g., some people
> >> may require ANSI X9.17 RNG.  With a software RNG, it's fairly easy
> >> to just drop in whatever RNG you need.
> > 
> > Ough... I always thought /dev/random has the highest possible
> > quality. How can a RNG be more random than real entropy?
> 
> Again, you're missing the point.
> 
> If /dev/random is set up to be access for a radioisotope RNG on one
> system, you have absolutely no guarantee it'll be a radioisotope RNG on
> all systems.  You have absolutely no guarantee it'll be a radioisotope
> RNG even on all UNIX systems.  Depending on how often you upgrade your
> hardware, you may not even be able to guarantee it's a radioisotope RNG
> on _your_ system.

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.

> 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.

> GnuPG _can_ rely on its own internal pseudorandom number generator.  And
> thus, it gets a random seed from some believed-good source (varies from
> platform to platform), and successive calls to the PRNG just use that
> instead.

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.

> You need to recognize that GnuPG is not a Linux-only platform, and
> considerable work has gone into it to make it work on as many platforms
> as possible.

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?