ChaCha20 IETF version vs DJB version

[piyush-kurur]

As far as I understand it, monocypher implements the djb version of chacha20, 64-bit counter, 64-bit nounce where as the RFC 7539 has a 32-bit counter and a 96-bit nounce. Would you want to move to the IETF version as that might be what protocols like tls and ssh will default to?.

[fscoto]

Monocypher 3.0.0 introduced the crypto_ietf_chacha20() and crypto_ietf_chacha20_ctr() functions. If you really need IETF ChaCha20 for compatibility reasons, you can get it from there.

crypto_lock() and crypto_unlock() use the DJB version. They can be reconstructed using the crypto_ietf_*() functions and the crypto_poly1305*() functions if need be. I do not expect this to change. If you need IETF ChaPoly, as far as I know, you can get it by adapting the crypto_lock() functions to use the IETF functions instead.

The reason for preferring the DJB variant as specified is that ChaCha20 is the worst of both worlds, so to speak: A 96-bit nonce is not quite large enough to always safely choose at random; at the same time, the 32-bit block counter causes a repeat of the ChaCha20 block for messages larger than approx. 256 GiB, subsequently leading to revealing the plaintext to an attacker that is aware of this. To discourage their use because of these properties—that at least I perceive as shortcomings, even though 256 GiB messages for a single (nonce,key) pair are rare and mostly impractical—the functions are somewhat hidden in the manual. Perhaps @LoupVaillant might be persuaded to include crypto_ietf_lock() variant, but considering Monocypher's paradigms (provide generally only one way to do things, try to minimize code size), I wouldn't bet on that.

I hope that helps clearing things up; if you have follow-up questions, please do feel free to ask.

[LoupVaillant]

Hi @piyush-kurur,

I agree with everything @fscoto just wrote: IETF Chacha20 is indeed the worst of both worlds, its properties are indeed shortcomings, and I do discourage its use.

I could be persuaded to publish crypto_ietf_lock() somewhere. Others have asked for it. I refuse however to include it in Monocypher itself. Maybe as an optional file. Most likely, I will put it in a separate repository.

[the IETF version] might be what protocols like tls and ssh will default to?

I don't know about the constraints TLS and SSH might have. Maybe the 96-bit nonce is right for them. I also know of one legitimate, though contrived, use case. For clean slate protocols however, the 96-bit nonce is never the best choice: either you need to be stateless, and nonces have to be long enough to be safely picked at random, or you want counters, and 64 bits are plenty.

Compatibility is not a goal for Monocypher. While I did chose popular primitives, I never sought to conform to existing protocols. If I did, I would have make sure we can implement (part of) TLS with Monocypher. That's just out of scope.

[piyush-kurur]

Sorry I seem to have missed the crypto_ietf_chacha20, was using the earlier version of monocypher. With that I do not think any more changes are required for Monocypher.

In any case either of the two version is fine for applications like TLS and SSH (due to the re-keying requirements) although I think they have standardised on the IETF version. And crypto_lock should probably use neither and stick to XChaCha20.

You may close this issue. One point though; you might want to add this information to the CHANGELOG.

[LoupVaillant]

One point though; you might want to add this information to the CHANGELOG.

Oops, yes I do, thanks for the tip. There, done (no touching the tarball, though, those are set in stone).