Double Ratchet initialization

[Sebastian]

I think the Double Ratchet initialization can be improved. Compared to the current specification, the below proposal:

1. sends two fewer keys during the handshake (four if you count the DH keys)
2. does not allow faulty implementations (as I explain below)
3. more closely implements [DAKEZ] and the [Double Ratchet] as specified in the literature

Proposal

I will write down the protocol from a high level perspective. To keep it simple, I omit the parts that are not relevant for initializing the Double Ratchet and got rid of nested KDF calls (something that I think should be done in the real protocol as well).

I use the following translations to compress the notation:
A: Ha
B: Hb
X: X
Y: Y
Z: our_ecdh_first as generated by Bob
W: our_ecdh_first as generated by Alice
V: our_ecdh as generated by Bob (when initializing the DR)
a: sigma as generated by Alice
b: sigma as generated by Bob
RK: used for both curr_root_key and prev_root_key
CKr: chain_key_r
CKs: chain_key_s

OTRv4 (Online initialization), currently:

Online-OTRv4:
  -> (query)
  <- B, Y, Z (Identity)
  -> A, X, W, a (Auth-R)
  <- b (Auth-I)

Alice (upon receiving Identity):
  RK := KDF(DH(X, Y))

Bob (upon receiving Auth-R):
  RK := KDF(DH(Y, X))
  (RK, CKr) := derive_ratchet_keys(RK, DH(Z, W))
  (RK, CKs) := derive_ratchet_keys(RK, DH(V, W))
  Bob can now decrypt data messages using keys derived from CKr.
  Bob can now encrypt data messages using keys derived from CKs.
  
Alice (upon receiving Auth-I):
  (RK, CKs) := derive_ratchet_keys(RK, DH(W, Z))
  Alice can now encrypt data messages using keys derived from CKs.
  Alice can now decrypt data messages using keys derived from RK and Bob's
    incoming public key (V for the first message).
  

Note that Alice will attach W to every data message she sends, but Bob already has that value, so that he should not ratchet. Bob will have to attach V to every data message that he sends.

Note that Alice COULD have initialized the entire ratchet after receiving the Identity message. She SHOULD not do this, as she has no guarantee that she is talking with Bob until she has received the Auth-I. There is the risk that a "clever" implementation initializes the Double Ratchet prematurely and lets the user send messages before it is safe to do.

OTRv4-DAKEZ

OTRv4-DAKEZ:
  -> (query)
  <- B, Y (Identity)
  -> A, X, a (Auth-R)
  <- Z, b (Auth-I)

Alice (upon receiving Identity):
  RK := KDF(DH(Y, X))

Bob (upon receiving Auth-R):
  RK := KDF(DH(X, Y))
  (RK, CKs) = derive_ratchet_keys(RK, DH(Z, X))
  Bob can now encrypt data messages using keys derived from CKs.
  Bob can now decrypt data messages using keys derived from RK and Alice's
    incoming public key (W for the first message).

Alice (upon receiving Auth-I):
  (RK, CKr) = derive_ratchet_keys(RK, DH(X, Z))
  (RK, CKs) = derive_ratchet_keys(RK, DH(W, Z))
  Alice can now encrypt data messages using keys derived from CKs.
  Alice can now decrypt data messages using keys derived from CKr.
  

If Bob wants to send multiple data messages before receiving a reply from Alice, he SHOULD attach b to every data message, so that Alice can complete the handshake even if she missed Auth-I.

Note that with this setup, both parties CANNOT initialize the Double Ratchet before they are allowed to, reducing the risk of "clever" implementations breaking the security.

Note that the last message can be interpreted as a combined Auth-I message and an empty Data Message, which functions just to send Z so that Alice can finalize the ratchet initialization. Seen in that way, the protocol is a more direct implementation of the [DAKEZ] protocol. The initialization of the Double Ratchet also corresponds more closely to the [Double Ratchet] specification.

[DAKEZ]: Improved Strongly Deniable Authenticated Key Exchanges for Secure Messaging - Nik Unger & Ian Goldberg.
[Double Ratchet]: https://signal.org/docs/specifications/doubleratchet/

[Sofía Celi]

Hey!

Thanks for the proposal. We had a similar proposal as this one in the past, but we decided against it as it will break the security proofs of the DAKEs used. Notice that on Unger and Golberg's paper,
Improved Strongly Deniable Authenticated Key Exchanges for Secure Messaging, the secret keys associated to X or Y are deleted as soon as the first Mixed Shared key is derived, so they cannot be used to initialize the double ratchet algorithm.

Note that Alice COULD have initialized the entire ratchet after receiving the Identity message. She SHOULD not do this, as she has no guarantee that she is talking with Bob until she has received the Auth-I. There is the risk that a "clever" implementation initializes the Double Ratchet prematurely and lets the user send messages before it is safe to do

Yes. I'll add a note :) But notice that according to the state machine, encrypted messages should only be received on the ENCRYPTED_MESSAGES state.

Note that the last message can be interpreted as a combined Auth-I message and an empty Data Message, which functions just to send Z so that Alice can finalize the ratchet initialization. Seen in that way, the protocol is a more direct implementation of the [DAKEZ] protocol. The initialization of the Double Ratchet also corresponds more closely to the [Double Ratchet] specification.

Yeah. I really don't know the security proofs for the AKE used in the Signal spec; but, for our case, it was debated that it was not a good idea.

[Sebastian]

Hey!

