tree 13ad5b54b4bf4b11c41d5be7c55e2ba265536b63
parent 81345b84505e9c23c156b2c7a1e655a204bd3e9a
author David Benjamin <davidben@google.com> 1727189943 -0400
committer Boringssl LUCI CQ <boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com> 1727821443 +0000

Fix the endianness of DTLS 1.3 ChaCha20 record number encryption

The spec is a little bit unclear, but it passes the counter portion as
bytes:

>  Mask = ChaCha20(sn_key, Ciphertext[0..3], Ciphertext[4..15])

And then RFC 8439 says:

>  A 32-bit block count parameter, treated as a 32-bit little-endian
>  integer.

So I believe this means that, formally, the block count parameter is a
[4]uint8, not a uint32, and then ChaCha20 internally reads it as
little-endian. Our API takes a uint32, so it is the caller's
responsibility to pick little-endian.

This also matches the QUIC construction.

While I'm here, avoid an unnecessary two-byte allocation on every DTLS
1.3 record decryption. Functions like these generally can generally work
in-place.

Bug: 42290594
Change-Id: I879944ca533d37a1599d2170a00193caecd01f42
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/71547
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>