feat: add the Noise_IKpsk2_25519_AESGCM_BLAKE2s cipher suite - #250
Draft
thomaseizinger wants to merge 8 commits into
Draft
thomaseizinger wants to merge 8 commits into
thomaseizinger wants to merge 8 commits into
Conversation
On CPUs with hardware AES-GCM, AES-256-GCM is considerably faster than ChaCha20-Poly1305. `Tunn::set_cipher_suite` lets both peers opt into the AESGCM variant of WireGuard's Noise protocol, per peer. The default stays standard WireGuard. The suite follows the Noise spec: the handshake is seeded from its own protocol name, so peers with mismatched suites fail at the handshake. Handshake messages and transport data are both sealed with AES-256-GCM, using the big-endian nonce encoding the spec mandates for AESGCM. WireGuard's prologue, MACs and cookies are unchanged. AES-GCM's security degrades with the amount of data encrypted under one key. Following draft-irtf-cfrg-aead-limits, an AESGCM session schedules a new handshake after 2^27 messages and refuses to encrypt after 2^28, keeping the confidentiality advantage below 2^-57 for packets of up to 2 KiB. `parse_handshake_anon` accepts initiations of either suite, so a peer can still be looked up by its static key before its suite is known. The handshake and transport are checked for interoperability against `snow` for both suites.
A `Tunn`'s cipher suite must never change over its lifetime, so it is fixed at construction instead of being set afterwards. The deprecated `Tunn::new` uses the default suite.
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
| /// The Noise spec (section 12) prefixes the counter with 32 zero bits and encodes it | ||
| /// little-endian for ChaChaPoly but big-endian for AESGCM. | ||
| pub(crate) fn nonce(self, counter: u64) -> [u8; 12] { | ||
| let mut nonce = [0u8; 12]; |
…col name Precomputed byte arrays obscure where the values come from. Deriving them from the protocol name and WireGuard's identifier makes the construction readable, and caching them once per suite keeps handshakes from rehashing.
The AESGCM suite is not WireGuard, so it should not identify itself as WireGuard in its handshake transcript. The ChaChaPoly suite keeps WireGuard's identifier and stays byte-for-byte compatible.
The message limits are a property of the session, so test them on a `Session` directly instead of establishing a `Tunn` pair.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Adds a second Noise cipher suite,
Noise_IKpsk2_25519_AESGCM_BLAKE2s, next to WireGuard'sNoise_IKpsk2_25519_ChaChaPoly_BLAKE2s. The suite is chosen perTunnand defaults to ChaChaPoly, so existing users are unaffected.The AESGCM suite derives its initial chaining key from its own protocol name and uses AES-256-GCM, with the Noise spec's big-endian nonce encoding, for both the handshake and transport data. Peers with mismatched suites therefore fail at the handshake rather than on the first data packet. MAC1, MAC2 and cookies are WireGuard-specific and stay unchanged.
AES-GCM has much tighter per-key usage limits than ChaCha20-Poly1305, so sessions of that suite rekey after 2^27 messages and refuse to encrypt past 2^28, following draft-irtf-cfrg-aead-limits. A helper reports whether the CPU runs AES-GCM in hardware, so callers only negotiate the suite where it is actually faster. On AES-NI hardware, Firezone's iperf3 benchmarks showed 25 to 30% more TCP throughput over direct connections.
Related: firezone/firezone#15505