gabriel rosenkoetter on Thu, 6 Mar 2003 13:13:06 -0500


[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: [PLUG] PGP keysigning aftermath


On Thu, Mar 06, 2003 at 12:33:33PM -0500, Jeff Abrahamson wrote:
> > - Everyone involved had really better understand how it works, or
> >   they're liable to do it wrong.
> This is true for all the schemes.

Not really. Your way requires significantly more crypto
understanding than either how we do it now or using key slips.

Key slips are especially good if we force one-to-one engagements
(which minimizes sleight-of-hand scares). They require no more
knowledge than basic procedural protocol; the crypto can be a
completely black box.

> > - Latecomers are completely screwed.
> This is semi-true for all schemes, although it's true that it's easier
> to run gpg-key2ps before leaving home/office than it is to remember to
> mail a key in advance.

By latecomers I mean "anyone who hasn't emailed their key to
Mike/whoever well enough in advance of the meeting for Mike to have
the keyring/file to be SHA1'ed updated". There's no way around them
being screwed in either our current or your scheme. We don't even
need to know that they're going to come to the meeting in mine.

> Uniqueness is not open to comment: it is not unique. (The range is
> larger than the domain.) The assurance is that different things you
> happen to have are highly unlikely to hash to the same value, and
> given a hash value, it is hard to find a pattern that hashes to it.
> 
> I'm knit picking, as I said.

Yes, you are. :^>

In any case, I still say that I haven't seen a (mathematical) proof
that finding another string to hash to the same value is impossible,
nor that a longer or shorter input string makes it harder or easier
(actually, that goes for changing *any* characteristic of the input
string). Trusting a hash that we know isn't perfectly one-way twice
doesn't make me any more comfortable.

Worse, we KNOW that there are PGP implementations that don't compute
their SHA1s correctly, as we've had key fingerprint collisions on
the keyservers before. Scar-y.

Is your OS's cksum(1) implementation correct? Sure? (Yes, Jeff,
you and I probably are because we've actually read it and know
enough to verify it. But is that true for everyone? Doubtful.)

> > - An error in ANY key aborts the whole keysigning for everyone.
> No, just that one key would be unuseful, the rest of the sheet is
> fine. We would all have computed the hash based on the same file.

Let me lay out a scenario for you:

- a key is provided to the organizer
- the organizer adds that to the block of keys to be SHA1ed
- the organizer uploads that key to the webserver
- the organizer SHA1s the block of keys, and brings that hash with
  him to the meeting to display
- everyone goes home, downloads the block of keys, SHA1s them, and
  finds that the hash doesn't match.

What do we do now? We certainly don't sign anyone's key...

I really think the process is inherently failure-prone. (This kind
of error is avoidable, but it requires that the organizer follow an
exact--different from the above!--procedure exactly correctly every
time. The organizer's human; let's not rely on him or her getting it
right every time if we don't have to.)

> One's not even required to prepare in advance, in the sense that you
> could compute the hash when you go home that night.

But the organizer needs to have all the keys in advance. Unless you
trust USIP's computers completely.

> That said, I'm not averse to the decentralized approach of everyone
> bringing key strips with them. I would just like to see us get away
> from the current approach, which is too time consuming *and* requires
> centralized planning.

No argument there.

-- 
gabriel rosenkoetter
gr@eclipsed.net

Attachment: pgpmk4LxwJc1Q.pgp
Description: PGP signature