Re: [PLUG] Jeff's and my paranoia.

[David Shaw <dshaw@jabberwocky.com>]

On Sat, Feb 07, 2004 at 11:21:05AM -0500, gabriel rosenkoetter wrote:
> On Fri, Feb 06, 2004 at 10:18:51PM -0500, David Shaw wrote:
> > This is a fairly standard policy.  I do something similar.
> 
> Yeah, but he wrote up an explanation of the "enciphered email of
> random strings" that it was easier for me to refer to than write up
> myself. :^>
> 
> He got that part right, anyway.
> 
> The weakness you refer to (can't know that the person you saw is
> still in control of the key when your enciphered email is received,
> right?) isn't, I don't think, something that can really be addressed
> in a disconnected communicant protocol, when it really comes down to
> it. There'll always be a timing attack.

Exactly.  You can't even know that the person you saw *ever*
controlled the key.  For all you know, there is someone else using the
person you traded fingerprints with as their "public face".  As
weaknesses go, it's not really up there.

I have seen keysigning protocols that attempt to resolve this as well
(by giving the signee a large random number in person, and asking for
it back via email), but that doesn't really close the hole completely
as the person you met could easily give his friend the token.

It's interesting to me that those people who send out tokens to be
signed generally send them encrypted (I do it as well).  It doesn't
hurt to encrypt, but strictly speaking, there really isn't any need to
do it either - the signature they are sending back is issed by the
primary, and when you sign a key (well, a OpenPGP key), you're binding
the user ID to the same primary key.  The whole thing could be in
cleartext.

> >   "I may sign keys when I have not met the person or verified the
> >   key."
> > 
> > This is a dreadful, dreadful idea.  Remember that the check level
> > numbers are for human reading - the computer, when building the web of
> > trust, treats all signatures the same.
> 
> I don't think he understands that. (I'll admit that I didn't when I
> first started assigning those values. It's maybe a bit misleading to
> even have the capability to do that, but it'd be hard to remove it
> now.)

Yes.  At this point, I pretty much wish I had never added that
feature.  It's a great example of the law of unintended consequences.

> Is there any reason NOT to make strength-of-trust part of the
> trustdb calculations? (I'm guessing, "What, you were complaining
> about how long it took to run --check-trustdb just months ago, and
> now you want me to make it take LONGER?" would be your valid
> response... ;^>)

Heh, actually 1.3 is already quite a bit slower than 1.2, since 1.3
combines --rebuild-keydb-cache with --check-trustdb.  I'm still
working on that and looking for ways to speed it up before 1.4.
Linear search is a killer.

Eventually, GnuPG is going to need a rethinking of the keyring
management.  GnuPG 1.9 (will be 2.0 eventually) has a completely
different database backed system, but the 1.x branch is going to stay
with flat files a la PGP.  There are better ways to handle flat files,
though.

There isn't any real reason not to make strength-of-trust part of the
trust calculations.  I was vaguely thinking of a system where each
user has four trust values, rather than one.  If this user makes a
level 1 signature, their level 1 trust value would apply to that link,
etc.

The main reasons it hasn't been done is complexity (social, not code).
It would be a significant change to the current trust model which is
already barely understood.  It would also mean that the GnuPG web of
trust would differ from PGP, which is also confusing.

Despite this, I rather like the idea of anyone using any trust model
they like (it's one of the big strengths of OpenPGP, in my book), so
rather than implement many trust models, I've started on a system for
an "external" trust model in GnuPG.  Anyone can write a program to
evaluate trust in whatever way they prefer, and use this (offline) to
spit out a complete trustdb.gpg file.  GnuPG just follows this trustdb
file, so this lets anyone write a trust model.

This is about halfway done, and should be in 1.4.  I imagine less than
a hundred lines of perl could do a trust model that takes into account
strength of trust.

David

Attachment: pgpvI0fvzcDq1.pgp
Description: PGP signature