Re: Secure key exchange

How byzantine!

PGP 2.1 will have a much more convenient facility for verifying public
keys that you receive over the network. If you say "pgp -kvc karn",
for example, it will display the MD-5 hash of karn's public key as 16
hex bytes. If you know the sound of my voice, you can call me on the
phone and have me read off the hash code that I compute here on my key
so you can compare it to the value you computed. If they match, you
can sign my key with reasonable confidence.

About the only way to defeat this system is for the bad guy who feeds
you the bogus key in my name to come to my house and hold a gun to my
head as I receive your phone call.

I would much rather trust a simple verification procedure based on
redundancy and close personal relationships than a single, complex,
impersonal process involving people I don't know. This is not to
impugn your integrity, of course -- I'm simply speaking on principle.

People need to be very selective about the signatures they sign,
otherwise they will become meaningless. I've already had people sign
my public key without any verification that it is legit. This is a
no-no.  I am bothered by the message that PGP currently generates when
it reads in some new public keys asking if you'd like to certify each
new key. Even though the default is "no", it makes it too easy to sign
a key without really verifying its authenticity.

Phil

>>>>> On Sun, 29 Nov 92 14:03:25 -0800, karn@qualcomm.com (Phil Karn) said:


	Phil> People need to be very selective about the signatures
	Phil> they sign, otherwise they will become meaningless. I've
	Phil> already had people sign my public key without any
	Phil> verification that it is legit. This is a no-no.  I am
	Phil> bothered by the message that PGP currently generates
	Phil> when it reads in some new public keys asking if you'd
	Phil> like to certify each new key. Even though the default is
	Phil> "no", it makes it too easy to sign a key without really
	Phil> verifying its authenticity.

I have to echo Phil's comments here. One of the things that might be
worth a few minutes is for this group to hash out (pun intended) a set
of guidelines for "when it's o.k. to sign a key". I have been
talking to some people about personal applications of cryptographic
technology, and I'm frequently surprised when even people with a DP
security background want to rush to certify keys they've received via
email, etc. 

I'm thinking something along the lines of "If I'm in a real-time
communications mechanism, and on the phone at the same time, and I
receive their key at the moment when they told me they hit the return
key - then it's probably theirs"...It would be prohibitive to list all
of the possible permutations, but it might go a long way toward
building the right habits if we brainstormed about a few firm
guidelines for the uninitiated as to what constitutes responsible key
management. 

I confess to some personal bias, because I know the PEM folks are
watching to see how robust our key distribution "web" becomes over the
course of its evolution, and I'd like to be able to show them a
convincing argument against centralized key management, empirically...

--Strat

An excellent suggestion.  Can you start writing such a thing? (This is
not a facetious request).  I imagine there will be two or three
strategies for approving a key, and if we write them up well, we will
be able to ask people which protocol they have engaged in:

1) Only people I know personally and whose keys I receive in person.

2...

n) Any key received throuhg any medium.

This could have lots of educational value.

dean