So, the next talk will be from Trevor Perrin. He has been called, wait for it, leading evangelist in cryptographic protocol modernization.

He helped out design some of the protocols that your phone right now is executing and sending to data P over there, like signal, which awarded, which gave him the award of

the left chin prize, and the noise protocol framework, which is used by WhatsApp for client to server communication, and WireGuard, the VPN from Jason Donfield, which I don't see around here. Anyways, the talk will focus about the noise protocol framework, what is the rationale behind it and how to use it.

Please give him a hand of applause. Alright, thank you everyone for being here. My name is Trevor Perrin, I do cryptography, consulting, and secure protocol design. I'm going to be talking to you this evening about a project I've been working on for

the last few years in the field of protocol design, which is the noise protocol framework. Noise is a framework that helps you in creating cryptographic secure channel protocols. So, the sort of protocols it addresses is things like TLS or SSH or IPSec, where you

have two parties, they're online at the same time, for example, an internet client talking to an internet server, they're going to want to exchange a few messages to authenticate each other and then establish some shared secret keys, which they can use for further communication.

Secure channel protocols like this are the workhorses of practical cryptography. Most of the time when crypto is used, it's within the context of some sort of secure channel protocol. There's other sorts of protocols like secure messaging and cryptocurrency and all sorts of other things, but noise is specifically focused on secure channels. So that's what I'm going to be talking about in this talk.

And you know, probably a lot of people just kind of off the bat have a reaction to that of being like, well, why? We have secure channel protocols already, we have TLS, we have SSH, we have IPSec, these things have been a huge amount of effort to design over the last 20 plus years. We've been bolting features onto them and picking bugs out of them.

Why would we want to start down that road again and build different and newer protocols? And I think that's a very legitimate question and source of skepticism. And my, you know, my feelings about this is as follows. It's that what a secure channel protocol does is really a very simple thing.

It just sends a couple of messages, two or three, maybe four, sets up a secure channel. So these protocols really should be pretty simple. They should be simple to implement. They should be simple to design. And I think a lot of the ones that we find ourselves with, the mainstream ones, for what they do, for what they actually accomplish, I think they're probably, you

know, often too complex, too complicated and too difficult to extend. And I think we need to extend them. We're going to need to keep adding features and extending them into new areas. And with new types of cryptography. So it's important to have good frameworks and good ways of doing this. I think this is an area where we need a lot of room for improvement. And so noise is a somewhat, I guess, ambitious effort in that direction.

It's ambitious in the sense that I love to get it to a point where people could use noise for building all sorts of new and future protocols. I'll be the first to admit that it's a work in progress. It hasn't achieved all of its ambitions yet. It's achieved some of them. But, you know, we're still working to extend it.

And if, you know, if by the end of this talk, I haven't convinced people in the next 20 minutes to try to use noise for all your protocol design challenges, that's going to be OK. What I mainly want to get across is just something about how these protocols work, the components that go into them, the design space they're a part of, because I think

these protocols are so central to computer security, it's helpful for everyone to understand how they work and what they do and not just think of them as, you know, kind of black magic that only a few wizards can ever touch. So to understand these sorts of protocols, secure channel protocols, I'm going to want to start by giving you some background on the type of cryptography

that's involved in them. And the main cryptographic construct in any secure channel protocol is going to be what cryptographers call an authenticated key exchange or AKE protocol. And an AKE is just a sequence of messages that go back and forth between two parties, between Alice and Bob, so they can authenticate each other and then at the end of that have a shared secret key that they know they share with their authenticated party.

These protocols, these AKE protocols can have different properties. All the ones we're going to look at have forward secrecy. They might have mutual authentication of both parties. They might have one-way authentication. How they handle identity information might be different in different AKEs.

So maybe in some AKEs, both parties start off knowing each other's identity and public key. In some AKEs, they'll have to transmit this information. In other AKEs, they might want to transmit this information, but do it only after the other party has negotiated some encryption so that their identity information is encrypted, is protected on the wire.

