preroll music Herald: So, the next talk would 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 AP over there. Like signal, 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 Donenfeld, which I don't see around here... Anyways, the talk will focus on the Noise Protocol Framework. What is the rationale behind it and how to use it. Please hand of applause. applause Trevor: All right, 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. The sort of protocols it addresses is things like TLS or SSH or IPSec, where you have 2 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 some shared secret keys, which they can use for further communication. Secure channel protocols like this are the the workhorses of practical cryptography; most 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 probably a lot of people, just kind of off the bat, have a reaction to that of being like "Well, why? We we have secure channel protocols already: We have TLS; we have SSH; we have IPSec; and these things have been a huge amount of effort to design over the last 20+ 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 -- 2 or 3, maybe 4 -- 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 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; its achieved some of them. But we're still working to extend it and if, by the end of this talk, I have then convinced people in the next 20 minutes to try to use Noise for all your new 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 essential to computer security, it's helpful for everyone to understand, how they work and what they do, and not just think of them as 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 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 Key Exchange" or "AKE protocol" . And an AKE is just a sequence of messages that go back and forth between 2 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 handled 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 and some AKEs will 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 are different properties of how these things work; there are different types of crypto we can use to design AKEs that have these properties. And 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 a AKE using signatures for authenticaton and Diffie-Hellman for a key agreement. But in the last... that's a 10 or so... 10+ years, there has been a growing interest in doing AKEs that are just purely based on Diffie-Hellman key agreement without signatures, and there has 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 Tor and Tor key agreement by Ian Goldberg and a number of designs by Daniel Bernstein and others, like SALT cryptoboxes, CurveCP, etc. So, there has been a kind of interest in doing this and Noise is particularly trying 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 is part is going to be sort of generic to all the protocols, all the AKE protocols, we talked about, which is just going to be an unauthenticated dDffie- 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, you 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 look at that schematically by imagining that what's happening if we don't consider the message sequences: Alice and Bob are each signing the key agreement, so that once they get a shared key, they know that the other party agrees with this 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 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, do 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... it's a well understood thing, but I wanted to kind of just touch on that before we talk about... where I 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, 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 CurveCP 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 that'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, the 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 kind of connecting protocol pieces together. Eventually, I talked to Mike Hamburg who's working on something else -- this Strobe Protocol Framework that was kind of based on sponge-based cryptography -- and we kind of took some ideas from that. With 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. That core design of noise is what we arrived at by 2015 and it's been stable since then. We 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 around this core but we do have a pretty good core at this point. We've built a small community around it with a mailing list, website, specifications, test suites, open source libraries in a bunch of common languages and we also have a couple users: Noise Based Protocol is used by WhatsApp for client-to-server communication from the app to the server and WireGuard which is a next generation VPN tunnel project by Jason Donenfeld, it also uses a a noise based secure channel protocol. We're also getting interest from some some other directions, from people doing like Internet of Things, embedded systems, anonymity network type systems, the Lightning Network proposal for Bitcoin which will incorporate a Noise 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. That's what I think is the sweet spot for Noise so far. 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 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 this shared secret key for the transport phase of just doing bulk encryption. 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 where all the excitement and the interesting things are. Of course, the main component of a secure protocol, a secure channel, is the handshake. It's 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 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. You can think of this negotiation happening logically before everything else because it determines everything else, but in practice, for efficiency, the negotiation of the AKE are usually 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". So you have these negotiation in AKE 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 would be saying, okay, what AKE 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. We're not trying to build a 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 is pretty simple. 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 negotiations 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. 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 off to the side, and a library or a tool 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 exactly what we want and not anything that we we don't want. That means that working with Noise is different from working with something like TLS because with most cryptographic protocols, you probably can just take a TLS library, point it at another TLS library, and they'll figure out how to connect. They'll do negotiations, fall backs, retries, ... and they'll find the intersection of cipher suites and versions, etc. that they support, and will connect to each other. That's a feat of engineering, but there's a lot of complexity that lies behind that, and there's a lot of opacity in understanding what you're really getting. To use Noise, on the other hand, you have to think in advance about what you want to use, what AKEs you want to use, what cryptography you're gonna get... You're going to choose all these things. You're going to have to understand why you want the 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. At least that's our goal. 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 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. We're gonna break it up in a couple different ways. The first way we're going to 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, it's 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, say, it detects cryptographic authentication failure. 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 decision 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, like, which cipher to use or, you know 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 the Noise… And this notion of the Noise protocol is going to encapsulate everything else that happens. It's just a linear sequence of code, it's going to be the AKE plus whatever transport encryption happens after that. So with this framework we've 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 the Noise protocol and break that into pieces too. And 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 AKE, so it's going to 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 going to tell you what crypto to use. You're going to 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: 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 AKE, 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 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, 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 AKE notion with Curve25519 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, etc. to get a Noise protocol and then the specification, and most of our Noise libraries can take this name and will 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 this simple language that it's built on top of. And, so we're gonna have a sort of simple language for describing a range of sort of abstract AKE 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 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, you know, these four involving some combination of their keys which you can just read from left to right, so they can do this 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 AKEs out of this. So let's start demonstrate... 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 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 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 the transport phase encryption of the message she's sending to Bob. So that's just--you could think of this as in like an ECIES or an ephemeral static public key encryption. We could 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 going to have this additional rule which is that any time we send the 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 unauthenticated Diffie-Hellman, just looks like this: an exchange of the 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'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 protocol. 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 the 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-Hellman-based AKE that you can't do with say a signature-based AKE, because if Bob's static key is the signing key you would not be able to encrypt to it. So, you know, 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. And if we're doing that we should probably also refresh the authentication in the 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, you know, 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 the 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 is 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, 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-Hellman 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 into 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 an 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 gonna be a WireGuard meet up tomorrow at 3 o'clock and I'll probably be milling around there as well, but if you want to talk to Jason and other WireGuard 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. applause Herald-Angel: Microphone one. Question: 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 the devices sharing with each other? Answer: 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 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 we've kind of just chosen a narrow scope to make this specific problem a lot easier, I would say. Q: Okay, thanks! Q: 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? A: 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 try to do like more complicated things with Diffie-Hellman ratchets or anything like that, Q: When would be--what's the simple sales pitch for why to use Noise over TLS? A: You know, probably the simplest sales pitch would be like, if you 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-tuned protocol that's a very small amount of code that just does like one thing pretty easily. Herald: That's it, thanks a lot Perrin: Thank you. applause postroll music subtitles created by c3subtitles.de in the year 2018. Join, and help us!