Q: Local keyring security, attacks and lsign

Neil Williams linux at codehelp.co.uk
Fri Sep 3 21:14:22 CEST 2004

On Friday 03 September 2004 3:17, Stewart V. Wright wrote:
> I have recently upgraded to the 1.2.6 release.  Before installing I
> verified the .sig associated with the source...
>   gpg --verify gnupg-1.2.6.tar.bz2.sig
> Fortunately(!) I got a good signature:

As you noted, you got a VALID signature, not a trusted signature. IMHO, a 
valid signature on the GnuPG code isn't good enough, for exactly the reasons 
you describe later.

Your best solution is your personal trust level, not lsign. Later . . 

> gpg: WARNING: This key is not certified with a trusted signature! gpg:     
>     There is no indication that the signature belongs to the owner. Primary
> key fingerprint: 6BD9 050F D8FC 941B 4341  2DCC 68B7 AB89 5754 8DCD

For your peace of mind, my Web of Trust allows me to fully trust Werner's key 
and I get the same fingerprint.

> There are (at least) two obvious solutions.  The first is for me to
> expand my web of trust so that Werner's key is is in my trusted set.

Your key is already in the strong set, courtesy of the signature of Chris 
Howells. You have a short distance to Werner's key, via Chris:
Only Marc Mutz and/or Ingo Klocker need to be trusted to verify keys correctly 
when signing for Werner's key to be trusted. Setting the trust value is a 
personal thing, but sometimes I do bump a key up to marginal or full trust 
even when I haven't signed it myself. If you can personally trust Ingo and/or 
Marc to properly validate keys when signing them, you should find Werner 
becomes trusted too.

The quickest way of finding close keys that are trustworthy is to import all 
the missing signatures on keys that YOU have already signed. Then view each 
key in something like KGpg or on a keyserver and see if there are enough 
other signatures on the key that could merit you trusting the keyholder to 
validate keys properly when they are signing other keys. One or two judicious 
tweaks can make a lot of difference - just take care and be realistic about 
whether you can trust the person behind the unsigned key to really validate 
keys properly.

These trust values are personal and local and no lsign or sign is involved. 
This, to me, would appear to be your best option. If for any reason you 
change your mind, edit the trust level of the link key and GnuPG will sort 
out the rest.

> The second is for me to verify the fingerprint each time I check a
> signature

With what? You are verifying an untrusted key against a copy of the same 
untrusted key. You have a slight protection in that Werner (or someone else) 
would probably spot a very similar key on the keyservers trying to pretend to 
be Werner - it's hardly worth considering.

> Thus:
>  * Does "lsign"ing Werner's key make sense in this case?

You still have to be sure that the key really belongs to the physical person 
reliably identifiable as Werner Koch who has sole access to the private key. 
lsign isn't a cop-out for bad security, it's there for those who don't want a 
valid signature to show up on keyservers, perhaps because their own key isn't 
on keyservers.

>       I _think_ what I want to achieve is a way to say "this is the
>       key that I have added" (and adding a signature is something that
>       makes the attack harder) without assigning too much trust in the
>       key itself (which seems to be opposite to the lsign)...

As far as GnuPG is concerned, a lsign is as valid as a sign and it will 
calculate your web of trust on that basis. You could set the trust value of 
the lsign'ed key as don't trust (so that none of the keys signed by Werner 
are affected by your lsign) but it's already getting messy.

>  * Would generating a "lsign"ing key which is itself only partially
>    trusted be the way to go?

?? Why does lsign appear to be less trustworthy than sign ??


Neil Williams

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : /pipermail/attachments/20040903/1a4ae791/attachment.bin

More information about the Gnupg-users mailing list