From 36609c20e66663a11a678b30f5d0330b11bba62c Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Mon, 26 Aug 2019 20:30:23 +1000 Subject: [PATCH 1/2] Simplify ChaCha20 interface The nonce can just be opaque bytes. The block counter is tricky, as noted in the issue. The "obvious" choice is little-endian, as that is consistent with the philosophy of the designer (as I understand it), but that is not anything more than a guess. Absent strong evidence that big-endian is a better choice, I'm going to err on the side of not making a substantive change here. But I think that we need a consensus call to support that viewpoint. Closes #2171. --- draft-ietf-quic-tls.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/draft-ietf-quic-tls.md b/draft-ietf-quic-tls.md index 1af599324d..4d9b142dbf 100644 --- a/draft-ietf-quic-tls.md +++ b/draft-ietf-quic-tls.md @@ -1049,16 +1049,16 @@ function as defined in Section 2.4 of {{!CHACHA}}. This uses a 256-bit key and 16 bytes sampled from the packet protection output. The first 4 bytes of the sampled ciphertext are interpreted as a 32-bit number -in little-endian order and are used as the block count. The remaining 12 bytes -are interpreted as three concatenated 32-bit numbers in little-endian order and -used as the nonce. +in little-endian order and are used as the block count; a ChaCha20 +implementation might instead take the 4 bytes as an opaque sequence of bytes. +The remaining 12 bytes are used as the nonce. The encryption mask is produced by invoking ChaCha20 to protect 5 zero bytes. In pseudocode: ~~~ counter = DecodeLE(sample[0..3]) -nonce = DecodeLE(sample[4..7], sample[8..11], sample[12..15]) +nonce = sample[4....15] mask = ChaCha20(hp_key, counter, nonce, {0,0,0,0,0}) ~~~ From b0f00edf9f8ba7139a6b7a2c36edd44112de5482 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Fri, 6 Sep 2019 10:51:44 +1000 Subject: [PATCH 2/2] Simplify more --- draft-ietf-quic-tls.md | 17 +++++++++++------ 1 file changed, 11 insertions(+), 6 deletions(-) diff --git a/draft-ietf-quic-tls.md b/draft-ietf-quic-tls.md index 4d9b142dbf..2c544a3cb7 100644 --- a/draft-ietf-quic-tls.md +++ b/draft-ietf-quic-tls.md @@ -1048,21 +1048,26 @@ When AEAD_CHACHA20_POLY1305 is in use, header protection uses the raw ChaCha20 function as defined in Section 2.4 of {{!CHACHA}}. This uses a 256-bit key and 16 bytes sampled from the packet protection output. -The first 4 bytes of the sampled ciphertext are interpreted as a 32-bit number -in little-endian order and are used as the block count; a ChaCha20 -implementation might instead take the 4 bytes as an opaque sequence of bytes. -The remaining 12 bytes are used as the nonce. +The first 4 bytes of the sampled ciphertext are the block counter. A ChaCha20 +implementation could take a 32-bit integer in place of a byte sequence, in +which case the byte sequence is interpreted as a little-endian value. + +The remaining 12 bytes are used as the nonce. A ChaCha20 implementation might +take an array of three 32-bit integers in place of a byte sequence, in which +case the nonce bytes are interpreted as a sequence of 32-bit little-endian +integers. The encryption mask is produced by invoking ChaCha20 to protect 5 zero bytes. In pseudocode: ~~~ -counter = DecodeLE(sample[0..3]) -nonce = sample[4....15] +counter = sample[0..3] +nonce = sample[4..15] mask = ChaCha20(hp_key, counter, nonce, {0,0,0,0,0}) ~~~ + ## Receiving Protected Packets Once an endpoint successfully receives a packet with a given packet number, it