Problems with private keyring?

Werner Koch wk@gnupg.org
Fri Mar 23 20:26:01 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