Hello,
nisse@lysator.liu.se (Niels Möller) writes:
Daiki Ueno ueno@gnu.org writes:
The ChaCha20 based header protection algorithm in QUIC requires a way to set the initial value of counter: https://quicwg.org/base-drafts/draft-ietf-quic-tls.html#name-chacha20-based-...
Out of curiosity, are you aware on any quic implementation using Nettle?
There is an ongoing effort to add an ngtcp2 backend based on GnuTLS, which surely uses Nettle under the hood: https://gitlab.com/gnutls/gnutls/-/merge_requests/1197
This will add a new function chacha_set_nonce128, which takes the counter value embedded in the nonce.
I see two issues with this change as is.
First is purely an interface design issue. It may be more useful to have a separate function to set the 32-bit counter. E.g., that would be convenient for random access to a chacha-encrypted file.
The other is more subtle and with interop implications. The way the counter is currently updated in chacha_crypt still assumes a 64-bit counter (as in the original chacha papers with 64 bits each for nonce and counter). This is compatible with RFC 8439, as long as the counter is initialized to a small value such as 0 or 1. But if counter is initialized to a random 32-bit value, and is expected to wrap around mod 2^32, then Nettle will not work as expected but propagate carry into the first 32-bits of the nonce.
Not sure how to best deal with this.
It looks like chacha was added in Nettle-3.0, and chacha_set_nonce96 added in Nettle-3.1 (undocumented and used in the implementation of ChaCha-Poly1305). The Nettle-3.1 release also updated chacha-poly1305 to follow draft-irtf-cfrg-chacha20-poly1305-08 (which later evolved into RFC 8439, if I understood the document history correstly). It seems this change is not documented in the manual or in NEWS; the manual still says that chacha-poly1305 use 64-bit nonce and is experimental.
For the QUIC use, I guess it would be acceptable that the 32-bit counter value is only accessible from the chacha_poly1305_* interface (i.e., chacha_poly1305_set_counter), as we would just need to trim the Poly1305 tag at the end of the ciphertext.
Regards,