can you please carry such suggestions to the mailing list
gnupg-users@gnupg.org.
OK.
[.Background: I'm trying to run gpg from a cgi script that encrypts the
posted form data and leaves an encrypted file for me to read later]
> 1) random_seed includes important entropy that anybody in the world
> can clobber (or replace with their own specially cooked entropy
If someone would be able to clobber with this file he can also do
other thins, e.g. install a trojaned version of GPG or run a
sniffer from your login script.
No he can't. GPG and my login script are write protected. But the
random_seed file has to be world writeable or else my cgi script can't
update it (since the cgi script runs as "nobody"). So the random_seed
file, but not the other stuff, can be clobbered by a user with no
privileges.
> I'm using GnuPG 1.0.2 on Linux with the default configuration, which
> is set up to use /dev/random for entropy. So why does random_seed
There used to be a long theread about the problems with
/dev/[u]random. They simply can't yield enough entropy for a medium
loaded system and therefore we need to carry some state in this file.
For a lightly loaded system it doesn't seem to be a problem.
Therefore there should be a configuration option that turns off
random_seed, if the user feels that the environment can support using
/dev/random. After all, entropy in the system is scarce for the
precise reason that the /dev/random implementers didn't consider
pseudo-random entropy good enough for high security applications.
So gpg should also not use pseudo-entropy if real entropy is available.
Also, many computers (Pentium III with the newer chip sets) have
hardware RNG's now, so if the /dev/random driver is updated to use the
RNG, that fixes the entropy scarcity once and for all. gpg should be
configurable to not save state on systems where entropy is plentiful.
Thanks for the prompt response.
Regards
Paul
--
Archive is at http://lists.gnupg.org - Unsubscribe by sending mail
with a subject of "unsubscribe" to gnupg-users-request@gnupg.org
gnupg-users@gnupg.org.
OK.
[.Background: I'm trying to run gpg from a cgi script that encrypts the
posted form data and leaves an encrypted file for me to read later]
> 1) random_seed includes important entropy that anybody in the world
> can clobber (or replace with their own specially cooked entropy
If someone would be able to clobber with this file he can also do
other thins, e.g. install a trojaned version of GPG or run a
sniffer from your login script.
No he can't. GPG and my login script are write protected. But the
random_seed file has to be world writeable or else my cgi script can't
update it (since the cgi script runs as "nobody"). So the random_seed
file, but not the other stuff, can be clobbered by a user with no
privileges.
> I'm using GnuPG 1.0.2 on Linux with the default configuration, which
> is set up to use /dev/random for entropy. So why does random_seed
There used to be a long theread about the problems with
/dev/[u]random. They simply can't yield enough entropy for a medium
loaded system and therefore we need to carry some state in this file.
For a lightly loaded system it doesn't seem to be a problem.
Therefore there should be a configuration option that turns off
random_seed, if the user feels that the environment can support using
/dev/random. After all, entropy in the system is scarce for the
precise reason that the /dev/random implementers didn't consider
pseudo-random entropy good enough for high security applications.
So gpg should also not use pseudo-entropy if real entropy is available.
Also, many computers (Pentium III with the newer chip sets) have
hardware RNG's now, so if the /dev/random driver is updated to use the
RNG, that fixes the entropy scarcity once and for all. gpg should be
configurable to not save state on systems where entropy is plentiful.
Thanks for the prompt response.
Regards
Paul
--
Archive is at http://lists.gnupg.org - Unsubscribe by sending mail
with a subject of "unsubscribe" to gnupg-users-request@gnupg.org