gabriel rosenkoetter on Thu, 6 Mar 2003 13:13:06 -0500 |
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
|
|