Mr. Squirrel?

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