# Incrementing nonces vs regular nonces?

I have recently been studying up on the lorawan protocol for IoT devices.

LoraWAN has a handshake, and then communication can commense. Messages are encrypted and MAC'ed. When encryption and MAC's are made, the values FCntUp and FCntDown are mixed in. FCntUp is used for Uplink messages, while FCntDown is for downlink.

Both of the values start at 0, and increment with every message, and then reset every so often.

So, my question is about the usage of these incrementing values. So I guess one alternative to having this incrementing-counter approach, would be just using regular, random nonces for every message that you could send with the message.

But what are the pros and cons of using regular random nonces vs incrementing ones. Which security features do they provide us respectively? My guess would be that random nonces are sligthly safer, since an adversary can predict what the nonce will be in the future.

• You can combine them; 1 2 Oct 14 at 18:30
• But, what is the encryption mode? Can't you use nonce-misuse resistance? scheme like AES-GCM-SIV Oct 14 at 21:57

I'll list the disadvantages of both

For random nonces:

• Random nonces obviously require a well seeded random number generator;
• There is more chance of a collision due to the birthday bound;
• Sequential nonces therefore usually require all bytes of the nonce (a counter could initially be encoded by a single byte);
• Random nonces need to be send separately from any other part of the message - keeping track of # of messages or using a message identifier doesn't work.

For sequential nonces:

• Sequential nonces are stateful, i.e. you need to keep state or you're prone to repeat them;
• There is a chance of collision if key values collide (this is a bit unfair, we generally don't have colliding keys, but maybe there is another weakness that can trigger identical key values);
• Sequential nonces may give away details of the protocol, as they are easily detected if sent with the message;
• It is required to specify endianness for random nonces (in e.g. WinZip a little endian counter was used for CTR mode, this is not common);
• You cannot use a random nonce and then e.g. switch to CBC mode which requires an unpredictable IV instead of just a nonce (without additional calculations; it is e.g. possible to encrypt the IV and use that value).
• If the nonce is chosen too small then the attacker knows exactly when they will start to "overrun" and repeat.
• Uh, that's most that I can come up with right now. I'll adjust if I can think of more. Made it a wiki post so that others can as well. Lists of objective advantages / disadvantages are generally never complete. Oct 14 at 21:37
• I've tried to find the encryption mode, however, it is paywalled The encryption scheme used is based on the generic algorithm described in IEEE 682 802.15.4/2006 Annex B [IEEE802154] using AES with a key length of 128 bits. Can you accces and see? Oct 15 at 20:38