From: Adam Back <aba@dcs.ex.ac.uk>
Date: Sat, 6 Dec 1997 08:14:23 +0800
To: smith@securecomputing.com
Subject: WoT discussions, Trust for Nyms
In-Reply-To: <v03007800b0ae121c8f4c@[172.17.1.150]>
Message-ID: <199712060006.AAA01508@server.test.net>
MIME-Version: 1.0
Content-Type: text/plain




Rick Smith <smith@securecomputing.com> writes:
> I admit I can't figure out what crypto mechanism Kong is really
> using since there's obfuscating talk of passphrases and secrets.

What James describes on the page is that he is storing the private EC
key in a file.  The file is optionally encrypted with a passphrase.
He also describes how the key file can be stored on floppy.  The term
he uses for the private key file is "secrets file".  This much is
fairly standard.

The novel feature is that he includes the PK with the signature.  I
consider this useful, in that if you ever receive a communication, or
read a post you wish to reply to you have all the information required
to reply without going to a keyserver.

You are vulnerable to MITM, but including a reasonable subset of the
WoT with a post is not an option due to size.

Another interesting option with EC is to derive the key from the
passphrase, then there is no private key file.

> Since Kong does not use certificates, it is vulnerable to the Man in the
> Middle (MIM) attack and indeed to forgery. 

Most uses of PGP are subject to the same attack, because people do not
have enough web of trust connectivity.  PGP certificates give you the
tools to avoid MITM attacks when you knew someone before hand.

A widely deployed WoT generally makes MITM harder even when you
converse with people only electronically, because somebody knows them
in person, and this may be reflected in the WoT.

The fact that it is easy to fabricate a whole community of fictitious
people who know each other is interesting also.  One method you could
use to restrict this somewhat is to add a cost function to creating
identities.  A certificate proving certain monies have been paid for
the identity, or a hash collision over a certain size.

> However, I also suspect that the behavior of a long lived cyberspace
> identity would make a MIM attack detectable and/or impractical in
> the long run. If John Doe consistently includes a public key in his
> web site, messages, and postings, then recipients have a relatively
> independent way to validate the key being used in a message
> allegedly from him. 

This is similar to including fingerprints at the bottom of posts.  In
some senses John Doe's web site, messages and postings define who he
is in cyberspace.

> As mentioned above, I haven't used the produt itself. But the
> underlying concept may represent a practical subset of classic
> e-mail security.

I strongly suspect it entails a high percentage of the use of PGP.
Very few people have WoT connections.

And there is the question of what a WoT link means.  The only people I
have direct WoT links to are people who I first met electronically.  I
wouldn't know them from Adam.  How do I know the person I met is the
real Ian Goldberg, or whoever.  

Also an inherent problem is that just because I met Ian Goldberg once
does not mean that all the people he signs keys of are who he thinks
they are.


The problem of preventing MITM can be viewed as the task of making the
MITM's job difficult, and making it difficult for the MITM to perform
many MITMs at once.

One way to go about this is to distribute your belief of other peoples
keys.  The potentially helps to strengthen the WoT because you may
work your way around the MITM by a link he does not control.  For
example you could download the list of email addresses from a
keyserver and spam them all with the set of fingerprints of all the
public key ring that you use (or all of the keys on the keyserver).

Not that they would thank you for it, spamwise, but if there are in
existance any MITM's it could conceivably flush some out.


Another lower bandwidth method of making the MITM's job harder is to
sign and/or publish hashes of public key databases -- download the
keys, or some useful easily definable subset of keys on keyservers,
and publish the hash of them in as many media as possible (web,
finger, news, mail, newspapers, etc.)

For example if the operator of a public key database published a hash
of all the keys in his database in a widely available newspaper, the
MITM now has to make sure that John Doe doesn't see this newspaper, or
that the newspaper John sees has been reprinted espescially for him.
If John Doe is suspicious he will stop a random person in the street
and ask to see the key hash section breifly.

In general John Doe's strategy to avoid being the subject of a MITM
attack should be to be unpredictable in the channels he uses for
authentication and communication.

Let's say John buys a book on cryptography, and the author included
his fingerprint.  Then John could use this person to authenticate a
key with Alice.  He could write to the author, including a nonce with
the plaintext, and ask the author to check that the key he thought
belonged to Alice really did belong to her.


Interlock protocols are another method of complicating the MITM's
task.  If Joe develops the habit of posting the hash of messages he is
about to post a day in advance, the MITM must think of something to
say also, and publish the hash, so that it can publish something a day
later.

As the MITM's messages now don't match with what Joe said, the MITM
has to lie some more to keep up the game.  We would like to overload
the MITM so that his task of lying becomes computationally infeasible.

Adam