The Noise Protocol Framework

The Noise Protocol Framework (Trevor Perrin, 2016; current revision 2018) is a framework for building secure channel protocols using a small set of primitives and a pattern language. Instead of specifying a single protocol, Noise defines a vocabulary of handshake patterns that describe the sequence of DH operations and their order. Any valid Noise pattern can be instantiated with concrete DH (Curve25519 or Curve448), cipher (AESGCM or ChaChaPoly), and hash (SHA-256, SHA-512, BLAKE2) functions. Noise is used in WireGuard, WhatsApp, Signal (as the basis of X3DH), Lightning Network, and I2P.

Every Noise handshake has an initiator (I) and a responder (R). Each party may have two types of keys: static (long-term identity key, denoted s/S) and ephemeral (generated fresh per session, denoted e/E). Lowercase letters denote the local party's key; uppercase denotes the remote party's public key. A Noise pattern specifies which keys are sent (as plaintext or encrypted) and which DH operations are performed. For example, "e" means "send my ephemeral public key"; "es" means "perform DH(my_ephemeral, remote_static)". Each DH output is mixed into the handshake's running hash state.

Noise's core is the SymmetricState, which maintains three values: ck (chaining key, initialized to a protocol name hash), h (handshake hash, the running transcript hash), and k (current encryption key). MixKey(input) runs HKDF(ck, input) to update ck and k. MixHash(data) hashes data into h. EncryptAndHash(plaintext) encrypts with k and mixes the ciphertext into h. DecryptAndHash(ciphertext) decrypts and mixes the ciphertext into h. The handshake hash h provides transcript binding — any adversarial modification of any message changes h, causing decryption to fail. At the end of the handshake, Split() produces two separate CipherStates for sending and receiving.

Noise_XX is the most commonly used mutual authentication pattern. It provides mutual static key authentication with both parties's static keys transmitted during the handshake. Pattern: (1) -> e (initiator sends ephemeral public key). (2) <- e, ee, s, es (responder sends ephemeral, performs DH(e,e) and DH(e,s_resp), sends encrypted static key). (3) -> s, se (initiator sends encrypted static key, performs DH(s_init, e_resp)). After step 3, both parties have mixed three DH outputs into the session key: ee (forward secrecy), es (server auth), se (client auth). The session key is independent of any long-term key compromise after the session ends.

WireGuard uses a pattern derived from Noise_IK where the initiator knows the responder's static key in advance. (1) -> e, es, s, ss (initiator sends ephemeral, DH(e, S_resp), encrypted static, DH(s_init, S_resp)). (2) <- e, ee, se (responder sends ephemeral, DH(e_resp, e_init), DH(e_resp, S_init)). The IK pattern provides identity hiding for the initiator (their static key is encrypted under the responder's static key in step 1) and one-RTT completion. WireGuard adds a timestamp inside the encrypted initiator payload to prevent replay. This gives WireGuard its characteristic simplicity: a complete VPN handshake in two UDP packets.

The handshake hash h at the end of a Noise handshake is a transcript hash covering every message sent. This serves as a channel binding value — both parties compute the same h, and any third-party protocol that wants to bind to the Noise session can include h as a nonce or channel ID. This enables compound authentication: a TLS-style certificate authentication step can run after the Noise handshake, binding the certificate to this specific session via h. Channel binding prevents credential forwarding attacks where authentication credentials from one session are replayed against another. Split() provides h to the application alongside the session keys.

Noise supports deferred patterns for situations where the initiator does not know the responder's static key in advance. Noise_NX (initiator has no static key; responder transmits theirs) is analogous to one-way TLS. Noise_XX handles the case where both need to exchange keys. Noise_IK can fall back to Noise_XXfallback if the initiator's guess at the responder's static key is wrong (e.g., after a key rotation). The fallback pattern allows the responder to signal "you used the wrong key; here is my new public key" without revealing that the fallback occurred to external observers — maintaining protocol opacity.

WhatsApp and Signal use Noise_XX for establishing secure channels between clients and servers. WhatsApp's binary protocol uses Noise_XX with Curve25519, ChaChaPoly, and SHA-256. The client's static key is its long-term identity key. After the Noise handshake, the application layer runs additional authentication (Signal registration, phone number verification). Signal's X3DH (Extended Triple Diffie-Hellman) key agreement performs four DH operations to establish a shared secret between two users via an asynchronous message exchange — this is not a standard Noise pattern but uses similar DH-mixing concepts. The Double Ratchet then takes over for ongoing message encryption.

Noise and TLS 1.3 address the same problem (authenticated key exchange) with different philosophies. TLS 1.3 is a single protocol with prescribed cipher suites, certificate formats (X.509), and extensions. It is designed for web browsers and servers — a one-size-fits-most protocol. Noise is a framework: it specifies no certificate format, no PKI, no transport binding. This makes Noise smaller (WireGuard's entire Noise implementation is under 400 lines of code) and easier to reason about formally, but requires the application to handle identity management separately. Noise is preferred for closed systems (app-to-server, VPN) where PKI is overkill; TLS for open systems (web) where certificate interoperability is needed.

Noise patterns have been formally analyzed in the eCK (extended Canetti-Krawczyk) security model. Kobeissi, Bhargavan, and Blanchet analyzed Noise using Proverif and found proofs for authentication and key confidentiality for all 12 fundamental Noise patterns. The proofs assume the standard DH hardness assumption (Curve25519) and the security of the underlying AEAD and hash functions. The compositional nature of Noise (each DH is mixed incrementally) makes it easier to reason about than complex TLS-like protocols with many state transitions. Cryptographic verification of Noise gave WireGuard and WhatsApp high confidence in their protocol security before deployment.

Common Noise implementation pitfalls: (1) Pattern confusion — using Noise_IK when the responder's static key is not reliably pre-distributed leads to identity mismatch (the initiator may silently encrypt to a wrong key). (2) Replay protection — Noise provides authentication but not replay protection of the Transport phase messages; nonces (64-bit counter) must be enforced and wrap-around (after 2^64 messages) must trigger rekeying. (3) Prologue integrity — the Noise prologue (a bytestring mixed into h before the handshake starts) must include all protocol context (version, algorithm choices) to prevent downgrade attacks. (4) PSK misuse — Noise supports PSK extensions for pre-shared key mixing; PSKs must be high-entropy, not user passwords.

What does the Noise pattern notation "es" mean in a handshake pattern?

Noise is a framework for building authenticated key exchange protocols using a pattern language of DH operations. SymmetricState maintains chaining key (ck), transcript hash (h), and cipher key (k), updated by MixKey/MixHash. Noise_XX provides mutual authentication in 1.5 RTT; Noise_IK (WireGuard) completes in 1 RTT with known responder key. The handshake hash h serves as channel binding. Noise is formally verified for all core patterns via Proverif. It is preferred over TLS for closed-system protocols (WireGuard, WhatsApp) where PKI is unnecessary. Correct implementation requires replay protection, prologue integrity, and high-entropy PSKs.