is the constant crypto_aead_xchacha20poly1305_ietf_MESSAGEBYTES_MAX wrong? about libsodium HOT 4 CLOSED

The constant looks correct.

ChaCha has 16 bytes to share between the nonce and the counter.

For the needs of TLS, the IETF version uses 12 bytes for the nonce, 4 for the counter:

NNNNNNNNNNNNCCCC

The original version uses 8 bytes for the nonce, 8 for the counter.

NNNNNNNNCCCCCCCC

Now, XChaCha uses a 24 byte nonce. 16 bytes of it are going to be the sub-key, and there are 8 bytes left for the actual sub-nonce. So we have 8 bytes left for the counter.

nnnnnnnnCCCCCCCC

If an implementation only supports 4 bytes counters and requires 12 bytes for the nonce, it's still possible to build XChaCha in a compatible way until 2^32 blocks:

nnnnnnnn0000CCCC

32 bits would always be zero, so usage would be limited to the IETF limits. That limit would be very artificial.
But if you need to reuse a library that only supports 4 byte counters, and implement XChaCha by only adding HChaCha, you will indeed have that limit.

libsodium supports 8 bytes counters so doesn't have that limit. Internally, it's called crypto_stream_chacha20_ietf_ext, as the authenticator is computed as with ChaCha20-iETF, but we allow the counter to be 8 bytes.

from libsodium.

Hmm I see. So it sounds like for XChaCha20-Poly1305, there is effectively no difference between the IETF and non-IETF variants (or maybe another way to think about it is, there is no such thing as non-IETF XChaCha20-Poly1305?), since both of them use 8 bytes of nonce and 8 bytes of counter after the HChaCha20 step?

from libsodium.

Yes, even the libsodium crypto_aead API has only one version.

from libsodium.

Thank you for clearing it up for me!

from libsodium.