Problems with private keyring?

[Florian Weimer]

Werner Koch <wk at gnupg.org> writes:

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

It protects against a certain class of errors---occasional bit
flipping.  This is probably much more common than the new attack. ;-)

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

Yes, the NAI solution will be proprietary, too, so this won't do any
additional damage to OpenPGP as a protocol.

>  * 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.

Currently, you can use the secret key without having the public key in
the public key ring.  If we take the public key packet from the public
ring, we'll have to change GnuPG's behavior.  However, I'm not sure if
anybody relies on it.

>  * Similiar to the new MDC packet, we hash the fingerprint and the
>  secret mpis, append that digest and the encrypt it.  

'it' == all the data (fingerprint, MPIs, digest)?

> This will help us to detect tampering with the last block (either
> CFB or CBC).

Yes, I think so.  Tampering with the first block will only affect the
public key fingerprint, this doesn't seem to be dangerous either.

> Using this we avoid time consuming operations to check the key
> integrty.

Some of the checks should be performed anyway, and the computed
signature should be verified, just to make sure that the signature was
computed correctly (bit flipping and MPI implementation bugs can lead
to errors as well, not only attacks).