[Cryptography] Ratcheting

Brendan Farmer bpfarmer at gmail.com
Tue Sep 1 13:11:55 EDT 2015

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.

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).

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20150901/a368cd20/attachment.html>

More information about the cryptography mailing list