-----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----- _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