So there's different properties of how these things work. There's different types of crypto we can use to design AKEs that have these properties. I want to expand on this a little bit because most AKEs that people have experience with, the mainstream ones, all do their AKE in kind of the same way. They do an AKE using signatures for authentication and Diffie-Hellman for a key agreement.

But in the last, let's say, 10 or so, 10 plus years, there's been growing interest in doing AKEs that are just purely based on Diffie-Hellman key agreement without signatures. There's been a bunch of papers that analyze security models and do proofs for this sort of AKE.

People have put this into practice in things like TORs and TOR key agreement by Ian Goldberg and a number of designs by Dan Bernstein and others like Salt, Cryptoboxes, Curve CP, etc. So there's been interest in doing this and Noyz is particularly going to try to take this idea and run with it.

So I want to explain a little bit more about how these sorts of Diffie-Hellman centric AKEs work. And so we'll start by looking at just the key exchange part of an AKE. And this part is going to be sort of generic to all the protocols, all the AKE protocols we talk about, which is just going to be an unauthenticated Diffie-Hellman key exchange.

The way you think about Diffie-Hellman is that there's Alice and Bob. They each have a key pair, a private key and a public key. They're each going to exchange their public key with the others. Then they're going to take their public key, they're going to take their private key, they're going to combine these two and get a shared secret, which is the same for both parties.

So that's just a basic Diffie-Hellman to add to key agreement to turn it into an authenticated key exchange. We're going to add authentication and so we can do that by adding signatures in a very conventional way. Let's say both parties know each other's public keys so Bob just has to send an encrypted signature to Alice.

Alice responds with an encrypted signature. Now we have an AKE and this design is called Sigma. It's essentially Sigma and it's essentially how something like TLS 1.3 works, where you first get a secret key then send signatures as authenticators under the encryption. And there's nothing wrong with this design, it's a good design.

We can kind of look at that schematically by imagining that what's kind of happening if we don't consider the message sequence is Alice and Bob are each kind of signing the key agreement so that once they get a shared key, they know that the other party agrees with the shared key by verifying the signature. If we want to do an AKE that's entirely signature-based,

we're going to have to replace these signatures with some sort of Diffie-Hellman while still getting that same confidence and that same guarantee that the other party agrees on the ultimate final shared secret key we get out of this AKE. So the way we can do that is we can say, well, these long-lived key pairs that people have, we'll call them static key pairs,

are going to be Diffie-Hellman key pairs instead of signature key pairs and each party is going to, in addition to doing an ephemeral to ephemeral DH for forward secrecy, do an ephemeral DH to the other party's static key for authentication and then hash all these DHs together to get a final key. And the reason why this convinces each party that the other party has agreed to the final key

is because this final key is a hash that includes the DH of the authentication DH of their ephemeral key, the other party's static private key. The only other party who knows the output of that DH is the other party. Thus, if we do anything with the final shared secret key,

like receive any encrypted message from it, we know that key can only have been calculated by the correct counterparty. So we're accomplishing authentication by using DH instead of signatures here. And so this is a well-understood thing, but I wanted to just touch on that before we dive into the history of noise.

And the history of noise is that a few years ago I was reading a lot of these papers that talked about Diffie-Hellman based key exchange and looking at a number of these designs where people were doing Diffie-Hellman based key exchange and I thought these were cool designs. I thought they were elegant, I thought they were efficient. But every time someone did a new Diffie-Hellman based thing,

like Ntor, or Salt, or Curve CP, or OpTLS, they would sort of start from scratch. And they'd say, okay, how are we going to do key derivation? How are we going to do transcript hashing? How are we going to do key confirmation? If they were doing security analysis, they'd create their own security model, they'd write their own gap DH ROM based security proof.

It's pretty much the same as everyone else's security proof, but it's still a lot of work. So there was a lot of reused or sort of repeated work being done to build this style of protocol. And so kind of the motivating idea for Noyz was whether we could capture that work into a framework that just provided you some common elements so people could easily combine those elements together

