Key confirmation and other benefits of double ratchet I'm trying to understand a comment from the Signal blog post Advanced cryptographic ratcheting.

This article uses the term OTR ratchet to refer to a simple asymmetric DH ratchet, where Alice contributes a new $g^{a_i}$ with every message and Bob contributes a new $g^{b_j}$. The current key is taken to be $g^{a_{i} b_{j}}$ for the maximum $i$ &amp; $j$.

It uses the term SCIMP ratchet to refer to a simple symmetric ratchet, where the key is continuously and deterministically evolved through a KDF for each message.

Then finally the article motivates their double ratchet as a combination of the two.



My question is about the benefits of the double ratchet as articulated in this article.

The article does mention what I understand to be the main advantage: OTR ratchet itself has suboptimal forward secrecy. If Bob just sent a message, his latest DH secret key must still be in memory (since it will be used in the next DH round and combined with Alice's next DH message). Then a state compromise will allow the attacker to read the message that was just sent.

On the other hand, with the double ratchet the DH shared key is combined with the chain key. Bob's DH secret key (without the previous chain key) is not enough to decrypt the message that he just sent.

That's what I understand. What I don't understand is the insistence that OTR ratchet requires 3 rounds while the double ratchet requires 2. This is repeatedly described as an important benefit of the double ratchet. The article describes OTR ratchet as a normal 2-round DH followed by a 3rd round "acknowledgment":


  until Bob has acknowledged Alice’s next key, she can’t use it


...later:


  We wanted to incorporate a DH ratchet into our ratcheting protocol because of the “future” secrecy it provides. However, it would be nice if we could eliminate the “advertise” step in the OTR ratchet and bring it down to a “two step” ratchet. In order to achieve a “two step” ratchet, we derive a RootKey in our initial handshake KDF, and both mix it into and re-derive it from every subsequent DH KDF. This makes it possible to chain the key material together so that Alice can create and use a new DH ephemeral key immediately without first advertising it and waiting for acknowledgment.


Let's say your only goal is to avoid the key acknowledgement step. Surely you don't need to do a double ratchet -- just simply don't do key acknowledgement! Do a DH ratchet where Alice sends $g^a$, Bob sends $g^b$ and immediately encrypts something with $g^{ab}$. Why does this article say that the parties "can't" use $g^{ab}$ until Alice acknowledges? I'm willing to believe that OTR does this in practice, but I don't understand why it presents some kind of fundamental barrier. What really goes wrong if you use the key right away?

Again, I understand the double ratchet benefits of ideal forward secrecy (it can protect the message that was most recently sent, while simple DH asymmetric ratchet doesn't [and I know that performing 2 parallel DH that are out of phase by 1 round is another way achieve the same thing without a double ratchet]). But I don't understand the implication that double-ratchet is the only way / best way to allow immediate key use and do away with an extra acknowledgement round. What am I missing?
This is convenient because each new key is used one-time and depends on the root key and message, so you do not need to constantly announce the next new key and wait for confirmation.  If Bob reads the encrypted message, he knows the encryption key and can decrypt the next message.  Since by exchanging messages that need to be decrypted, you get the opportunity to know how to decrypt the next message.  This is what is called “future” encryption in the article.  Thus, we have only one root key and constantly changing ephemeral keys, which are obtained from the messages themselves.  This allows you to simply communicate while being sure that the protection is very reliable.  I recommend reading the source code for this article from 2013.  Maybe this can clarify the principle.  A potential attacker, even if he intercepts the original message and all subsequent ones, will not be able to push off from something to start the attack, because he will have messages that are always encrypted with different keys and depend on encrypted messages that need to be decrypted.