QUIC Crypto Primitives Support

[btoms20]

New API Proposal: QUIC Crypto Primitives Support

Request:

• Add support for AES-ECB under the Insecure umbrella struct
  • Used to generate the mask required for AES based Header Protection RFC 9001 - Section 5.4.3
• Add support for setting the 4 byte Counter alongside the Nonce/IV when initializing a ChaCha20 Cipher.
  • Used to generate the mask required for ChaCha20 based Header Protection RFC 9001 - Section 5.4.4

Importance:

Adds the missing cryptographic functions required to support the QUIC protocol as defined in RFC 9001

[Lukasa]

Thanks for this, this is a reasonable ask.

For the 4-byte Counter, this will need to be discussed with the CryptoKit team, I'll take that suggestion to them. For the AES-ECB use-case, I'll note that swift-crypto provides an AES block function primitive in _CryptoExtras (https://github.com/apple/swift-crypto/blob/d1047c1c9acd5681a48728c26d48ed9280f871d9/Sources/_CryptoExtras/AES/Block%20Function.swift#L33) which can be used to build up an AES-ECB implementation fairly trivially.

[FredericJacobs]

Hey @btoms20,

Thanks for this proposal. As @Lukasa said, we swift-crypto already provides the AES permutation function, from which you can do one-block ECB since you only need a single block for header protection.

Regarding the proposal to expose counters, the challenge is that counter is really an internal construct of ChaCha20 (which we don't officially support with POLY1305 authentication).

The swift-crypto API is really designed to be misuse resistant and exposing the counter through an API is clearly very risky, so we would likely make this some sort of an Insecure-prefixed extension function.

However, as it currently stands, we are not supporting stream ciphers without authentication. And therefore, it would be a bit of a stretch to have a way to set the counter on top of our existing AEAD API.

But we can keep this request to revisit this if we have any developments on unauthenticated stream ciphers.

[btoms20]

@Lukasa, thanks for pointing that out!

@FredericJacobs, sounds good and understood. Hopefully it can make its way into the Insecure API in the future.

Thanks for the quick responses!

[btoms20]

I had completely overlooked _CryptoExtras. Maybe if / when the Insecure ChaCha20 Counter extension gets implemented, it could be tucked away in _CryptoExtras with a not-so-public API and all of the appropriate / necessary warnings. That might help deter your average user from unknowingly misusing it.

[Lukasa]

It may be worth double-checking whether BoringSSL supports setting this flag. I did a quick scan earlier today and couldn't see an interface for it, but I might have missed something. If they don't, we'd want to make sure that they added that support. If they do, then you're welcome to open a PR to _CryptoExtras to add the feature directly.

[btoms20]

Hey @Lukasa, I followed your advice, did some digging, and found the BoringSSL function required to support this change. I implemented a rough PR #169 that I'd appreciate your feedback on when you get the chance.