and create a wide range of different protocols in this style. And so I started working on ways of, you know, kind of connecting protocol pieces together. Eventually I talked to Mike Hamburg, who was working on something else, his strobe protocol framework that was kind of based on sponge based cryptography. And we kind of took some ideas from that.

And with all those ideas, we were able to come up with, I think, a pretty good system for describing a wide range of protocols just by taking a Diffie-Hellman operation and some simple other cryptography and combining them in a bunch of different ways. And so that core design of Noyz is what we sort of arrived at by 2015, and it's been stable since then.

So Noyz is still a work in progress because we're trying to extend it and add new forms of cryptography and build more things kind of around this core, but we do have a pretty good core at this point. We built a small community around it with a mailing list, websites, specifications, test suites. We have open source libraries in a bunch of common languages.

And we also have a couple users. Noyz based protocols are used by WhatsApp for client to server communication from the app to the server. And the WhatsApp and WireGuard, which is a next generation VPN tunnel project by Jason Donenfeld, also uses a Noyz based secure channel protocol. And we're getting interest from some other directions,

from people doing internet of things embedded systems, anonymity network type systems, the lightning network proposal for Bitcoin incorporates a Noyz based protocol. So I think we're getting interest from people who potentially want a customized secure channel protocol

for a new area they're working in but don't want to drag in a lot of extraneous complexity. They want something simple and efficient that addresses their use case. And that's what I think, that's kind of the sweet spot for Noyz so far. So for the rest of this talk, what I want to do is talk about what the components of a secure channel protocol are,

why I think it's a good idea to have a framework that kind of addresses the design of these things and then fill in the details on what the Noyz framework actually is. Secure channel protocols all have kind of the same structure. They start with a handshake phase where parties send a few messages back and forth to get a shared secret key. Then they use the shared secret key

for like a transport phase of just doing bulk encryption. And the transport phase is a simple thing. It's pretty easy to just use shared keys to encrypt data back and forth. So I'm not gonna say a lot more about it. The handshake phase is kind of where all the excitement and the interesting things here are. So of course the main component of a secure protocol,

a secure channel's handshake is gonna be just an authenticated key exchange, an AKE of some sort. But a lot of secure channel protocols will also have some sort of negotiation that happens logically before the rest of this

that determines the type of AKE and the parameters of the AKE and the parameters of the encryption, such as which cipher to use. And you can think of this negotiation happening logically before everything else because it determines everything else but in practice for efficiency, the negotiation and the AKE are usually kind of overlaid or woven together a little bit.

So I might send an initial message from the client that says I'm speculatively executing this AKE protocol but I'm willing to execute these other protocols and I'm willing to use these ciphers for the transport phase. Then the server can respond by saying I want you to do a different AKE. I want you to use these ciphers at the end of it. And so you have these negotiation and AKE things

happening kind of simultaneously which is one of the reasons these protocols are a little complicated to think about. But anyways, if we were building a single secure channel protocol, we would be trying to fill in these elements. We'd be saying okay, what AKEs do we wanna use? How do we wanna instantiate the cryptography within them?

And then how do we wanna design a negotiation structure that can select one of these different things and how do we assemble all that together? So we're not trying to build a single AKE protocol. We're trying to build a framework for building AKE protocols. So we're doing something a little bit more confusing

and the reason why is a pretty simple reason which is that if you're trying to build a single protocol, you have a hard decision and a difficult trade off to manage between adding features into this protocol and keeping it simple. Because the more features you add, the more negotiation you have,

the more different branches your protocol can take, the more complexity every implementer has to deal with, the more attack service you have because if there's any bug in any of these features that an attacker can navigate to, that's potentially a problem. So we wanna work on things that have a lot of features that address a lot of cases but we also wanna keep things simple

and so if we think of ourselves as creating not just a single protocol but a framework of protocols, we can kind of manage that tension a little bit better by imagining that we have all these features and all these capabilities kind of off to the side in like a library or a toolbox somewhere and when we build a concrete protocol, we're just gonna select a bunch of features and hopefully have some simple combination rules

