Need non-writable --homedir
Robert J. Hansen
rjh at sixdemonbag.org
Tue Sep 12 21:10:57 CEST 2006
-----BEGIN PGP SIGNED MESSAGE-----
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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iQEcBAEBCgAGBQJFBwZBAAoJELcA9IL+r4EJaVUH/3Er4alOB7hkKE1uO1dQNzJc
30IKEzjuykGuAhLFnhap0dtRGX3RfBAQOkyrEcHDg0LLAsX5gLNUy7th/0PLxSOU
E2fQGMA530zG6qVKqx7iwbMmnq+nUymNekIqBTTFS03vkQm84AOzO72U4FRa9uVv
WRzrSxw5CNO7e/WnOsavvLt/rMpAHKbxTEgz7IpCHNRR3v/A+B5lJfq5+jdJQMg3
sqVK8pc9Lc5E/HQfCWWgmebxNrYWRj6q/XU4v4yPU529dn0YaLYVdCAZF0EPBg7h
qfz7hicPzScTdBh4t1tW57YobkwQuOdwGd8x4QAlB6OpJal6oQpKNVdWj6s2ufs=
=faU9
-----END PGP SIGNATURE-----
More information about the Gnupg-users
mailing list