Problems with private keyring?
Werner Koch
wk at gnupg.org
Fri Mar 23 20:26:01 CET 2001
On Wed, 21 Mar 2001, Florian Weimer wrote:
> In general, GnuPG should stop operation if public and secret keys do
> not match (currently, only a warning is printed), and generated
I might have missed something, but this would only help if the
public has has been left unchanged. I cannot see a reason why an
attacker should not be able to modify the public key too, so that
that matching public and secret key won't help.
I don't think that we are able to provide a solution in OpenPGP very
fast. Because transferrring secret keys is an action not recommened
(and if it has to be done, a secret key should be send over an encrypted
channel anyway), it migh make sense to have a private GnuPG solution.
GnuPG already has a mechanism to extend the key protection mechanism
(use to store just a dummy for a secret key, cf.
--export-secret-subkeys). So we can extend this further.
My first take on this is:
* Prepend the secret mpis with the fingerprint of the public key.
This way one can check that the public key (either taken from the
public key packet orfrom the secret key packet) has not been
tampered with. Havin the fingerprint together with the secret
parts will also help in migrating the secret key to a hardware
device.
* Similiar to the new MDC packet, we hash the fingerprint and the
secret mpis, append that digest and the encrypt it. This will help
us to detect tampering with the last block (either CFB or CBC).
When exporting a key we have to rewrite it according to the RFC;
this needs the passphrase for doing the export which is not that bad.
Using this we avoid time consuming operations to check the key
integrty.
This can go into 1.0.5
Comments?
Werner
--
Werner Koch Omnis enim res, quae dando non deficit, dum habetur
g10 Code et non datur, nondum habetur, quomodo habenda est.
Privacy Solutions -- Augustinus
More information about the Gnupg-devel
mailing list