1

Why is forward secrecy better (say for WhatsApp) than public-key encryption with a routinely revised key?

The advertised issue is backwards safety: If at a point one key is compromised, someone storing the history of past communications would still be unable to suddenly decrypt all that history.

But consider the following simpler method using ordinary public-key encryption. Whenever Bob's client sends a message, it sends along with that message a new public key, one generated algorithmically. The public key is stored on the (WhatsApp's) server. Those sending messages to Bob would retrieve that public key, and their client would encrypt the message they are sending to Bob using that key. The key remains valid until Bob again sends a message to anyone.

What is the weakness of this elementary approach compared to forward secrecy? Once one message under forward secrecy is compromised, subsequent messages would become readable. The method just described would be stronger in that respect.

Calaf
  • 113
  • 4

2 Answers2

1

Well forward secrecy is usually achieved exactly by what you propose, namely ephemeral public (usually Diffie-Hellman) keys. This basically works as follows:

  1. Generate some DH parameters.
  2. Sign the public parameters via your longterm public key.
  3. Send parameters and your signature over the parameters to whatever computer you want to talk to.
  4. Use the ephemeral parameters to generate a shared secret from which to derive symmetric keys.

If you look at the key exchange mechanism for most HTTPS connections you'll see part of the ciphersuite is usually ECDHE_RSA, meaning ephemeral Diffie-Hellman (over an elliptic curve group) with the parameters signed via RSA (the RSA key being the servers long-term private key for which the corresponding public key is found in the servers certificate).

It is important that you sign your ephemeral keys with your long-term private key, otherwise an attacker would be able to upload a key of their choice to say the WhatsApp servers and read all messages intended for you as there would be no way to verify the ephemeral keys legitimacy.

Once one message under forward secrecy is compromised, subsequent messages would become readable. The method just described would be stronger in that respect.

This is not correct, only messages related to the session whose ephemeral parameters were compromised would become readable. The next session would have different ephemeral parameters and would still be secure.

puzzlepalace
  • 681
  • 3
  • 11
1

What you've described is essentially what forward secrecy does. It generates a random public key for every session.

https://en.m.wikipedia.org/wiki/Forward_secrecy

Daisetsu
  • 5,110
  • 1
  • 14
  • 24
  • Forward secrecy makes a point of sending the new key in a message to the recipient, rather than simply making the new public key public. – Calaf Apr 27 '16 at 02:08