Daiki Ueno ueno@gnu.org writes:
From: Daiki Ueno dueno@redhat.com
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-...
This will add a new function chacha_set_counter, which takes an 8-octet initial value of the block counter.
I've merged all three patches to master-updates. Two nits below:
+void +chacha_crypt32(struct chacha_ctx *ctx,
size_t length,uint8_t *c,const uint8_t *m)+{
- if (!length)
- return;
- for (;;)
- {
uint32_t x[_CHACHA_STATE_LENGTH];_chacha_core (x, ctx->state, CHACHA_ROUNDS);++ctx->state[12];/* stopping at 2^70 length per nonce is user's responsibility */
Should be 2^38, not 2^70, right?
+Nettle's implementation of ChaCha-Poly1305 follows @cite{RFC 8439}, +where the ChaCha cipher is initialized with a 12-byte nonce and a 4-byte +block counter. This allows up to 256 gigabytes of data to be encrypted +using the same key.
Should be "same key and nonce"; the counter size limits the size of a message, but the nonce allows for many messages using the same key.
I'll fix these.
It would be nice with a test case where the first 32 bits of the counter wrap around, which is the only case where chacha_crypt and chacha_crypt32 behave differently. Is that something you can look into?
Thanks! /Niels