1995-10-07 - MITM attacks and True Names (again…)

Header Data

From: Bryce <wilcoxb@nagina.cs.colorado.edu>
To: cypherpunks@toad.com
Message Hash: 164e07e257a6f7f6389e346b3bdebecd42b45ea87a2291a01f94637af4ea44cd
Message ID: <199510070102.TAA14826@nagina.cs.colorado.edu>
Reply To: N/A
UTC Datetime: 1995-10-07 01:02:50 UTC
Raw Date: Fri, 6 Oct 95 18:02:50 PDT

Raw message

From: Bryce <wilcoxb@nagina.cs.colorado.edu>
Date: Fri, 6 Oct 95 18:02:50 PDT
To: cypherpunks@toad.com
Subject: MITM attacks and True Names (again...)
Message-ID: <199510070102.TAA14826@nagina.cs.colorado.edu>
MIME-Version: 1.0
Content-Type: text/plain



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

What is the difference between having a conversation with a spook 
masquerading as a cypherpunk (or vice versa) and having a conversation 
which is, unbeknownst(sp?) to either of you, monitored and modified by 
a "Man in the Middle" (hereafter: "Mitch", the Man in the Channel)?


The difference is that in the second case there actually is an entity,
separate from the one in control of the other end of your conversation,
with whom you are (sort of) conversing.  Furthermore it is practically
(if not theoretically) possible for that entity to evade Mitch and
contact you directly.  So much for the debate about "talking to public
keys".


(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.))


Now I have four things to say about this "evasion of Mitch" thing.
Don't worry, they are all short and some of them are interesting.


1.  A dense, strong Web of Trust is very important.  This should 
already be obvious, but point 2 should make it even more so.


2.  It should be each person's responsibility to ensure that their 
true public key has reached the Web of Trust.  If you make a habit of 
delivering copies of your true public key to members of the Web of 
Trust via multiple channels which should be difficult for Mitch to 
intercept, (e.g. snail mail, connections from pay phones to local net 
nodes, courier delivery, phone calls, face-to-face meetings, etc. etc) 
then you can make it arbitrarily difficult for Mitch to keep your true 
public key off the WoT.
  Others can just use the public key for you which they get from the
WoT (of course, they have to make sure that *they* are strongly
connected to the Web by sending their own public key through multiple
channels!).  If other keys show up claiming to be you then we have an
interesting denial-of-service sort of scenario where psychology and
reputation and crypto and all kinds of interesting stuff get mixed in,
but at least we are relatively safe from an un-noticed MITM attack.


3.  There is one other method that can help foil Mitch: the "overload
his processors" trick.  Pay attention to the lag time between
transmission and reception of messages.  Then send a very large
message, or many messages simultaneously.  If it takes longer to get
there (modulo normal processing penalty, normal net lag variation, the
possibility that Mitch was delaying transmissions specifically in
preparation for this trick, etc etc etc) then you know Mitch is in the
channel.  Highly interactive, complex-signal stuff like voice and video
is perfect for this.  Even the NSA can't intercept a PGPFone session
and fake my voice in real time, echoing me when necessary and replacing
my words with other words when necessary.  For this reason PGPFone will
hopefully be quite a boon to the Web O T.  (Thanks to Seb Kuzminsky for
bringing the "overload his processors" trick to my attention.)


4.  Mitch's big opportunity is to strike before the Web is formed.
Once your key is in the Web then his only options are:  1.  acquire
your secret key.  2.  wait til you forget your passphrase and then get
in the middle when you announce a new public key unsigned by the old
one.  or 3.  launch a really mean denial of service attack on you.  
This is one of the reasons that I sign almost all of my outgoing
messages, even to people who don't use PGP.  I can use these
accumulated messages to demonstrate to others that I, Bryce, really was
in control of the PGP public key whose ID is 0x617c6db9 and the one
whose ID is 0x148a11e5 during this time.  This might be important
someday.
  (My *primary* reason for clearsigning everything is to let others know
about PGP's existence and to encourage them to start using it.)


  (And to advertise my cybershop product...)



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: Automatic PGP clearsigning under Unix with Bryce's Auto-PGP v1.0

iQCVAwUBMHXRmvWZSllhfG25AQEp7wP/TiLAlfy4S5WeQX8Xgxf0Ng/83UJLffAS
oMrALvPdmTA/wTA1a5/5oUAP/FUTY0uDoR/ELX99yO353B4pljl1yMhk3VW7vNuN
6egklSRsqBBNsJ5qNekDZmuRmxnucCHvn90EXo8BHfyUwGDMksUq77a982aHbYWd
ctF/T35KomQ=
=3hTQ
-----END PGP SIGNATURE-----





Thread