<div dir="ltr">I think that it's important to note that cryptographic ratcheting is important both for reducing the impact of a key leak, but also minimizing the amount of time that encryption keys are stored on a filesystem.<div><br></div><div>It's my understanding that the design choices for Axolotl are motivated more by the fact that it's designed to work for highly-asynchronous communications than to support SMS (in fact, they don't support SMS transport anymore). In this case, ratcheting makes more sense than in the case of a short-lived synchronous session. When you consider the ratchet case (B) with highly-asynchronous communication, if Alice and Bob perform a key-exchange at the beginning of a conversation that lasts for several weeks, and there's no ratcheting step, then both parties must retain these message keys for several weeks, on the filesystem, not just in memory. Also, if you're using an encrypt-then-HMAC scheme, having a non-ratcheting MAC key that's compromised would be harmful (though not as serious as losing an encryption key for an entire conversation).</div><div><br></div><div>Now, you might argue that the threat model remains the same, with the addition of a (T4) that's analogous to T2/T3 but for the filesystem instead of for memory. In my opinion, since the probability of a key compromise is directly related to the key's lifetime, and ratchets like Axolotl aren't prohibitively complicated, it's worth the expense to adopt a ratcheting protocol. Not to say that protecting your implementation against side-channel vulnerabilities isn't important, but adopting a ratchet is a step that, to me, clearly appears to increase security. </div></div>