SSL and forward secrecy

[melodie]

http://blog.ivanristic.com/

An alternative to RSA-based key exchange is to use the ephemeral Diffie-Hellman algorithm, which is slower, but generates session keys in such a way that only the two parties involved in the communication can obtain them. No one else can, even if they have access to the server's private key.1
After the session is complete, and both parties destroy the session keys, the only way to decrypt the communication is to break the session keys themselves. This protocol feature is known as forward secrecy.2

...

if the keys are destroyed, how can one fancy to break them? There might be something I didn't catch on the way?

[djohnston]

if the keys are destroyed, how can one fancy to break them? There might be something I didn't catch on the way?

That's the whole idea. The paired keys are created when the conversation begins and discarded when the conversation ends. From the article:

After the session is complete, and both parties destroy the session keys, the only way to decrypt the communication is to break the session keys themselves. This protocol feature is known as forward secrecy.

That is, IF the application which is using the Diffie-Hellman paired key erases the keys that were created at the beginning of the conversation. There can be more than one participant in the conversation, but any conversations recorded would be encrypted. The recorded conversations cannot be decoded without at least two of the cipher keys.

[melodie]

Ok I see. I thought the protocol/method whatever, implied that the keys would be destroyed no matter what when the participants leave.

[djohnston]

Pass the SSL Labs Test on Apache2 article will show you how to enable forward secrecy as described by Ivan Ristic.