[Security] TLS Certificates Verification

Jonathan Dickinson jonathanD at k2.com
Tue Aug 19 13:13:15 CDT 2008

Diffie Hellman only allows a common passphrase to be generated by exchanging information that doesn't allow the eavesdropper to determine the passphrase. This passphrase is fed into a symmetric encryption algorithm.

Diffie hellman is quite unique and could be called 'zero-knowledge passphrase generation'.

Diffie Hellman keys are one-time, that is, they are used only once per session.

The only problem is the man-in-the-middle attack. Diffie hellman can be done over a secure channel, however, which eliminates man-in-the-middle attacks.

Each party exchanges their 'keys'.
 - These keys may be stored in memory/logs on servers on the internet etc. but are useless because diffie hellman can only be cracked using a man-in-the-middle attack (reading logs is eavesdropping).
 - Man-in-the-middle attacks are not possible because each endpoint is connected to the other via TLS.
The parties ecnrypt messages from then on using the shared key.
 - It is seen as difficult (breaking diffie hellman would also result in breaking TLS) to break diffie hellman. The eavesdropper can't determine the key and hence can't decrypt the messages (e.g. if encrypted using decent cyphers like AES).
The parties destroy their keys once the session is complete.
 - The diffie-hellman key has a one-time-key loving properties which makes it incredibly difficult to determine even under cryptanalysis of many similar messages.

Once again, RSP resolves the problem of the man-in-the-middle attack, but means a lot needs to be set up beforehand: such as shared passwords etc.

-----Original Message-----
From: security-bounces at xmpp.org [mailto:security-bounces at xmpp.org] On Behalf Of Eric Rescorla
Sent: Tuesday, August 19, 2008 8:03 PM
To: XMPP Security
Subject: Re: [Security] TLS Certificates Verification

On Tue, Aug 19, 2008 at 10:57 AM, Jonathan Dickinson <jonathanD at k2.com> wrote:
> Maybe something based on Diffie Hellman (which RSP uses)?

I'm not sure what you're suggesting. Basically, there are PAKE (aka
zero knowledge password
proof) systems and non-PAKE systems. All the non-PAKE systems are
subject to dictionary
attacks, whatever technology they're based on (though the public key
ones can be
made to be require an active attack on one connection).

What Dave is suggesting, I think, would be a garden variety TLS handshake with
whatever ciphersuites you already support and self-signed certs. Then you'd run
SASL with some challenge/response protocol and channel bindings (you'd
almost certainly want mutual auth here) and then on the basis of the C/R
note that you trusted the peer's self-signed cert.


More information about the Security mailing list