Noise Protocol Framework
The Noise Protocol Framework serves as open source - Framework for encryption protocols for end-to-end encrypted data exchange , based on the Diffie-Hellman key exchange (DH). Using the framework, secure alternatives to the well-known TLS have already been created, which guarantee the integrity and authenticity of the transmitted messages by using a method called Authenticated Encryption with Additional Data (AEAD) .
origin
The framework was developed by Trevor Perrin with the support of Moxie Marlinspike and is already used in the well-known instant messenger WhatsApp , the Lightning network for scaling possible Bitcoin transactions and the VPN tunnel system WireGuard . Furthermore, there are currently initial drafts for the planned noise socket , which is to serve as a TLS socket for a noise protocol built on the framework.
functionality
As with TLS, the protocol begins with the handshake phase, through which the two public keys of the parties are exchanged. The two party's keys can be volatile and / or static. As a result, by performing a series of DH operations, a common secret key is calculated, with the help of which a symmetrical encryption method can be used and the messages are secured by a Message Authentication Code (MAC) to protect the authenticity . With the Noise Protocol Framework, you can choose between different handshaker patterns, DH functions, hash functions and encryption functions, through which a specific noise protocol is obtained.
Handshake
The core of the noise protocol is the respective set of variables of the parties at the time of the handshake and the rules of the selected handshake pattern according to which the individual handshake messages are processed, sent and received. Each party has the following variables:
- s, e: The local, static and / or volatile key pair, which can also be empty.
- rs, re: The static and / or volatile key pair of the remote party, which can also be empty.
- h: A handshake hash value that hashes all handshake data that is sent or received.
- ck: The chaining key that hashes all previous DH outputs. As soon as the handshake is completed, the chaining key is used to derive the encryption key.
- k, n: The encryption key k, which can also be empty, and a count-based nonce n, are used to encrypt the static public keys and the handshake payloads with the help of AEAD, which h uses as AD. Whenever a new ck is calculated by the DH output, a new k is also calculated.
A handshake message always consists of a DH public key followed by a freely selected payload, depending on the application. The sender compiles the respective message step by step from tokens, depending on the message pattern. Possible tokens are:
- "e": The sender generates a new volatile key pair and writes the public key as plain text in the message buffer and hashes the public key together with the old h to derive a new h.
- "s": The sender writes his static public key of s in the message buffer, encrypts it with k if k has already been generated and hashes the public key together with the old h to derive a new h.
- "ee", "se", "es", "ss": A Diffie-Hellman is carried out between the key pair of the initiator and the responder, the result is hashed with the old chaining key ck to create a new ck and a new one h and finally n is set to zero.
After the last token of a handshake message has been processed, the sender writes the payload in the message buffer, encrypts the message if an encryption key k has already been generated and hashes the output with the old h to derive a new h.
Examples
Handshake pattern of a handshake without authentication:
-> e <- e, ee
- The initiator sends the first message with his volatile public key.
- The responder sends back its own volatile public key.
- Finally, a DH is performed and the output is hashed to a secret key.
Handshake pattern of a handshake with authentication of the responder:
-> e <- e, ee, s, es
In this case the final ck and k values are a hash of both DH results. As the token shows that a DH was carried out between the volatile key pair of the initiator and the static key pair of the responder. If the initiator can decrypt the payload of the second message, the responder was successfully authenticated.
Handshake pattern of a handshake with authentication of the initiator:
-> e <- e, ee, s, es -> s, se
This is done in the same way as authenticating the responder.
There is still a large number of possible patterns from which to choose, which are always selected depending on the area of application.
properties
The noise protocol framework is compatible with various encryption and hash methods.
The following encryption methods are supported:
- Advanced Encryption Standard (AES) in Galois / Counter Mode (GCM)
- ChaCha20 -Poly1305
The following hash procedures are supported:
The following Diffie-Hellman functions are supported: