Hi, I've just joined this list. Interesting confusion about Mr. Squirrel. That's one of the problems with anonymity. How do you know you're talking to the right person? What you should do is to use a public key. The pseudonym is not really the name "Secret Squirrel"; anybody can use that. The pseudonym is the public key. Any message signed by that particular key is from that particular squirrel. Any message you encrypt in Squirrel's public key is readable only by him. If Squirrel changes his key, he should sign the message so you know it's really _that_ squirrel who's changing his key (and not some other squirrel telling people to use a new key). A pseudonym is a public key. Hal P.S. Here's my key, signed by PRZ: -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.01 mQCNAiqsNkwAAAEEAMKWM52m5EWi0ocK4u1cC2PPyHT6tavk9PC3TB5XBYDegf3d sldRpnjJj1r+aO08FFO+QLEI9wtBqvf1PPP5iLX7sD2uIVlJH14MPtyVtjm9ZKb8 JMtCW74045BgtHBC9yQ3V7vXNV5jM6dE2ocnH4AI/pBFrGLJPKgTA69YIUw3AAUR tCZIYWwgRmlubmV5IDw3NDA3Ni4xMDQxQGNvbXB1c2VydmUuY29tPokAlQIFECqu M1Tidd4O/2f3CwEByrUD/3uoV2y+Fuicrrd2oDawgOw9Ejcx6E+Ty9PVPqKvflLs 0zYyGfeFVSgBbTSDP3X91N3F68nydl9J9VA6QRCGelHM1cZRukCJ0AYbKYfpwUN0 xjEGHsDrd2gT5iWlB3vBZvi+6Ybs4rSq+gyZzVm1/+oRrMen32fz2r0CLgUtHok2 =fF6Z -----END PGP PUBLIC KEY BLOCK-----
Hal is somewhat right, anyone can use 'Secret Squirrel' and anyone can use any public key they want also. So, in a many-to-one scope (as in a maillist) where the sender can not use the one-on-one signed signiture method how do we have proff of who the sender really is? Maybe public forums are just not places where it is easy to verify the identity of a speaker? A second thing that Hal's comments bring up is that we were reading the From: headders and ignoreing the keys. In good crypto-mail readers the key ought to be checked against our own data base of others keys and the result added to the hedders as say: KeyCheck: FooBar Bazoid holds this key in XXX database or some such rot. I wonder what is more important, who I claim to be in a random message or what key I include... New keys ought for an ID (or new ID's for the same key) should be added to the data base as well. But all this needs to be done automaticly by the mailers and interfaces, else the system will be mis-used and folks will tire of the extra work that gets them little advantage. ||ugh Daniel
From: hugh@domingo.teracons.com (Hugh Daniel)
A second thing that Hal's comments bring up is that we were reading the From: headders and ignoreing the keys. In good crypto-mail readers the key ought to be checked against our own data base of others keys and the result added to the hedders as say: KeyCheck: FooBar Bazoid holds this key in XXX database or some such rot. I wonder what is more important, who I claim to be in a random message or what key I include...
Anyone can include your key in a random message. If you just sign your messages, then the whole thing goes away and everyone knows its from you. PGP allows you to sign messages without encrypting them. The problem is that most people find using PGP on routine email inconvenient. Perry
Hugh asks how, in a broadcast network, we may verify identity. The answer is "statistically." Not everyone needs to verify each message; only those who communicate with the sender personally (and who thus know the private keys) need to. Hugh mentions the "one-on-one signed signature method" and that it is not applicable to broadcast. Well, signing the whole message is not, but signing a message digest is. This is the whole reason for message digests, that a message may go out in cleartext, but the validating information for that message be encrypted. Thus everyone can read the message, even without knowledge of the public key, but it is possible to verify the identity if you know it, i.e. you know the private key. Eric
Hugh's comments brought up a idea to me. RFC 822 is the standard for the format of Internet mail messages. Anybody interested in the remailer should eventually read this thing. In it there is already a standard header field "Encrypted." It accepts two optional arguments, a decryption type and an identifier (say, for key lookup). So we have a way of automatically telling encrypted message without doing pattern recognition on the body. I propose a couple more header fields. "Digest" for signed message digests. "Key-Mgmt" for the distribution of new keys and key compromise certificates, i.e. for automatic key distribution. What else do we need to make a fairly automated crypto mail system? Eric
We have standards already for a fully encrypted email system. It's called PEM, Privacy Enhanced Mail. It'd be completely senseless to come up with a different format at this point, as PEM is on the verge of deployment. John
From: gnu@cygnus.com
We have standards already for a fully encrypted email system. It's called PEM, Privacy Enhanced Mail. It'd be completely senseless to come up with a different format at this point, as PEM is on the verge of deployment.
One might have a good reason to follow most of PEMs formatting standards and the like; I'd fully agree its foolish in the extreme to do otherwise. However, some of us don't like PEMs hierarchical key authentication concepts. Perry
participants (5)
-
Eric Hughes -
gnu＠cygnus.com -
Hal -
hugh＠domingo.teracons.com -
pmetzger＠shearson.com