Need non-writable --homedir
jw at raven.inka.de
Tue Sep 12 20:42:39 CEST 2006
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
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
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?
More information about the Gnupg-users