Chapter 2

In essence, the DH key exchange guarantees privacy; that is, you can be sure you are only talking to one other person. However, the public channel used for the DH key exchange could be manipulated. What if Alice just did a DH key exchange with Mallory instead of Bob, because Mallory is trapping all communications to Bob? DH key exchange is certainly valuable, but it does not address how to authenticate the other party, to ensure you are not talking (privately) to a man-in-the-middle (MITM).

Avoiding the Man in the Middle

There are two ways out of this problem. One is to use someone else, with whom Alice and Bob already have a trust relationship, as a mediator. This is called a Trusted Third Party (TTP). The TTP can send them an encrypted message only they can read in order to prove the identities of Alice and Bob to each other. The communication with the TTP cannot be forged by a man-in-the- middle because Alice and Bob already have a trust relationship.

The second solution for Alice and Bob is to do an 'out-of-bound' communication that is either trusted, or for which it is trusted that an attacker is not able to perform a MITM attack on both channels of the communication. For example, one way for Alice and Bob would be to call each other by phone, and read the keys aloud. If Alice and Bob have talked to each other before, they will recognize their voices and trust what those voices are saying. Of course, this is very much prone to errors, so a common method is to run a secure hash function over the public keys that Alice and Bob have sent to each other, and only read the short output of that hash function. This output is called the fingerprint.

There is actually a third 'better than nothing' solution, which is called a 'leap of faith'. Since it is very unlikely that upon their first communication, an attacker is already trying a MITM attack, both Alice and Bob accept the public keys as true and store them. Any later communication uses these keys. This leap of faith method is frequently used with the SSH program. When trying to connect to a new machine with an unknown public key, the SSH client informs the user of that fact, shows the user the fingerprint, in case an out-of-bound verification is needed, and then stores the key for future use. If the remote public host key changes, or an attacker is trying a MITM attack, the SSH program complains loudly.

Session Keys

Common cryptographic systems do not use the private key to encrypt or sign. Instead, they sign and encrypt a new key, called the session key. This key is used to encrypt the bulk of the data, but is discarded after some relatively short time. The advantage here is that using session keys protects your communication even in the case where all your encrypted communication is logged and at some point your private key is compromised. Since the session keys have long since been destroyed after their use, having the private key will not enable someone to decrypt all previous communication since even the holder of the private key does not have the old session keys any more. This is called Perfect Forward Secrecy (PFS).

31