<- s ... -> e, es, s, ss <- e, ee, se Handshake names are formulaic: The line(s) before ... represent a message prior to DH AKE such as an out-of-band transfer of a public key.
The Specification outlines an API in §5[4] using the following objects each having a small set of methods: 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 .
[7] Much of the following consists of excerpts from the Specification with formatting: with the focus on: The framework was developed by Trevor Perrin with support from Moxie Marlinspike based on work done at Open Whisper Systems.
Most secure channel protocols use an AKE based on signatures (for authentication) and Diffie-Hellman (for key exchange).
Elegant, but each protocol starts from scratch The initial commit for the Specification was on Aug 4, 2014[16] and underwent many changes following discussion on the mailing list until rev34 on Jul 11, 2018.
A pattern modifier is named with a lowercase alphanumeric ASCII string which must begin with an alphabetic character (not a numeral).
However, if the order of some modifiers does not matter, then they are required to be sorted alphabetically (this is an arbitrary convention to ensure interoperability).
If both parties do not provide identical prologue data, the handshake will fail due to a decryption error.
Of course, the identities of Noise participants might be exposed through other means, including payload fields, traffic analysis, or metadata such as IP addresses.
The properties for the relevant public key are: The fundamental handshake patterns in the previous section perform DH operations for authentication (es and se) as early as possible.
For example:[41] Alice might have chosen a Noise Protocol based on a cipher, DH function, or handshake pattern which Bob doesn't support.
Alice might have sent a "zero-RTT" encrypted initial message based on an out-of-date version of Bob's static public key or PSK.
Noise Pipes support the XX pattern, but also allow Alice to cache Bob's static public key and attempt an IK handshake with 0-RTT encryption.
XXfallback: Note that fallback can only be applied to handshake patterns in Alice-initiated form where Alice's first message is capable of being interpreted as a pre-message (i.e. it must be either e, s, or "e, s").
XXfallback: The XX pattern is used for a full handshake if the parties haven't communicated before, after which Alice can cache Bob's static public key.
The XXfallback pattern is used for a switch handshake if Bob fails to decrypt an initial IK message (perhaps due to having changed his static key).
Email from Trevor Perrin on 4-Mar-2018[44] I've created a draft spec for an "NLS" framework that adds a negotiation language ("NoiseLingo") on top of NoiseSocket (hence "NoiseLingoSocket").
[45] This needs a tweaked NoiseSocket draft, with modifications from 2[46] (renaming a couple things, and changing the prologue calculation to differentiate the "retry" case, and to add an application prologue): The NLS draft also defines some "basic profiles", which are intended as high-level protocols usable by application developers: The idea is that NoiseLingo and NLS give you a menu of negotiation fields that are easy to choose from to create profiles.
Also, these profiles will have a lot of similarity and thus potential for interop (e.g. a NoiseZeroLink client can talk to a NoiseLink server, by falling back to 1-RTT).
And if you start with something simple like NoiseLink, it's easy to add new NLS fields and negotiation options as you discover new needs.