for putting them together and to get a very customized protocol that does exactly what we want and not anything that we don't want. That means that working with noise is different from working with something like TLS because with a lot of, probably most cryptographic protocols, you can just take a TLS library,

point it at another TLS library and they'll figure out how to connect. They'll do negotiations and fallbacks and retries and whatever but they'll find the intersection of Cypher suites and versions and so on that they support and will connect to each other and that's a feat of engineering but there's a lot of complexity that lies behind that and there's a lot of opacity

and just kind of understanding what you're really getting. Noise on the other hand, to use it you have to kind of think in advance about what you wanna use, what AKs you wanna use, what cryptography you're gonna get. You're gonna choose all these things. You're gonna have to understand why you want the sequence of messages. You're gonna put them together and you're gonna end up with something that very much addresses your use case hopefully

but is not gonna have a lot of extraneous complexity. So that's a different way of working with protocols and thinking about protocols but I think it's the right answer for a lot of cases. And at least that's our goal. That's what we wanna build is a framework where we can choose a bunch of things, combine them together

and then end up with a wide range of different protocols but to get there is a little bit complicated. To get there we're gonna have to take our structure of a secure channel protocol and break it up into some different elements so that we can mix and match these elements and get different protocols. And we're gonna break it up in a couple different ways.

And the first way we're gonna do that is we're gonna separate out all the points in the protocol where runtime decisions are made from all the points of the protocol we can think of as just straight line linear code. And the reason why is because if we have straight line, just linear cryptographic code

that just does one thing after another and sends one message after another and does nothing else except maybe erroring if it detects a cryptographic authentication failure. If we have code like that it's very easy to test, it's easy to think about, it's easy to design things around because it just does one thing in a sequence. And so noise is very much gonna be

about forcing people to use straight line code with no branches as much as possible. Our idea of being a framework hopefully helps with that because we've moved a lot of decisions that might have been runtime decisions, negotiation decisions in a full protocol, we're moving them to hopefully design time decisions

within a framework. But we might still have some negotiation decisions remaining about which cipher to use or if we try to do a zero round trip encryption we might have to fall back to something else. So there might be some decisions that remain, we're gonna try to compress all those decisions into kind of one and say there's only one point in this framework where runtime decisions get made

which is selecting what we're gonna call a noise protocol and this notion of a noise protocol is gonna encapsulate everything else that happens it's just a linear sequence of code and it's gonna be the AKE plus whatever transport encryption happens after that. So with this framework we've hopefully, we hate decision making at runtime

but we're gonna compress it down to one if we have to and then call everything else just a straight line sequence of code. The next thing we're gonna do to make this framework sort of manageable and break it down is zoom in on this notion of a noise protocol and break that into pieces too. And so we're gonna view that as a combination of what we call a handshake pattern with some actual crypto algorithms.

And a handshake pattern is gonna be like an abstract notion of an AKE. So it's gonna be an AKE protocol that just says do some sort of Diffie-Hellman, encrypt this in some way, hash this in some way but it's not gonna tell you what crypto to use. You're gonna plug in crypto and it's that combination of things is gonna give you a concrete noise protocol

which is in kind of an implementable unit of this framework. So the whole framework then kind of ends up being like this we, the sort of core central piece is this notion of a noise protocol which is what we've probably spent most of our engineering effort on where we combine some abstract notion of an AKE, a handshake pattern with some crypto

to get a noise protocol. We're gonna imagine a negotiation layer that can really just make one decision which is does the server want to switch from the initial noise protocol to a different one. So we're only gonna allow one transition just to make things really simple. And then the only other layer we're gonna add is this notion of an encoding layer which is that we might want to send our messages over TCP

in which case we'd have to add length fields or we might send them over HTTP in which case we'll have to encode them as HTTP requests. So we have this kind of abstract notion of our protocol but we might need to add a little bit more encoding to actually fit it into a particular context. And that's gonna be kind of just the whole way we build secure channel protocols.

So the main thing that you're going to interact with is, or the kind of central piece of this is the noise protocol. And the main way that you're going to interact with noise protocols and design them as a user is by just giving them names. And so we have this notion of you can precisely name

