Noise Protocol Framework


The Noise Protocol Framework, sometimes referred to as "Noise" or "Noise Framework", is a public domain cryptographic framework for creating secure communication protocols based on Diffie–Hellman key exchange. Developed by Trevor Perrin, the framework defines a series of handshake patterns—predefined sequences of message exchanges—that outline how parties initiate communication, exchange keys, and establish shared secrets. These patterns can be combined and customized to meet specific security requirements, such as mutual authentication, forward secrecy, and identity protection.
Several popular software applications and protocols, including the messaging platforms WhatsApp and Slack and the VPN protocol WireGuard, have used implementations of the Noise Framework to ensure end-to-end encryption for user communications. The framework remains a topic of development, including post-quantum adaptations. The framework is currently at revision 34, published in July 2018.

History

Most secure channel protocols rely on authenticated key exchange using digital signatures and Diffie–Hellman. In the 2000s–2010s, interest grew in developing pure Diffie–Hellman-based AKEs, without signatures, leading to both theoretical and practical advancements. These were often developed from scratch. The Noise Protocol Framework was developed by Trevor Perrin, with support from Moxie Marlinspike, introducing two key innovations:
  1. Combining simple elements to construct various protocols.
  2. Using “sponge-like” symmetric cryptography, inspired by cryptographer Mike Hamburg's Strobe protocol framework.
The Framework evolved based on work initially conducted at Open Whisper Systems, the software organization from which the Signal Protocol and Signal messaging app originated. While unrelated to the signal processing concept of noise, the choice of “Noise” as the name for this cryptographic protocol might be a play on the signal vs. noise concept.
Originally maintained as a wiki starting from February 10, 2013, the framework's development began with an initial commit to its specification on August 4, 2014. The framework evolved through numerous revisions following mailing list discussions until version 34 on July 11, 2018. The Noise Protocol Framework acknowledges inspiration from previous cryptographic designs and contributions from figures in cryptography and computing.
During its development, the Noise Protocol Framework evolved alongside TLS 1.3, including 2015 discussions comparing the protocols, particularly the “OPTLS” proposal. Both projects spanned from 2014 to 2018, with the first draft of TLS 1.3 RFC 8446 released in August 2014 and the final Proposed Standard in August 2018. The Noise Framework provided an alternative approach, enabling the selection of specific handshake patterns and cryptographic algorithms to design protocols tailored to specific security properties and performance needs.
Formal verifications of the Noise Protocol Framework have evaluated its security properties. Studies have employed automated tools to model and verify various handshake patterns within the framework, assessing their resilience against a range of attacks.

Overview

A secure channel protocol has two phases:
The handshake pattern can be described in a diagram as a set of messages, each annotated with a list of tokens that describe cryptographic operations performed on a party's handshake state.

Example handshake pattern having 3 messages:
IK
<- s
...
-> e, es, s, ss
<- e, ee, se
Handshake names are formulaic:
  • I = Static key for initiator Immediately transmitted to responder, despite reduced or absent identity hiding
  • K = Static key for initiator Known to responder
The line before ... represent a message prior to DH AKE such as an out-of-band transfer of a public key.

The specification lists three one-way handshake patterns, and 12 fundamental interactive handshake patterns. There are variations of some of these:
  • deferred patterns, where the authentication DHs are deferred to the next message. A numeral 1 is used after the first and/or second character, e.g. NK1 or X1X1
  • a pre-shared symmetric key to support protocols where both parties have a 32-byte shared secret key, e.g. Npsk0 or Xpsk1
  • compound protocols in which the roles of initiator and responder get reversed as a negotiation mechanism via the fallback modifier. A Noise Pipe is an example found in §10.4
A real-world example comes from WireGuard whose Construction on page 10 of the is Noise_IKpsk2_25519_ChaChaPoly_BLAKE2s.
Each handshake pattern can be combined with one of the 16 combinations of the 8 cryptographic algorithms listed in the Specification. As and do not enlarge the design space.
The Specification outlines an API in §5 using the following objects each having a small set of methods:
  • A CipherState object contains k and n variables, which it uses to encrypt and decrypt ciphertexts. During the handshake phase, each party has a single CipherState, but during the transport phase, each party has two CipherState objects: one for sending, and one for receiving.
  • A SymmetricState object contains a CipherState plus ck and h variables. It is so-named because it encapsulates all the "symmetric crypto" used by Noise. During the handshake phase, each party has a single SymmetricState, which can be deleted once the handshake is finished.
  • A HandshakeState object contains a SymmetricState plus DH variables and a variable representing the handshake pattern. During the handshake phase, each party has a single HandshakeState, which can be deleted once the handshake is finished.
The implementation of a concrete protocol involves the design of message representation, as well as aspects outside the Noise Framework. An example of the latter happens with protocols using UDP transports, such as WireGuard, which uses a sliding window to handle out-of-order arrival.
Security properties of several handshake patterns are described in the Specification and can support mutual authentication, forward secrecy, zero round-trip encryption, identity hiding, and other advanced features. Formal cryptographic analyses of common handshake patterns have appeared in the academic literature. The second effort has resulted in the online tool Noise Explorer.
Much of the following consists of excerpts from the Specification with formatting:
  • IK for protocol names consisting of handshake patterns, cryptography, and modifiers
  • ck for variables in the handshake state machine
  • e for tokens in a message pattern
  • § prefixes references to sections in the Specification
with the focus on:
  • handshake patterns
  • security properties and tradeoffs
  • application responsibilities and security considerations

    Protocol Names and Modifiers §8

To produce a Noise Protocol name for Initialize you concatenate the ASCII string Noise_ with four underscore-separated name sections, which sequentially name the handshake pattern, the DH functions, the cipher functions, and then the hash functions. The resulting name must be 255 bytes or less. Examples:
  • Noise_XX_25519_AESGCM_SHA256
  • Noise_N_25519_ChaChaPoly_BLAKE2s
  • Noise_IK_448_ChaChaPoly_BLAKE2b
Each name section must consist only of alphanumeric characters, and the two special characters "+" and "/".
Additional rules apply to each name section, as specified below.

Handshake pattern name section §8.1

A handshake pattern name section contains a handshake pattern name plus a sequence of zero or more pattern modifiers.
The handshake pattern name must be an uppercase ASCII string containing only alphabetic characters or numerals.
Pattern modifiers specify arbitrary extensions or modifications to the behavior specified by the handshake pattern. For example, a modifier could be applied to a handshake pattern, which transforms it into a different pattern according to some rule. The psk0 and fallback modifiers are examples of this and will be defined later in this document.
A pattern modifier is named with a lowercase alphanumeric ASCII string that must begin with an alphabetic character. The pattern modifier is appended to the base pattern as described below:
The first modifier added onto a base pattern is simply appended. Thus, the fallback modifier, when added to the XX pattern, produces XXfallback. Additional modifiers are separated with a plus sign. Thus, adding the psk0 modifier would result in the name section XXfallback+psk0, or a full protocol name such as Noise_XXfallback+psk0_25519_AESGCM_SHA256.
In some cases, the sequential ordering of modifiers will specify different protocols. However, if the order of some modifiers does not matter, then they are required to be sorted alphabetically.