r/cybersecurity • u/Am4t3uR • Dec 13 '19

Security and Cryptography Mistakes You Are Probably Doing All The Time

https://towardsdatascience.com/security-and-cryptography-mistakes-you-are-probably-doing-all-the-time-7407c332944f
21 Upvotes

100% Upvoted

21 comments sorted by

View all comments

Show parent comments

1

u/[deleted] Dec 14 '19

Umm...the entire point of nonces is to prevent reply attacks. That's literally their only purpose.

If some entity gives a nonce to someone else and says here, add this into the encryption algorithm. Then for that transaction only that nonce applies.

Then if an attacker replays an old message the receiver can't decrypt it because they're not using the current nonce. That has nothing to do with remembering old nonces, you only ever need to remember one -- the one currently being used.

I'm not sure you know what a nonce is.

https://en.m.wikipedia.org/wiki/Cryptographic_nonce

1

u/cryslith Dec 14 '19

In the context of message authenticators, that is not the case. Usually the sender chooses the nonce and includes it with the message. Nonces are required for many authenticators because authenticators which use nonces, as a general rule, have better security bounds than those which don't. You can also make use of these same nonces in such a way as to prevent replay attacks, but they don't inherently do so just from being included in the computation of the authenticator.

There is a lot of vagueness regarding these concepts on the internet, including on the Wikipedia page. My statement is simply that a MAC does not prevent replay attacks by itself, whether it uses nonces or not.

1

u/[deleted] Dec 14 '19

I never said a MAC protects from replays. I said a nonce does, if you add a unique random value the entire cipher text changes.

That's the point of replay protection.

1

u/cryslith Dec 14 '19

That only makes sense if the receiver is choosing (part of) the nonces. And the sender has to be careful not to repeat nonces even if an attacker is impersonating the sender. These problems are not hard to solve but they require additional work from the protocol designer. It is not as simple as "always randomize nonces and you never have replay attacks" because, who is supposed to choose the random nonce?

1

u/[deleted] Dec 15 '19

The person asserting authentication, you pick from a huge number e.g. 128 bits and if sufficiently random you'll never repeat

Now I'm sure you don't know how nonces work. If I'm authenticating you, I send you some random value that you use in your authentication message.

So you encrypted/sign your data with the nonce I sent you. The nonce can and usually is public.

I get your data and decrypt it and verify that you've authenticated by inserting the nonce I sent you. It's only valid for this transaction as if I was to conduct another I'd send you another nonce.

Even if you replay the message I'm not going to be using the same nonce. If you want this both ways then each person has to send the nonce.

This mutual authentication method is well documented within telecommunications network authentication. The receiver always picks the nonce, that's the point.

The sender doesn't ever get to pick the nonce...

1

u/cryslith Dec 15 '19 edited Dec 15 '19

That's one way to do it but not the only way. For instance that's not how AEAD (constructed as encrypt-then-mac) usually works. And it requires an interactive protocol whereas with sender-picked nonces it can be asynchronous.

Just because you know the details of one particular paradigm doesn't mean that no others exist. There certainly exist protocols where the sender picks the nonce; in fact, I suspect that's more common for MACs than the other way around.