a noise protocol and then that just kind of like defines the entire protocol. So here we have a noise protocol that's, this is a concrete implementable thing. It uses the NX pattern which, I haven't explained what that means, but it also combines that pattern, that AKE notion with curve 25519 for Diffie-Hellman,

with AES GCM for encryption, with SHA-256 for hashing. We can plug in or out different options of any one of these things. So we could have different patterns, different ciphers, et cetera, to get a noise protocol and then the specification and most of our noise libraries can take this name

and we'll just automatically know what to do. They'll synthesize a whole protocol around this just with some pretty simple rules. And so the pattern notion and the way we're naming patterns, there is a naming convention here, but I think more important than understanding the naming convention is understanding the simple language that it's built on top of.

And so we're gonna have a simple language for describing a range of abstract AKE patterns based on this set of concepts, based on just saying we have Alice and Bob, they each might have a static key and they might have an ephemeral key, and the only things we're gonna allow them to do

as part of their AKE protocol is send their public keys back and forth and do Diffie-Hellman operations. And the only Diffie-Hellman operations they can do are these four involving some combination of their keys, which you can just read from left to right. So they can do the static static Diffie-Hellman, they can do the Alice's static to Bob's ephemeral,

which sort of authenticates Alice, they can do Alice's ephemeral to Bob's static, which authenticates Bob, or they can do this EE Diffie-Hellman for forward secrecy. So we're gonna allow them just to combine these units in different ways and get a wide range of different AKEs out of this. So let's start demonstrating, I'm gonna demonstrate a bunch of patterns and kind of go through them quickly,

and let's start with something that's very simple, which is just a public key encryption. So this AKE pattern doesn't even describe an interactive protocol, it's just Alice encrypting a message to Bob, and so our little language here, we're gonna add three dots to indicate when Alice has prior knowledge of something before the protocol starts. So this is a protocol where Alice knows

Bob's public key at the outset. She's gonna send one message, which is an ephemeral public key she chooses. She's gonna do an ES, ephemeral static Diffie-Hellman, to authenticate Bob, and that's gonna give her public key encryption, because then she's gonna have keys that she can use for sort of a transport phase encryption of the message she's sending to Bob. So that's just, you could think of this

as like an ECIES or an ephemeral static public key encryption. We can make this more complicated by saying both parties know their public keys, and we want Alice to authenticate to Bob, and now we just throw in the static static encryption, and now we have Alice authenticating herself to Bob. We could make another step in complexity and say, we want Alice to authenticate herself to Bob

and also send her public key to Bob, and she might also have to send certificates and things like that to convince Bob her public key is to be trusted. That can go in the transport payload, but the point is now we've taken Alice's public key and say instead of it being prior knowledge of Bob's, it's transported in the message itself, and we're gonna have this additional rule,

which is that any time we send a static public key, we're gonna encrypt it with all the other keys that have come before. So in this case, Alice's static public key is encrypted with the output of the ephemeral static DH, which provides some identity hiding. So someone looking at the wire doesn't know who Alice's is, even though Bob knows.

We can move on to interactive protocols and look at an unauthenticated Diffie-Hellman, just looks like this, an exchange of ephemeral public keys and a Diffie-Hellman. You could add server authentication to that, where the server just sends its static public key and does a Diffie-Hellman. You could imagine that the server's public key

is known in advance by the client, and in this case, we don't have to, so in this case, we had to transport it. In this case, we're not transporting it from the server. But if we're in this case, we can use something even better, which is kind of a nice property of this style of protocol is we can move that ephemeral static DH from the second message to the first

and say Alice can actually do zero round trip encryption to Bob or to the server's public key. So she does, the first message there is essentially what I earlier called a public key encryption. She's just encrypting straightaway to Bob in her first message, and that's something we can do with a Diffie-Hellman based AKE that you can't do with, say, a signature based AKE

