Q: Local keyring security, attacks and lsign

[Neil Williams]

On Monday 06 September 2004 12:38, Stewart V. Wright wrote:
> This comes back to the concept that you can trust that all signatures
> from a certain key are made by someone with control of that key,

otherwise the key would have to have been compromised, yes.

> _without_ knowing anything about the ownership of the key.

True. The GnuPG / PGP signing process tells you that much. However, it doesn't 
help you trust either key. You can trust that the signatures made from one 
key to another are valid signatures and you can check for either key being 
revoked, but without a web of trust, that's all you can do.

> Someone (a 
> Deep-Throat for example) may wish their identity to remain unknown,
> but publish verifiable messages.

messages cannot be verified without publishing the public key. You could make 
the public key anonymous - you would then have to go by the fingerprint.

> How does one protect a key on your 
> keyring without having a valid WOT to it?

Protect? You protect the secret key, public keys need no protection.
If a key is untrusted, it easily cannot be protected from 'man-in-the-middle' 
attacks - that's why the web of trust is so important - you'd have to verify 
the fingerprint.

> Take a new gpg user, Alice, installing Fedora Linux for example.  The
> CDs contain the Fedora (p)gp(g) key.  Alice checks that the key not
> only verifies the packages on the CDs, but that the key has been used
> historically (via say Google) for signing messages to mailing lists,
> files, or whatever.  There is no indication in any of these sources
> that the key does not belong to a reputable RedHat/Fedora source.
>
> However, Alice has no way of connecting the key to her via the WOT as
> she's yet to even generate a key of her own.  Alice imports the Fedora
> key into her keyring and then uses it to verify various security
> patches that have been released...  Alice would love to join the WOT,
> but living at the South Pole, LUG meetings are hard to attend!

Alternative protocols can be envisaged. Presumably, there is some method of 
delivery of other goods and services. Some form of secure communication 
should be available or could be arranged using physical media conveyed over 
routine delivery channels. This would be sufficient for the exchange of 
certain data:
1. Photo ID, as per any keysigning protocol. In this case, verified using 
external records, maybe from the professional body who sent her out. The 
veracity of the ID attested by being securely sent alongside the key details.
2. The key fingerprint, ditto
3. some random text token that cannot be guessed or intercepted (random text 
and digits etc.) ENCRYPTED to the recipient key on read-only media.
4. A return of the same items PLUS a SIGNED (and possibly encrypted) copy of 
the identical text token on read-only media.

As long as she chooses to whom she will send the parcel, using details from 
the key, she can validate that the person she chose really does have the 
appropriate secret key.

If she has her own key by this time, the token sent in 3. should be signed by 
her key and the token in the reply should be encrypted to her key. That 
should allow both keys to be signed.

The recipient must have the correct secret key to decrypt the text for the 
reply, similarly, a signed reply shows that it was not a coincidental 
discovery of the text token. 

> Alice wants a way to ensure that the key she imported to her key ring
> is indeed the one she put there and that Eve hasn't replaced it
> somewhere along the piece.
>
>
> How would she do this?
>
>
>
> Cheers,
>
> S.

-- 

Neil Williams
=============
http://www.codehelp.co.uk/
http://www.dclug.org.uk/
http://www.isbn.org.uk/
http://sourceforge.net/projects/isbnsearch/

http://www.biglumber.com/x/web?qs=0x8801094A28BCB3E3
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : /pipermail/attachments/20040906/4f3db952/attachment.bin