Risk Assessment

[Werner Koch]

"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).


  Werner