crypto_secretbox without nonce parameter

[Apromixately]

In many cases specifying a nonce is an unnecessary burden on the API caller and doesn't add any benefit. Could there be a version which generates a nonce internally?

This would also cover problems where people don't know how to generate proper randomness.

[jedisct1]

The nonce is critical for security. Every message encrypted with a given key must must encrypted with a unique value for that parameter. It doesn't have to be random nor secret, just unique.

secretstream creates the nonce for you. It also ensures that messages cannot be dropped, duplicated or reordered. If you are planning to send more than one message per key, this is usually what you want.

In most protocols, the nonce is a simple counter, or anything the sender and the recipient can compute deterministically. So it doesn't have to be sent along with the ciphertext.

[Apromixately]

Cool, thanks. I didn't think of using secretstream!
Doesn't the same argument why secretstream creates the nonce for you apply to secretbox as well?

I mean, I understand what you're saying but I still think it would be harder to misuse if there was just an option to get a random nonce. And random is a good option if the nonce is large enough and avoids accidental replay when a counter is reset for whatever reason.

[jedisct1]

And random is a good option if the nonce is large enough and avoids accidental replay

This is pretty much the opposite. Random nonces enable replay attacks, unless the receiver keeps track of all the previously observed nonces, which has a cost, and doesn't prevent messages from being reordered or dropped. They are fine if only ONE message should ever be sent with a given key. In all other cases, nonces should be deterministic (unless you're abusing the AD for that, but secretbox is not an AEAD).

[Apromixately]

Sorry, poor choice of words. I didn't mean "replay" in the sense of "replaying a sent message". I meant reusing the counter for a different message because the state of your program got reset somehow.

If people find it easy to consistently keep state, they can use that for the nonce, of course. But that is known to be difficult. A random nonce is a simple solution.

For actual replay protection, I would say secretstream needs to be used anyway, right? Because otherwise you would somehow have to check for replays on the receiver side.