Re: New Method for Authenticated Public Key Exchange without Digital Certificates

From: Anne & Lynn Wheeler (lynn_at_garlic.com)
Date: 08/06/04 

Date: Fri, 06 Aug 2004 08:01:46 -0600

Mok-Kong Shen <mok-kong.shen@t-online.de> writes:
> Thank you for the clarification. I have however one probably
> rather dumb question: You have said quite a bit about T(pki)
> but nothing about T(pgp) in my view. What makes up T(pgp),
> i.e. what does it consist of in concrete terms (and how are
> people to have/generate trust with respect to them)?

so i ask to exchange keys with somebody ... we exchange keys that
possibly happens over a period of several days. i then check there key
with some key server ... again, random events over a period of several
days. this is for relatively low value consideration. for
man-in-the-middle attack ... somebody has to be constantly monitoring
all of my packets and all of their packets ... and looking for very
specific packets out of a whole load of different packets to
modify/replace.

while such a extended man-in-the-middle attack isn't impossible
... the cost to mount such an attack is going to be sufficiently
larger than the benefit ... i.e. they have to identify those specific
things that are the public key exchange ... and replace the public key
values ... and then monitor all future traffic and carefully replace
all traffic that involve the specific public key operations. these are
for the things that would be relatively low value operations.

for higher value situations the key's fingerprint is exchanged out of
band.

in the secret/symmetric key scenario ... all you have to do is
evesdrop ... since just knowning the value ... allows for both
impersonation as well as future evesdropping. for public key spoofing,
the attack is much more massive ... since just knowing the public key
isn't sufficient ... that carefully crafted public key replacement has
to be performed ... and then every possible future public key
operation has to be intercepted and replaced.

so one can talk about man-in-the-middle attacks on PGP public key
exchanges as vulnerabilities. however, the man-in-the-middle attacks
themselves have vulnerabilities ... where either party detects a
substituted public key or the possibility of a substituted public key,
say some public key communication was missed and got thru w/o being
correctly substituted first ... and the end-points find something
amiss. this vulnerability (to succesful man-in-the-middle attacks) are
in addition to out-of-band key fingerprint exchanges (which is
semi-analogous to what is being described in original posting) or
direct in-person exchanges of public keys.

so an ongoing man-in-the-middle substitution attack on typical PGP
public key exchange is fairly massive and expensive ongoing
undertaking and involves maintaining the substitution transparency
... and the man-in-the-middle attack is therefor vulnerable to either
party becoming aware of the substitution. the man-in-the-middle attack
on PGP public key exchange substition is vulnerable to out-of-band key
exchange and/or out-of-band key fingerprint exchange. 

-- 
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

Relevant Pages

  • Re: RSA Key Exchange
    ... Server B, so it initiates a request saying "Hey... ... At this point is where we can do key exchange, how we want to do it is up to ... So client A says "Hey, here's my public key, encrypt all packets coming out ... Now each one has a public key, so secured communications continue. ...
    (microsoft.public.dotnet.languages.vb)
  • Re: Key establishment question
    ... machines need to exchange two random numbers, e.g., R1, R2, if ... Diffie-Hellman is used. ... encrypt it with my private key. ... The fact that my public key decrypts ...
    (comp.security.misc)
  • Re: Reading encrypted mail?
    ... Exchange Reporting & Analysis: http://www.quest.com/messagestats/ ... There's a public key and private key involved ... ... >>> delegated mailbox access to read received encrypted messages in the ...
    (microsoft.public.exchange.admin)
  • Re: Need General Encryption Guidance
    ... >Exchange/Outlook seems to offer quite a bit of functionality. ... Exchange and Outlook only allow you to use a certificate to sign (or ... recipient must have your public key and they *should* trust your CA ... That expense ...
    (microsoft.public.exchange.admin)
  • How does this work?
    ... prevent man-in-middle attack to Diffie_hellman exchange by "Encrypt ... the Diffie_Hellman value with the other side's public key". ...
    (sci.crypt)