BoringSSL parity: ChaCha20

[woodruffw]

Tracking breakout from #7747, for ChaCha20.

Expected BoringSSL API: CRYPTO_chacha_20

CC @facutuesca 🙂

[facutuesca]

In progress

[woodruffw]

xref for Wycheproof: C2SP/wycheproof#90

[woodruffw]

From email discussions: integrating BoringSSL's ChaCha20 isn't straightforward, since BoringSSL strictly complies with RFC 7539 while LibreSSL and OpenSSL both use the original paper's 64/64 nonce/counter split.

Two possible routes forward:

1. Make a breaking change to the current ChaCha20 API: turn the current bytes nonce[16] into a bytes nonce[12], and internally initialize the counter word to either 0 or 1 (as suggested by the RFC)

• Pro: This will make the OpenSSL and LibreSSL behave as if they're RFC 7539 compliant, which is how the Cryptography docs state the public API behaves.
• Pro: This makes it easier to track the counter and fail a block operation if the counter overflows (i.e., after the 2^32 block limit specified in the RFC). Doing so might be overkill and would be a divergence from the current API behavior, so this is strictly optional.
• Con: This would reduce the internal block count of the OpenSSL and LibreSSL implementations to 2^32, rather than 2^64. This is arguably not a con at all, since it's what the RFC specifies.

2. Retain the current API, but wrap Boring's implementation so that the counter's overflow behavior matches that of LibreSSL and OpenSSL.

• Pro: API stability?
• Con: Turns an RFC compliant implementation into a non-complying one; also requires that Cryptography's documentation be updated to emphasize that the ChaCha20 API doesn't provide an RFC compliant implementation.
• Con: Adds a lot of complexity for a probably very rare edge case (expecting to share ChaCha20 outputs across implementations).

cc @alex and @reaperhulk for opinions/preferences here.

[alex]

We've decided to wontfix this -- the API was too gnarly relative to the benefits, given nearly all use cases are better served by the AEAD API.