1

I am aware that using a counter or a random value are both acceptable ways of generating nonces, depending on the circumstances.

The tradeoff with using a counter is the necessity to keep state and sometimes this can be a complex problem on its own.

The tradeoff with using a randomly generated nonce is the possibility (even if perhaps astronomically low) of generating the same nonce twice. Please note that I am aware that there are some cryptographic functions that are designed to be resistant to nonce reuse.

Assuming I'm not confident in my system's ability to reliably keep track of a counter, that I am not using a cryptographic function that's resistant to nonce reuse and that I am not assured in leaving nonce generation up to a PRNG, would I be able to significantly lower the probability of nonce reuse if I implemented both a counter as well as a random nonce, compared to the case that I either (xor) use a counter or a random nonce?

elemetrics
  • 146
  • 4
  • 2
    If you want to prevent a nonce from being used twice (which is required to defeat replay attacks), your server cannot be stateless. But you said you cannot reliably keep track of a counter, so I assume you cannot reliable keep track of already used nonces either... How do you intend to handle this? It seems accidentally generating the same nonce twice is the least of your problems in such a situation. Or did I misunderstand your problem? – Marc Schütz Feb 16 '19 at 17:09
  • I think in the case you can't keep state and use a counter, you can at least minimize the likelihood of nonce reuse by generating the nonce at random. However, my question was, what if I used a counter nonce AND a random nonce, so that in the event the counter failed and generated the same nonce for two messages (for example in the event of a system restart), the system could at least somewhat rely on the random nonce to have made the two messages different – elemetrics Feb 16 '19 at 22:19
  • Your title mentions replay attacks, but I see nothing about that in the question. Did you actually just mean nonce reuse? – AndrolGenhald Feb 18 '19 at 14:39
  • Hi @AndrolGenhald I was under the impression that preventing nonce reuse (depending on the implementation) implicitly protected against replay attacks. I guess you could say my primary question is about preventing nonce reuse. – elemetrics Feb 18 '19 at 16:23
  • 1
    @elemetrics The trouble is that "nonce" is too general a concept with too many different applications to tell what you're talking about. The nonce used in CTR mode encryption for example is completely different from the nonce used in HTTP Digest auth. Is the purpose of the nonce to be used for encryption (in which case you only care about generating a nonce that hasn't been used before with high probability) or for preventing replays (in which case you have to ignore a request if the nonce has been previously used), or both? – AndrolGenhald Feb 18 '19 at 16:40
  • 1
    Sorry for the confusion. My thinking about this is completely off. I realize now what @MarcSchütz was saying, that in order to prevent replay attacks I would actively have to keep track of the messages that have already been accepted. My original thinking was that merely using a random nonce in each message would prevent a replay attack. I now realize this is impossible because an attacker could simply reuse a message containing a "random" nonce and the server would be none the wiser. Sorry for wasting your time fellas. – elemetrics Feb 18 '19 at 18:42

0 Answers0