Figure out how much of the current OTR packet structure to change to get double ratcheting working about otrv4

[rosatolen]

@natalieesk I think we should be defining them. OTRv3 specifies SHA256-HMAC keys, 128 bit AES encryption keys, and SHA-1 for the MAC keys.

[rosatolen]

Updated

Todos:

• Remove unnecessary description of the Double Ratchet Algorithm since this is a well known standard described here
• Decide if the transition from the DAKE to the double ratchet in Nik's paper (p.116) is the best way to transition
• Describe what errors can happen and what to implement in response to those errors
• Describe what keys should be revealed from the Double Ratchet Algorithm to achieve deniability

Details: decide what variations of the double ratchet should be included in the protocol:

• Including in the spec whether header encryption can be omitted for situations where the underlying transport already reveals metadata
• Whether we should include a time limit for updating the chain keys

[natalieesk]

As discussed in stand up this morning, the final paper does not specify which KDFs to use. I am investigating different KDFs and which ones different double ratchet implementations use.

This is my current understanding:

There are two kinds of KDF, ones that take keys as arguments, and others that take passwords (known sometimes as PBKDF, so when you hash a password that uses a KDF). The difference is in the entropy level that you decide what kind you need. We would need to use one that takes keys as arguments both times.

We use different KDFs for:

1. deriving the root key and chain key from the shared secret
2. deriving the MAC and encryption keys from the chain key

TextSecure uses HKDF (HMAC based Key Derivation Function) for both

I’ve found a range of other KDFs that I’m looking into now.

[natalieesk]

I'm also wondering whether we should define the KDF in the protocol or implementers should choose themselves?

[rosatolen]

I've pushed the draft of the Data Exchange section here: 651d099

Review Checklist

• Does it read clearly?
• Should we use a different word than "storage" and "storedDHR" to denote how a newly received DH Ratchet key is used to decrypt messages and then to send the next ratchet messages?
• Should we be more clear about when keys can be deleted? i.e. Delete the current root key when you create the next root key.

[juniorz]

I've added questions to the commit. I think we should also define generateECDH().

[juniorz]

• How to reveal MAC keys in the context of double ratchet?

[tcz001]

afe9465