Forward Secrecy|Public-Key Encryption

Forward Secrecy

Suppose Alice and Bob exchange a shared-key-cipher session key KS using their RSA keys. Later, their RSA keys are compromised. If the attacker has retained Alice and Bob’s prior communications, the attacker can go back and decrypt KS, and then use KS to decrypt the entire session protected by KS.

This is not true, however, if Alice and Bob had used Diffie-Hellman-Merkle key exchange. In that case, there is no encryption used in the process of negotiating KS, so no later encryption compromise can reveal KS.

This property is called forward secrecy, or, sometimes, perfect forward secrecy (other times, perfect forward secrecy adds the further requirement that the compromise of any other session key negotiated by Alice and Bob does not reveal information about KS).

The advantage using public-key encryption along with Diffie-Hellman-Merkle key exchange, then, is that Alice can sign the key KS she sends to Bob. Assuming Bob is confident he has Alice’s real public key, a man-in-the-middle attack (29.3 Trust and the Man in the Middle) becomes impossible.

It is now common for public-key encryption to be used to sign all the transactions that are part of the DiffieHellman-Merkle exchange. When this is done, Alice and Bob gain both forward secrecy and protection from man-in-the-middle attacks.

One drawback of forward secrecy, as described here, is that the Diffie-Hellman-Merkle key exchange nominally requires synchronous exchanges. If Alice is encrypting an email message to Bob, synchronous exchanges are probably not an option, as Bob may be offline at the time.

One approach to forward secrecy in asynchronous communication, used by the X3DH protocol, is for Alice and Bob to generate prekeys. In the key exchange described above in 28.8 Diffie-Hellman-Merkle Exchange, Alice and Bob agree on a prime p and a generator g, and choose random values a and b respectively. They then exchange ga mod p and gb mod p. A prekey for Bob is simply a precomputed gb , shared with a server and signed by Bob. To avoid reuse, Bob will typically generate (and share) many prekeys. When Alice wants to send her asynchronous message, she simply asks the server for one of Bob’s prekeys. With that and her own ga , she can then calculate the session key KS and encrypt the message. Alice’s ga must then be sent along with her encrypted message, so Bob can also calculate KS and decrypt the message. This prekey approach appears to be quite secure, though it does either commit everyone to using the same key-exchange prime p and generator g (the usual approach), or else requires the generation of a set of prekeys for every potential correspondent.

Frequently Asked Questions

Ans: OpenFlow and the POX Controller|Mininet view more..
Ans: Linux Traffic Control (tc)|Mininet view more..
Ans: Forward Secrecy|Public-Key Encryption view more..
Ans: Trust and the Man in the Middle|Public-Key Encryption view more..
Ans: End-to-End Encryption|Public-Key Encryption view more..
Ans: SSH and TLS|Public-Key Encryption view more..
Ans: IPsec |Public-Key Encryption view more..

Rating - NAN/5