8
$\begingroup$

In the answer to this question, a message counter is used to protect against replay attacks. Could a key ratchet be used instead? The basic idea is that with every message sent, the symmetric encryption key is replaced with a hash of itself. The receiver can then reject any messages that use previous keys.

The benefit of this approach is that a counter doesn't need to be sent on the wire, so bandwidth is saved. I'm designing a system where bandwidth is constrained, but computation not so much so performing a hash with every message is not a problem (and having the receiver possibly try multiple keys in the case of message loss is not a problem either).

Is using a key ratchet any less effective at protecting against replay attacks than a message counter? Are there any other reasons not to use such an approach?

Improve this question
$\endgroup$
5
  • $\begingroup$ If you can keep a ratchet in sync then you should also be able to keep a counter in sync, right? $\endgroup$
    – Maarten Bodewes ♦
    Mar 11, 2017 at 16:47
  • $\begingroup$ Sure, but a counter takes bandwidth (the counter needs to be sent) whereas a ratchet doesn't $\endgroup$
    – awelkie
    Mar 11, 2017 at 16:52
  • 1
    $\begingroup$ Why does the counter need to be sent? $\endgroup$
    – Maarten Bodewes ♦
    Mar 11, 2017 at 17:23
  • $\begingroup$ Oh, I guess it doesn't. You could use the counter as an initialization vector. This sounds very similar to using the ratchet, and it might be a better alternative for my use case. $\endgroup$
    – awelkie
    Mar 11, 2017 at 18:59
  • $\begingroup$ Note that I'm not advocating the use of the counter or ratchet, it's just that I didn't get the argument in the question. $\endgroup$
    – Maarten Bodewes ♦
    Mar 11, 2017 at 19:21

1 Answer 1

Reset to default
7
$\begingroup$

Yes, a ratchet is an effective way of preventing replay attacks. For example, the Signal Protocol does this (for reasons other than replay protection), and it is stated in a blog post that the replay protection "comes for free".

Since your transport protocol can lose messages, I would assume it also does not guarantee the ordering, so you will have to store some skipped keys. In fact, the Signal Protocol I just mentioned still sends a counter for this bookkeeping reason as you can see in the actual specification. You will have to decide if trying the skipped keys in order is computationally feasible. This issue is related to the first attack scenario described in the first answer of the question you linked: an attacker who can hold back messages and replay them at a later time would still be successful.

If you do not authenticate your messages, this scheme also enables DoS attacks - an attacker simply has to send enough messages to fill up the buffer of stored keys, and you will not be able to decrypt legitimate messages. While this prevents an attacker from using garbage data as keys, he can still use old messages with legitimate keys for this purpose. The result is that you have to keep track of old keys as well, add a counter, or invalidate old authentication tags by e.g. also evolving the key material used for signing.

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.