Thanks for the proposal. We had a similar proposal as this one in the past, but we decided against it as it will break the security proofs of the DAKEs used. Notice that on Unger and Golberg's paper,
Improved Strongly Deniable Authenticated Key Exchanges for Secure Messaging, the secret keys associated to X or Y are deleted as soon as the first Mixed Shared key is derived, so they cannot be used to initialize the double ratchet algorithm.

TBH I don't fully understand that proof, so you are probably right here. However, the current solution adds a different ephemeral key to the state that needs to remain stored in memory, so you have just moved the same problem to a different key. I doubt that the current solution wouldn't break the security proof.

Note that Alice COULD have initialized the entire ratchet after receiving the Identity message. She SHOULD not do this, as she has no guarantee that she is talking with Bob until she has received the Auth-I. There is the risk that a "clever" implementation initializes the Double Ratchet prematurely and lets the user send messages before it is safe to do

Yes. I'll add a note :) But notice that according to the state machine, encrypted messages should only be received on the ENCRYPTED_MESSAGES state.

Maybe there is a compromise here: Bob does not need to generate Z (or our_ecdh_first) until after receiving Auth-R, since Alice does not use it until having received Auth-I. Shrinking the lifetime of an ephemeral key always seems like a good idea. So maybe keep the handshake the way it is but delay generating Z?

Note that the last message can be interpreted as a combined Auth-I message and an empty Data Message, which functions just to send Z so that Alice can finalize the ratchet initialization. Seen in that way, the protocol is a more direct implementation of the [DAKEZ] protocol. The initialization of the Double Ratchet also corresponds more closely to the [Double Ratchet] specification.

Yeah. I really don't know the security proofs for the AKE used in the Signal spec; but, for our case, it was debated that it was not a good idea.

[Sofía Celi]

Hey!

TBH I don't fully understand that proof, so you are probably right here. However, the current solution adds a different ephemeral key to the state that needs to remain stored in memory, so you have just moved the same problem to a different key. I doubt that the current solution wouldn't break the security proof.

As far as I remember, with the current 'extra' ephemeral keys, there is no problem. The problem was that the first ephemeral keys (X or Y) are used to not only derive the Mixed Shared secret but also for the Ring Signature. The 'extra' ephemeral keys are just used for double ratchet purposes.

Maybe there is a compromise here: Bob does not need to generate Z (or our_ecdh_first) until after receiving Auth-R, since Alice does not use it until having received Auth-I. Shrinking the lifetime of an ephemeral key always seems like a good idea. So maybe keep the handshake the way it is but delay generating Z?

The only problem with that is that the Auth-I message will become a little too big. But I think it can be done. Let me recheck with Nik :)

[Sofía Celi]

Ok, so after reviewing some notes:

The reason why the double ratchet first ephemeral keys are included in the Identity message are to:

1. Optimize the participant initiating the DAKE to be able to send data messages (notice that the DAKE does not need to be started only with a query message).
2. Include these ephemeral keys as part of Phi (which is part of the Ring Signature).

Therefore, I'll add the warning/note.

[Sofía Celi]

I added some thoughts to different parts of the spec. I'll check them tomorrow. @sebastianv89 do you think is enough? Thanks!

[Sebastian]

I am surprised that Alice must authenticate Bob's extra ephemeral key, but if that is true then I withdraw my proposal, as the existing solution seems the best way to include both extra ephemeral keys in Phi.

The additions you provided in the spec look good to me, with one nitpick from my end:

Alice is not able to send data messages at this point, as she needs to receive the 'Auth-I' message from Bob.
...
When receiving an Identity message, note that the participant cannot start sending data messages
...
Note that after receiving an Indentity message, a participant can't start sending data messages.

Technically they can, but they shouldn't. I suggest replacing cannot with must not, as follows:

• Alice must not send data messages at this point, as she needs to receive the 'Auth-I' message from Bob.
• When receiving an Identity message, note that the participant must not start sending data messages
• Note that after receiving an Indentity message, a participant must not start sending data messages.

For the record, I'm not seeing why the other reasons you give invalidate the proposal:

The only problem with that is that the Auth-I message will become a little too big.

The Auth-I message contains only a single ring-signature, whereas Auth-R includes a ring-signature and a Client Profile, two ECDH public keys and a DH key. Adding a single ECDH public key should be fine.

Optimize the participant initiating the DAKE to be able to send data messages (notice that the DAKE does not need to be started only with a query message).

I'm not sure what optimization you refer to here. Either party must not send data messages until after having received the ring-signature of the other party. In both my proposal and the current implementation both parties can securely start sending data messages at the same time.

[Sofía Celi]

I am surprised that Alice must authenticate Bob's extra ephemeral key, but if that is true then I withdraw my proposal, as the existing solution seems the best way to include both extra ephemeral keys in Phi.

Yeah, this is something that was strongly suggested :)

The Auth-I message contains only a single ring-signature, whereas Auth-R includes a ring-signature and a Client Profile, two ECDH public keys and a DH key. Adding a single ECDH public key should be fine.

Yeah, I agree on this. The Auth-R is long already.

I'm not sure what optimization you refer to here. Either party must not send data messages until after having received the ring-signature of the other party. In both my proposal and the current implementation both parties can securely start sending data messages at the same time.

We tried to prioritize the case where a participant starts the interactive DAKE with an identity message, so it is faster from them to do it. But it is not that important.

[Sofía Celi]

The wording has been fixed :)