because if Bob's static key was the signing key, you would not be able to encrypt to it. So that's kind of an example of some nice features we get from this style of AKE. We could continue making things more complicated. So we could add not just zero round trip encryption, zero round trip authentication in this first flow

by having Alice send her identity and doing an additional Diffie-Hellman. We can, and if we're doing that, we should probably also refresh the authentication in this second message with this ES so that Bob's authentication of Alice is based on a fresh ephemeral instead of a long-term static key

which could potentially be compromised. And if we do all this, we get actually, this is very close to WireGuard's pattern. WireGuard adds an additional feature that is a pre-shared symmetric key, and that's something that we designed working with the WireGuard designer, Jason Donenfeld,

that just allows you to add an extra key that gets mixed into everything. The idea being that in a VPN context, if two parties want to share a secret key, then your security will depend on either that or all these Diffie-Hellmans. And so even if someone's able to break Diffie-Hellman through cryptanalysis or a quantum computer, if you've shared a secret key through some other means,

they would not be able to go back and break your traffic. So that's kind of just an example of how we can take this language that is a fairly simple language, extend it with new features, and we're interested in continuing that process and adding new features onto this. So things that are in the mix

is trying to figure out how to add post-quantum-resistant algorithms to provide hybrid forward secrecy onto these protocols, even going back and adding the notions of signatures into this. Because just like all this machinery we have is good for Diffie-Hellman-based protocols, probably we can take all these notions of patterns and of noise protocols and our approach to negotiation

and apply them even to more conventional AKEs and to other things as well. So that's sort of our framework. It ends up looking kind of like this with a very simple negotiation layer, switching to this very linear notion of a fixed-noise protocol that you can assemble together by taking an abstract notion of patterns and combining it with cryptography of your choice.

We're still working on a lot of extensions for this. I'd love to get more people who wanted to experiment with it or use it for anything. You can find more on our website, which has links to our mailing list as well. I'm happy to talk about it with anyone. There's gonna be a WireGuard meetup tomorrow at three o'clock,

and I'll probably be milling around there as well. But if you wanna talk to Jason and other WireGuard people and see how all this works in a concrete context, that would be a good way to learn more about it. Thank you for listening, and do I have time for questions? Maybe a brief amount of time.

Microphone one, test, test, okay. So in the context of multi-party systems,

if you have a person that has either multiple devices or multiple keys, is there anything that you could use inside noise to work with that so that you have messages being sent to both identities? Or would you recommend doing something like that

over a central registry and then linking the keys and having it sent to one and share the devices sharing with each other? Yeah, that's a good question. I mean, I think that really gets into the scope of what secure messaging protocols try to address is when you have notions of groups and you wanna be consistent with the group and you want to talk to everyone in the group and maybe everyone in the group isn't online at the same time.

And I would say that's a different and more complex class of protocols that we're kind of just not trying to handle here. I think with noise, hopefully we're looking at something that's a very simple and well-understood design space so we can build a lot of machinery around it because it's so simple. And these other cases you're talking about, I think just add a lot of complexity about how you would wanna do all those things. So we've kind of just chosen a narrow scope

to make our disk-specific problem a lot easier, I would say. Okay, thanks. Go. Hey, does noise include any of the ratcheting or sort of key evolution over time properties that we've seen in protocols like this in the past? No, so noise has a pretty simple model of just you have like a handshake phase

and a transport phase and the transport phase just uses a key. Now we have added a notion of being able to update this key by just replacing it with some of its own output, essentially. So we can kind of roll it forward in a very simple way and we have an efficient way of doing that. So you could do things like have every one of your messages update the key to the next key and then you have within the protocol forward secrecy.

We don't do try to like more complicated things with Diffie-Hellman ratchets or anything like that. Go. The last one. One would be, what's the simple sales pitch for like use noise over TLS? You know, probably the simplest sales pitch would be like if you want, really, really want your protocol

to just do like one thing and you don't wanna drag around a lot of code that does like a lot of things. You know, like noise will let you produce a very fine-tuned protocol that's a very small amount of code that just does like one thing pretty easily. That's it. Thanks a lot. Thank you.