wk at isil.d.shuttle.de
Fri Oct 23 20:56:43 CEST 1998
"Edward S. Marshall" <emarshal at logic.net> writes:
> "insecure memory"? It's only insecure if GPG doesn't clean memory properly
> after generating a key (as other processes could then reuse the free()'d
> memory later; protected memory spaces are exactly that: protected. Only
> the process (or root) should be able to get at that memory space.
With "insecure memory" I mean memory which may get swapped out to
harddisk and if you have physical access to the machine and you can
inspect the harddisk (read /dev/sd* ) - than there is a possibility,
that you will find a secret key or a passphrase on the disk (it is not
very complicated to localte a secret key on a huge harddisk: There
are some properties which makes it "easy": Look for a area on the
harddisk which is realy random and than do furthers tests.
Anyway, all memory which held some secret information is overwritten
- so the risk is very minimal. Non swapable key storage is a request
by many cryptographers and that is the reason why it is there.
There is a option "--no-secmem-warning".
> > Exported all the keys and then the secret keys (--export-secret-keys isn't
> > listed in -h, btw).
On purpose - you should never need it. Yesterday I imported ~75000
RSA keys and found 30 secret keys in it - I think there is a pgpcrack
which does a dictionary attack on secret keys :-)
> Assume, however, that if you have a root compromise, -all- of your keys
> are compromised. Your "break-in recovery" procedure should cover a means
There is nothing to do against the allmighty Mr. Root: She can simply
install a trojan horse for everything or if you are verifying
signatures of every binary and lib, why not install a "special" kernel
which makes backup copies of all data entered when the "echo" is
disabled on a tty, ... and and and.
You need a hardware device for real good security (with integrated
keyboard to enter the passphrase).
More information about the Gnupg-devel