- From: Aaron Swartz <me@aaronsw.com>
- Date: Thu, 04 Apr 2002 21:51:23 -0600
- To: "Joseph M. Reagle Jr." <reagle@w3.org>, RDF-Interest <www-rdf-interest@w3.org>
On 2002-04-04 09:34 PM, "Joseph Reagle" <reagle@w3.org> wrote: > On Thursday 04 April 2002 20:45, Aaron Swartz wrote: >> PKI and Web-of-Trust networks are designed to foil Man-In-The-Middle >> (MITM) attacks, not who's-key-is-this? problems. > > I don't follow. For public keys, they are largely the same problem. My > scenarios is orientated towards validating a signature on a single > document. The Man-in-the-Middle scenario is orientated towards the exchange > of multiple interactive documents. (The person can sit in the middle > proxying the messages back and forth watching the conversation while > fooling both sides.) But, they share the same problem of, "This is really > Andrew's (or Bacon's) key." [a] MITM can occur in the static document scenario, if you imagine the Man sitting at your ISP, slyly rewriting all the crypto that comes thru. (I admit, this is a very paranoid scenario.) The attack here would be to feed you (seemingly signed) documents that the real person never signed. > The nature of the threat might be different, but the problem is to be sure > one has the right key. On the Semantic Web, I'd treat that as a normal trust problem, the same way I'd want try to make sure that the triple "x y z" was true. How is finding John's key any different than finding who won some war, or any other question you might ask the Semantic Web? It's just a set of bits, like any other. > [a] http://www.silicon-trust.com/background/sp_pki.htm > [[ > [...] One problem is that if a > hacker has knowledge of your private key information, they can intercept a > message and replace the public key with one of his or her own. This is > known as a man-in-the-middle attack. Huh? You can execute a MITM attack without knowing someone's private key -- that's the whole point. -- [ "Aaron Swartz" ; <mailto:me@aaronsw.com> ; <http://www.aaronsw.com/> ]
Received on Thursday, 4 April 2002 22:51:29 UTC