Re: MITM attacks and True Names (again...)

-----BEGIN PGP SIGNED MESSAGE-----

At 07:02 PM 10/6/95 -0600, bryce@colorado.edu wrote:
>(As an aside I fully sympathize with those who rail against the popular
>(?) impression that a True Name is somehow necessary to communication.
>That is a dangerous idea, since all a True Name is really necessary for
>is violence.  (And, pending certain eagerly-awaited technological
>developments, for sex.))

That's incorrect - it can also be necessary for _avoiding_ violence.
You don't need a full True Name for that, but you do need an accurate
partition of the namespace into those entities who will, won't, or might
come and beat you up based on what you say.  Thus, if you're talking to
Subcommandante Marcos about your plans for overthrowing the governor,
you don't need to know his True Name, but you do need to know if he's a cop;
anybody doing a successful MITM job on your data communications probably is.

Similarly, if you're in the pharmaceutical retail business and talking to
your wholesaler, you may even want to avoid knowing his True Name, but you
not only want to know if he's a cop, but you may want to know whether,
if you show up at the appointed physical location with your physical body,
you'll be met by just him (with his merchandise), or by other people as well
(eavesdroppers using MITM because it's easier than cracking crypto),
or by one of his or your competitors trying to rip you off.
(You'd also like to know if you'll be met by him without his merchandise,
but with his big ugly friends, which is why you plan to meet him in a 
public place...)




-----BEGIN PGP SIGNATURE-----
Version: 2.7.1
Comment: PGP available outside U.S.A. at ftp.ox.ac.uk

iQBVAwUBMHdVcPthU5e7emAFAQHRNwH9ErIcbgioSJOD5270SJ2hRfycNd6sMAj3
Q5jzguJVkbmsrI9I85eB/caV9UOOkSTX29v3gTAHWbeNuAL9t/Yyrw==
=3qir
-----END PGP SIGNATURE-----
#---
#                                       Thanks;  Bill
# Bill Stewart, Freelance Information Architect, stewarts@ix.netcom.com
# Phone +1-510-247-0664 Pager/Voicemail 1-408-787-1281
#---

One of the reasons people don't like solutions based on True Names is
because nyms don't have them.  Pr0duct Cypher can't very well go to
someone, show a drivers license, and get his key signed.

There is still a way in which signed, true-name-based keys can be useful
to nyms.  Maybe they can't get their own keys signed in this mode, but
they can check the keys of others.

If Pr0duct Cypher, under his secret identity, goes out and gets valid
keys that he can trust (maybe he sees Verisign's key fingerprint in the
newspaper), then if I send him my key signed by someone he trusts, he
can check the signature.  He can then send data to me encrypted with my
actual key, and the MITM can't do anything about it.  So the presence
of my True Name based key allows us to communicate securely.

This doesn't help for the case of two nyms who want to communicate,
though.  For that we do need a mode in which nyms can get their keys
signed.  I do think that there are some situations in which that is
plausible, based on the difficulty of mounting a MITM attack against
someone who is determined to try to detect it.  In the most extreme case
the MITM has to simulate the whole outside world with respect to the
person he is targetting, which is infeasible.  Various tricks like
sending hashes of future messages have been discussed; the MITM can't let
these through since the future message may include the true key that he
is hiding.  If people are then supposed to reply to these hashes, all of
the replies have to be simulated by the MITM.  Eventually it seems that
the MITM becomes enmeshed so deeply in his own lies that he would get
caught.  If steps like these are taken successfully it should be
reasonable to sign a nym's key, with the semantics being that either this
is the real key of the sender, or he has a nearly omnipotent MITM
surrounding him.

Hal

-----BEGIN PGP SIGNED MESSAGE-----

  Hal <hfinney@shell.portal.com> wrote:
> Eventually it seems that
> the MITM becomes enmeshed so deeply in his own lies that he would get
> caught.  If steps like these are taken successfully it should be
> reasonable to sign a nym's key, with the semantics being that either this
> is the real key of the sender, or he has a nearly omnipotent MITM
> surrounding him.


Let's think of ways to foil Mitch:


1.  Physical body (a.k.a. "True Name") mapping.
2.  The "overload his processors" trick.
3.  Sending hashes of future messages.
4.  Sending your public key to the Web O Trust via multiple, 
independent channels.
5.  Working an identifier of your public key into conversation so that
Mitch can't edit out your public key without changing the whole
conversation.  (E.g. "I talked to her a number of times equal to the
least significant 4 bits of my public key."  This is an example which
Mitch could easily handle, by replacing "a number ... key" with "3
times", but it gives you the idea.)


All of these can involve psychological manuevers, like "informal 
coding".  That is, trying to sneak some information by Mitch that he 
*should* edit if he knew what he was good for him, but he doesn't 
realize it.  This gets really interesting, trying to communicate 
something to your actual recipient without letting Mitch realize what 
you are communicating.

The "tell me [something only you would know]" game is a good example of
that.


I think method 4 is the best method.  Method 1 is more reliable, but
much more expensive and I have a strong aversion to making it necessary
for everyone to publicize their True Name.  I don't know if method 5 
is even feasible.  :-)

Of course, there is no reason not to use many different methods
simultaneously.


Bryce

signatures follow


            "To strive, to seek, to find and not to yield."   
    <a href="http://ugrad-www.cs.colorado.edu/~wilcoxb/Niche.html">

                          bryce@colorado.edu                   </a>

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: Auto-signed under Unix with 'BAP' Easy-PGP v1.01

iQCVAwUBMHoR6/WZSllhfG25AQFgbwP/fTXZTRGdPL1GIzep+0YS9lD/GigW9XHP
8SiF8y+AxmVXeYYE0Jwj7T2MPNE298H1V8ZQQXq6ClLSJjXbvOnCGN35mhu0xR+l
MdaCiV2LOpLs8tXVDSkuLfJBcVdJRR7TuyXYTBSdAf2pTn6SOkmMhIKe7z/6fj7h
qrRMjCPRL5s=
=8QFl
-----END PGP SIGNATURE-----