Daiki Ueno <[email protected]> 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-header-prote
Out of curiosity, are you aware on any quic implementation using Nettle? > 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. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance. _______________________________________________ nettle-bugs mailing list [email protected] http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
