The Noise Protocol Framework

Noise is a framework for crypto protocols based on Diffie-Hellman key agreement. Noise can describe protocols that consist of a single message as well as interactive protocols.
A Noise protocol begins with two parties exchanging handshake messages. During this handshake phase the parties exchange DH public keys and perform a sequence of DH operations, hashing the DH results into a shared secret key. After the handshake phase each party can use this shared key to send encrypted transport messages.
The Noise framework supports handshakes where each party has a long-term static key pair and/or an ephemeral key pair. A Noise handshake is described by a simple language. This language consists of tokens which are arranged into message patterns. Message patterns are arranged into handshake patterns.
A message pattern is a sequence of tokens that specifies the DH public keys that comprise a handshake message, and the DH operations that are performed when sending or receiving that message. A handshake pattern specifies the sequential exchange of messages that comprise a handshake.
A handshake pattern can be instantiated by DH functions, cipher functions, and hash functions to give a concrete Noise protocol.
The core of Noise is a set of variables maintained by each party during a handshake, and rules for sending and receiving handshake messages by sequentially processing the tokens from a message pattern.
Each party maintains the following variables:
s, e: The local party's static and ephemeral key pairs (which may be empty).
rs, re: The remote party's static and ephemeral public keys (which may be empty).
h: A handshake hash value that hashes all the handshake data that's been sent and received.
ck: A chaining key that hashes all previous DH outputs. Once the handshake completes, the chaining key will be used to derive the encryption keys for transport messages.
k, n: An encryption key k (which may be empty) and a counter-based nonce n. Whenever a new DH output causes a new ck to be calculated, a new k is also calculated. The key k and nonce n are used to encrypt static public keys and handshake payloads. Encryption with k uses some AEAD cipher mode (in the sense of Rogaway [1]) and uses the current h value as associated data which is covered by the AEAD authentication. Encryption of static public keys and payloads provides some confidentiality and key confirmation during the handshake phase.
A handshake message consists of some DH public keys followed by a payload. The payload may contain certificates or other data chosen by the application. To send a handshake message, the sender specifies the payload and sequentially processes each token from a message pattern. The possible tokens are:
"e": The sender generates a new ephemeral key pair and stores it in the e variable, writes the ephemeral public key as cleartext into the message buffer, and hashes the public key along with the old h to derive a new h.
"s": The sender writes its static public key from the s variable into the message buffer, encrypting it if k is non-empty, and hashes the output along with the old h to derive a new h.
"ee", "se", "es", "ss": A DH is performed between the initiator's key pair (whether static or ephemeral is determined by the first letter) and the responder's key pair (whether static or ephemeral is determined by the second letter). The result is hashed along with the old ck to derive a new ck and k, and n is set to zero.
After processing the final token in a handshake message, the sender then writes the payload into the message buffer, encrypting it if k is non-empty, and hashes the output along with the old h to derive a new h.
As a simple example, an unauthenticated DH handshake is described by the handshake pattern:
The initiator sends the first message, which is simply an ephemeral public key. The responder sends back its own ephemeral public key. Then a DH is performed and the output is hashed into a shared secret key.
Note that a cleartext payload is sent in the first message, after the cleartext ephemeral public key, and an encrypted payload is sent in the response message, after the cleartext ephemeral public key. The application may send whatever payloads it wants.
The responder can send its static public key (under encryption) and authenticate itself via a slightly different pattern:
In this case, the final ck and k values are a hash of both DH results. Since the es token indicates a DH between the initiator's ephemeral key and the responder's static key, successful decryption by the initiator of the second message's payload serves to authenticate the responder to the initiator.
Note that the second message's payload may contain a zero-length plaintext, but the payload ciphertext will still contain authentication data (such as an authentication tag or "synthetic IV"), since encryption is with an AEAD mode. The second message's payload can also be used to deliver certificates for the responder's static public key.
The initiator can send its static public key (under encryption), and authenticate itself, using a handshake pattern with one additional message:
The following sections flesh out the details, and add some complications. However, the core of Noise is this simple system of variables, tokens, and processing rules, which allow concise expression of a range of protocols.
All Noise messages are less than or equal to 65535 bytes in length. Restricting message size has several advantages:
Simpler testing, since it's easy to test the maximum sizes.
Reduces the likelihood of errors in memory handling, or integer overflow.
Enables support for streaming decryption and random-access decryption of large data streams.
Enables higher-level protocols that encapsulate Noise messages to use an efficient standard length field of 16 bits.
All Noise messages can be processed without parsing, since there are no type or length fields. Of course, Noise messages might be encapsulated within a higher-level protocol that