Verified Commit 9457f7e1 authored by Sofia Celi's avatar Sofia Celi
Browse files

Handle delayed messages of previous sessions #195

parent e56c1b2e
......@@ -2159,7 +2159,7 @@ Bob will be initiating the DAKE with Alice.
Note that he will not perform a new DH ratchet, but rather start using
the derived `chain_key_s[j]`. He should follow the
"When sending a data message in the same DH Ratchet:" subsection and
attaches his ECDH and DH public keys to this message.
attach his new ECDH and DH public keys to this message.
* In the case that he receives a data message:
* Follows what is defined in the
[When you receive a Data Message](#when-you-receive-a-data-message)
......@@ -3316,17 +3316,19 @@ The decryption mechanism works as:
* Calculate `MKmac = KDF(usage_MAC_key || MKenc, 64)`.
* Use the `MKmac` to verify the MAC of the data message. If this
verification fails:
* Reject the message.
* Securely delete `skipped_MKenc[Public ECDH Key, message_id]`.
* Reject the message and delete `MKmac`.
* Set `nonce` to 0.
* Decrypt the message by using the nonce and only the 32 bytes of `MKenc`:
* Try to decrypt the message by using the nonce and only the 32 bytes
of `MKenc`:
```
decrypted_message = ChaCha20_Dec(MKenc, nonce, m)
```
* Securely delete `MKenc`.
* Add `MKmac` to the list `mac_keys_to_reveal`.
* If sucessful, securely delete `MKenc` and `extra_symm_key` (if not
needed). Add `MKmac` to the list `mac_keys_to_reveal`. Otherwise,
delete `MKmac`.
* Securely delete `skipped_MKenc[Public ECDH Key, message_id]`.
* If `max_remote_i_seen` > `ratchet_id`:
* If the received `message_id` and `Public ECDH Key` are not in the
......@@ -3404,12 +3406,10 @@ The decryption mechanism works as:
```
* Use the `MKmac` to verify the MAC of the message. If the verification fails:
* Reject the message.
* Delete the derived `MKenc` and `MKmac`.
* Delete the derived `MKenc`, `extra_symm_key` and `MKmac`.
* Otherwise:
* Derive the next receiving chain key:
`chain_key_r[k+1] = KDF(usage_next_chain_key || chain_key_r[k], 64)`.
* Securely delete `chain_key_r[k]`.
* Increment the receiving message id `k = k + 1`.
* Set `nonce` to 0.
* Decrypt the message by using the nonce and only the 32 bytes of `MKenc`:
......@@ -3420,6 +3420,8 @@ The decryption mechanism works as:
* If the message cannot be decrypted:
* Reject the message.
* Securely delete `chain_key_r[k]`.
* Increment the receiving message id `k = k + 1`.
* Securely delete `MKenc`.
* Set `their_ecdh` as the 'Public ECDH key' from the message.
* Set `their_dh` as the 'Public DH Key' from the message, if it is not
......@@ -3895,13 +3897,31 @@ In any event:
* Send a version `3 D-H Commit Message`.
* Transition authstate to `AUTHSTATE_AWAITING_DHKEY`.
#### Sending a Query Message after an offline conversation
#### Starting an online conversation after an offline one
In the case that a party received offline messages, comes online and wants to
send online messages:
* Send a TLV type 1 (Disconnected).
* Send a Query Message.
* Send a Query Message, a whitespace tag or an Identity message.
Note that in this case delayed messages from a previous offline conversation
can potentially be received when the online conversation has started
(in `ENCRYPTED_STATE`). For recommendations on how to handle this, check the
'OTRv4 recommendations for implementations' repository.
#### Starting an offline conversation after an online one
In the case that a party received online messages, the participant they are
talking to goes offline and they still want to send offline messages:
* Send a TLV type 1 (Disconnected).
* Request a Prekey Ensemble and send a Non-Interactive-Auth message.
Note that in this case delayed messages from a previous online conversation
can potentially be received when the offline conversation has started
(in `ENCRYPTED_STATE`). For recommendations on how to handle this, check the
'OTRv4 recommendations for implementations' repository.
#### Receiving a Query Message
......@@ -3994,6 +4014,11 @@ If the state is `ENCRYPTED_MESSAGES` or `FINISHED`:
* Reply with an Auth-R message.
* Transition to the `WAITING_AUTH_I` state.
Note that in this case delayed messages from a previous session
can potentially be received after the new DAKE has been established
(in `ENCRYPTED_STATE`). For recommendations on how to handle this, check the
'OTRv4 recommendations for implementations' repository.
Otherwise:
* Ignore the message.
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment