 So, the next talk will be from Trevor Perrin. He has been called, wait for it, Living Evangelist in Cryptographic Protocol Modernization. He helped out design some of the protocols that your phone right now is executing and sending to that API over there, like Signal, which awarded, which gave him the award of the Levchin Prize, and the Noise Protocol Framework, which is used by WhatsApp for client-to-server communication, and WireGuard, the VPN from Jason Dunfield, which I don't see around here. Anyways, the talk will focus about the Noise Protocol Framework, what is the rationality 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, you know, 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 like 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 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 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 complicated and too difficult to extend. And I think we need to extend them. We're going to need to keep, you know, 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, you know, somewhat, I guess, ambitious effort in that direction. And it's ambitious in the sense that I, you know, 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, you know, 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, to extend it. And if, you know, by the end of this talk, I haven't convinced people in the next 20 minutes to try to use noise for all your, your protocol design challenges, that's going to be okay. 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, 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, can ever touch. So to understand these sorts of protocols, secure channel protocols, I'm going to want to start by giving just 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 exchange or a.k.a. protocol. And an a.k.a. 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 a.k.a. 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 a.k.a.s. So maybe in some a.k.a.s, both parties start off knowing each other's identity and public key in some a.k.a.s. They'll have to transmit this information in other a.k.a.s. 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 a.k.a.s. That have these properties. And I want to expand on this a little bit because most a.k.a.s. That people have experience with, the mainstream loans all do their a.k.a.s. In kind of the same way. They do a.k.a. using signatures for authentication and Diffie-Hellman for a key agreement. But in the last, you know, let's say 10 or so, 10 plus years, there's been growing interest in doing a.k.a.s that are just purely based on Diffie-Hellman key agreement without signatures. And, you know, there's been a bunch of papers that kind of analyze security models and do proofs for this sort of a.k.a.e. People have put this into practice and things like TORs and TOR key agreement by Ian Goldberg and a number of designs by Dan Bernstein and others, like Salt Crypto Boxes, Curve CP, et cetera. So there's been kind of interest in doing this and noises particularly kind of 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 a.k.a.s work. And so we'll start by looking at just the key exchange part of an a.k.a.e. And this is part is going to be sort of generic to all the protocols, all the a.k.a.e. 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 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. 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 a.k.a.e. 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 a.k.a.e. 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 a.k.a.e. 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, they're 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 Ford's 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, you know, it's a well understood thing, but I wanted to kind of just touch on that before we talk about, or kind of dive into the history of noise. And the history of noise is that, you know, a few years ago I was reading, you know, 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 Entor, or Salt, or CurveCP, or OptiLS, 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, you know, GapDH 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 noise 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 noise is what we sort of arrived at by 2015, and it's been stable since then. So we've, you know, noise 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 and a bunch of common languages. And we also have a couple of users. Noise-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 noise-based secure channel protocol. And we're getting interest from some other directions from people doing like Internet of Things embedded systems, anonymity network type systems, the Lightning Network proposal for Bitcoin incorporates a noise-based protocol. So I think we're getting interest from people who potentially want, you know, like kind of a customized secure channel protocol for a new area they're working in, but don't want to drag in a lot of like extraneous complexity. They want something simple and efficient that addresses their use case. And that's what I think it's kind of the sweet spot for noise so far. So for the rest of this talk, what I want to do is, you know, 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 noise 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 the 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 going to say a lot more about it. The handshake phase is kind of where all the, you know, the excitement and the interesting things here are. So of course the main component of a secure protocol, a secure channel's handshake is going to 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 before, sort of 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 cypher 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. And 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 want to use? How do we want to instantiate the cryptography within them? And then how do we want to 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 want to work on things that have a lot of features, that address a lot of cases, but we also want to keep things simple. 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 going to 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, you know, 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 pointed at another TLS library and they'll figure out how to connect. They'll do, you know, negotiations and fallbacks and retries and whatever, but they'll find the intersection of cipher 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 want to use, what AKs you want to use, what cryptography you're going to get. You're going to choose all these things. You're going to have to understand why you want this sequence of messages. You're going to put them together and you're going to end up with something that very much addresses your use case hopefully but is not going to 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 want to build as 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 going to 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 going to break it up in a couple of different ways. The first way we're going to do that is we're going to 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 that's noise is very much going to 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 the full protocol, we're moving them to hopefully design time decisions within a framework. But we might still have some negotiation decisions remaining about like which cypher to use or like 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 going to 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 going to call a noise protocol. And this notion of a noise protocol is going to encapsulate everything else that happens. It's just a linear sequence of code. And it's going to be the aka plus whatever transport encryption happens after that. So with this framework we hopefully you know we hate decision making at runtime but we're going to 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 going to 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. So we're going to view that as a combination of what we call a handshake pattern with some actual crypto algorithms. And a handshake pattern is going to be like an abstract notion of an aka. So it's going to be an aka protocol that just says do some sort of Diffie Hellman, encrypt this in some way, hash this in some way but it's not going to tell you what crypto to use. You're going to plug in crypto and it's that combination of things is going to 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. The sort of core central piece is this notion of the noise protocol which is what we've probably spent most of our engineering effort on where we combine some abstract notion of an aka, a handshake pattern with some crypto to get a noise protocol. We're going to 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 going to allow one transition just to make things really simple. And then the only other layer we're going to 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 you know that's going to 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 you know 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 a.k.a. E notion with Curve 25519 for Diffie Hellman with AESGCM for encryption with SHA256 for hashing we can plug in or out different options of any one of these things. So we could have different patterns, different ciphers, etc. 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 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 that it's built on top of and so we're going to have a sort of simple language for describing a range of sort of abstract a.k.a. patterns based on 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 going to allow them to do as part of their a.k.a. protocol is send their public keys back and forth and do Diffie Hellman operations and the only Diffie Hellman operations they can do are you know 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, you 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 going to allow them just to combine these units in different ways and get a wide range of different a.k.a.s out of this. So let's start demonstrating, I'm going to 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 a.k.a. 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 going to 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 going to send one message which is an ephemeral public key she chooses, she's going to do an ES, ephemeral static Diffie Hellman to authenticate Bob and that's going to give her public key encryption because then she's going to 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 can think of this as like an ECIS 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, you know we've taken Alice's public key and say instead of it being prior knowledge of Bob's it's transported in the in the message itself and we're going to have this additional rule which is that anytime we do a diffie, we send the static public key we're going to 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 is even though Bob knows. We can move on to to interactive protocols and look at an unauthenticated diffie helmet just looks like this in exchange of ephemeral public keys and a diffie helmet. You could add server authentication to that where the server just sends its static public key and does does a diffie helmet. 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 the style of protocols 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 straight away to Bob in her first message and that's something we can do with a diffie helmet based aka that you can't do with say a signature based aka 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 aka. 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 helmet. We can and if we're doing that we should probably also refresh the authentication in the second message with this yes so that it's the 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 into 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 helmets and so even if someone's able to break diffie helmet through crypt analysis 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 you know things that are there in the mix is trying to figure out how to add you know 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 helmet-based protocols probably we can take all these notions of patterns and of noise protocols and how 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. You know it ends up looking kind of like this with some you know a very simple negotiation layer switching to this very linear notion of a fixed noise protocol that you can assemble together by taking abstract notion of patterns and combining it with cryptography of your choice. You know 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 going to be a wire guard meetup tomorrow at three o'clock and I'll probably be milling around there as well but if you want to talk to Jason and other wire guard people and see how all this works in a concrete context that would be you know 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 like multi-party systems if you have like 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 like messages being sent to both identities or would you recommend some doing something like that over like a central registry and then linking the keys and having it sent to one and shared the devices sharing with each other? Yeah, that's a good question. I mean I think that really gets into the scope of what like secure messaging protocols try to address is when you have notions of groups and you want to 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 want to do all those things. So it's we've kind of just chosen a narrow scope to make our this 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 like update this key by just replacing it with like, you know, 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. When would be when's the simple sales pitch for like use noise over TLS? Mmm, 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 want to drag around a lot of code that does like a lot of things. You know, like noise will let you produce a very fine tune protocol that's a very small amount of code that just does like one thing pretty easily. That's it. Thanks a lot. Cool. Thank you.