1 00:00:00,000 --> 00:00:15,534 preroll music 2 00:00:15,534 --> 00:00:22,540 Herald: So, the next talk would be from Trevor Perrin. He has been called -- wait 3 00:00:22,540 --> 00:00:29,431 for it -- "Living Evangelist in cryptographic protocol modernization"; he 4 00:00:29,431 --> 00:00:34,809 helped out design some of the protocols that your phone right now is executing and 5 00:00:34,809 --> 00:00:42,719 sending to that AP over there. Like signal, which gave him the award of the 6 00:00:42,719 --> 00:00:46,449 Levchin Prize and the Noise Protocol Framework, which is used by WhatsApp for 7 00:00:46,449 --> 00:00:51,109 client-to-server communication and WireGuard, the VPN from Jason Donenfeld, 8 00:00:51,109 --> 00:00:56,231 which I don't see around here... Anyways, the talk will focus on the Noise Protocol 9 00:00:56,231 --> 00:01:02,010 Framework. What is the rationale behind it and how to use it. Please hand of 10 00:01:02,010 --> 00:01:09,250 applause. applause 11 00:01:09,252 --> 00:01:13,540 Trevor: All right, thank you everyone for being here. My name is Trevor Perrin; I do 12 00:01:13,540 --> 00:01:18,850 cryptography, consulting and secure protocol design. I'm going to be talking 13 00:01:18,850 --> 00:01:25,880 to you this evening about a project I've been working on for the last few years in 14 00:01:25,880 --> 00:01:32,979 the field of protocol design, which is the Noise Protocol Framework. Noise is a 15 00:01:32,979 --> 00:01:39,960 framework that helps you in creating cryptographic secure channel protocols. 16 00:01:39,960 --> 00:01:45,710 The sort of protocols it addresses is things like TLS or SSH or IPSec, where you 17 00:01:45,710 --> 00:01:49,249 have 2 parties -- they're online at the same time, for example an internet client 18 00:01:49,249 --> 00:01:53,189 talking to an internet server -- they're going to want to exchange a few messages 19 00:01:53,189 --> 00:01:57,569 to authenticate each other and then establish some some shared secret keys, 20 00:01:57,569 --> 00:02:01,899 which they can use for further communication. Secure channel protocols 21 00:02:01,899 --> 00:02:05,920 like this are the the workhorses of practical cryptography; most the time when 22 00:02:05,920 --> 00:02:11,530 crypto is used, it's within the context of some sort of secure channel protocol. 23 00:02:11,530 --> 00:02:14,810 There's other sorts of protocols, like secure messaging and cryptocurrency and 24 00:02:14,810 --> 00:02:19,070 all sorts of other things, but Noise is specifically focused on secure channels, 25 00:02:19,070 --> 00:02:25,050 so that's what I'm going to be talking about in this talk. And probably a lot of 26 00:02:25,050 --> 00:02:28,580 people, just kind of off the bat, have a reaction to that of being like "Well, why? 27 00:02:28,580 --> 00:02:33,270 We we have secure channel protocols already: We have TLS; we have SSH; we have 28 00:02:33,270 --> 00:02:38,020 IPSec; and these things have been a huge amount of effort to design over the last 29 00:02:38,020 --> 00:02:42,270 20+ years. We've been bolting features onto them and picking bugs out of them. 30 00:02:42,270 --> 00:02:46,850 Why would we want to start down that road again and build different and newer 31 00:02:46,850 --> 00:02:51,430 protocols?" And I think, that's a very legitimate question and source of 32 00:02:51,430 --> 00:02:58,650 skepticism. And my feelings about this is as follows: It's that, what a secure 33 00:02:58,650 --> 00:03:02,590 channel protocol does is really a very simple thing; it just sends a couple 34 00:03:02,590 --> 00:03:08,210 messages -- 2 or 3, maybe 4 -- sets up a secure channel. So, these protocols really 35 00:03:08,210 --> 00:03:11,900 should be pretty simple; they should be simple to implement; they should be simple 36 00:03:11,900 --> 00:03:14,430 to design; and I think, a lot of the ones that we find ourselves with -- the 37 00:03:14,430 --> 00:03:18,900 mainstream ones -- for what they do, for what they actually accomplish, I think, 38 00:03:18,900 --> 00:03:24,820 they're probably often too complex, too complicated and too difficult to extend. 39 00:03:24,820 --> 00:03:29,870 And I think, we need to extend them; we're going to need to keep adding features and 40 00:03:29,870 --> 00:03:33,070 extending them into new areas and with new types of cryptography. So, it's important 41 00:03:33,070 --> 00:03:36,510 to have good frameworks and good ways of doing this. I think, this is an area where 42 00:03:36,510 --> 00:03:42,300 we need a lot of room for improvement. And so, Noise is a somewhat, I guess, 43 00:03:42,300 --> 00:03:46,270 ambitious effort in that direction. It's ambitious in the sense that I love to get 44 00:03:46,270 --> 00:03:51,180 it to a point where people could use Noise for building all sorts of new and future 45 00:03:51,180 --> 00:03:55,620 protocols. I'll be the first to admit that it's a work in progress; it hasn't 46 00:03:55,620 --> 00:03:59,520 achieved all of its ambitions yet; its achieved some of them. But we're still 47 00:03:59,520 --> 00:04:05,441 working to extend it and if, by the end of this talk, I have then convinced people in 48 00:04:05,441 --> 00:04:09,920 the next 20 minutes to try to use Noise for all your new protocol design... 49 00:04:09,920 --> 00:04:14,740 Challenges, that's going to be okay. What I mainly want to get across is, just 50 00:04:14,740 --> 00:04:18,089 something about how these protocols work, the components that go into them, the 51 00:04:18,089 --> 00:04:21,709 design space they're a part of, because I think, these protocols are so essential to 52 00:04:21,709 --> 00:04:26,780 computer security, it's helpful for everyone to understand, how they work and 53 00:04:26,780 --> 00:04:31,180 what they do, and not just think of them as kind of black magic that only a few 54 00:04:31,180 --> 00:04:37,290 wizards can ever touch. So, to understand these sorts of protocols, secure channel 55 00:04:37,290 --> 00:04:41,010 protocols, I'm going to want to start by giving just some background on the type of 56 00:04:41,010 --> 00:04:46,190 cryptography that's involved in them: And the main cryptographic construct in any 57 00:04:46,190 --> 00:04:49,680 secure channel protocol is going to be what cryptographers call an "Authenticated 58 00:04:49,680 --> 00:04:54,680 Key Exchange" or "AKE protocol" . And an AKE is just a sequence of messages that go 59 00:04:54,680 --> 00:04:58,690 back and forth between 2 parties, between Alice and Bob, so they can authenticate 60 00:04:58,690 --> 00:05:02,210 each other and then, at the end of that, have a shared secret key that they know 61 00:05:02,210 --> 00:05:08,040 they share with their authenticated party. These protocols, these AKE protocols, can 62 00:05:08,040 --> 00:05:11,300 have different properties: All the ones we're going to look at have forward 63 00:05:11,300 --> 00:05:15,010 secrecy; they might have mutual authentication of both parties; they might 64 00:05:15,010 --> 00:05:19,560 have one-way authentication; how they handled identity information might be 65 00:05:19,560 --> 00:05:24,540 different in different AKEs, so maybe in some AKEs, both parties start off knowing 66 00:05:24,540 --> 00:05:28,720 each other's identity and public key and some AKEs will have to transmit this 67 00:05:28,720 --> 00:05:33,600 information. In other AKEs, they might want to transmit this information, but do 68 00:05:33,600 --> 00:05:38,410 it only after the other party has negotiated some encryption, so that their 69 00:05:38,410 --> 00:05:43,139 identity information is encrypted, is protected on the wire. So, there are 70 00:05:43,139 --> 00:05:46,010 different properties of how these things work; there are different types of crypto 71 00:05:46,010 --> 00:05:51,540 we can use to design AKEs that have these properties. And I want to expand on this a 72 00:05:51,540 --> 00:05:57,100 little bit, because most AKEs that people have experience with, the mainstream ones, 73 00:05:57,100 --> 00:06:03,020 all do their AKE in kind of the same way: They do a AKE using signatures for 74 00:06:03,020 --> 00:06:08,389 authenticaton and Diffie-Hellman for a key agreement. But in the last... that's a 10 75 00:06:08,389 --> 00:06:12,020 or so... 10+ years, there has been a growing interest in doing AKEs that are 76 00:06:12,020 --> 00:06:17,020 just purely based on Diffie-Hellman key agreement without signatures, and there 77 00:06:17,020 --> 00:06:22,060 has been a bunch of papers that analyze security models and do proofs for this 78 00:06:22,060 --> 00:06:27,100 sort of AKE. People have put this into practice in things like Tor and Tor key 79 00:06:27,100 --> 00:06:32,570 agreement by Ian Goldberg and a number of designs by Daniel Bernstein and others, 80 00:06:32,570 --> 00:06:37,850 like SALT cryptoboxes, CurveCP, etc. So, there has been a kind of interest in doing 81 00:06:37,850 --> 00:06:42,420 this and Noise is particularly trying to take this idea and run with it. So, I want 82 00:06:42,420 --> 00:06:47,850 to explain a little bit more about how these sorts of Diffie-Hellman-centric AKEs 83 00:06:47,850 --> 00:06:53,250 work. And so, we'll start by looking at just the key exchange part of an AKE and 84 00:06:53,250 --> 00:06:56,760 this is part is going to be sort of generic to all the protocols, all the AKE 85 00:06:56,760 --> 00:07:01,199 protocols, we talked about, which is just going to be an unauthenticated dDffie- 86 00:07:01,199 --> 00:07:05,750 Hellman key exchange. The way you think about Diffie-Hellman is that there's Alice 87 00:07:05,750 --> 00:07:09,290 and Bob: They each have a key pair, a private key and a public key; they're each 88 00:07:09,290 --> 00:07:12,610 going to exchange their public key with the others; then they're going to take 89 00:07:12,610 --> 00:07:15,380 their public key, they're going to take their private key; they're going to 90 00:07:15,380 --> 00:07:20,800 combine these two and get a shared secret, which is the same for both parties. So, 91 00:07:20,800 --> 00:07:25,240 that's just a basic Diffie-Hellman to add... to key agreement, to turn it into 92 00:07:25,240 --> 00:07:30,560 an authenticated key exchange, you exchange, we're going to add 93 00:07:30,560 --> 00:07:34,590 authentication. And so, we can do that by adding signatures in a very conventional 94 00:07:34,590 --> 00:07:38,990 way: Let's say both parties know each other's public keys, so Bob just has to 95 00:07:38,990 --> 00:07:41,990 send an encrypted signature to Alice; Alice responds with an encrypted 96 00:07:41,990 --> 00:07:47,770 signature; now we have an AKE. And this design is called Sigma, it's essentially 97 00:07:47,770 --> 00:07:51,980 Sigma, and it's essentially how something like TLS 1.3 works, where you first get a 98 00:07:51,980 --> 00:07:57,870 secret key, then send signatures as authenticators under the encryption. And 99 00:07:57,870 --> 00:08:02,150 there's nothing wrong with this design, it's a good design. We can look at that 100 00:08:02,150 --> 00:08:06,590 schematically by imagining that what's happening if we don't consider the message 101 00:08:06,590 --> 00:08:10,650 sequences: Alice and Bob are each signing the key agreement, so that once they get a 102 00:08:10,650 --> 00:08:14,960 shared key, they know that the other party agrees with this shared key by verifying 103 00:08:14,960 --> 00:08:20,470 the signature. If we want to do an AKE that's entirely signature-based, we're 104 00:08:20,470 --> 00:08:23,880 going to have to replace these signatures with some sort of Diffie-Hellman, while 105 00:08:23,880 --> 00:08:28,451 still getting that same confidence and that same guarantee, that the other party 106 00:08:28,451 --> 00:08:35,330 agrees on the ultimate, final, shared secret key we get out of this AKE. So, the 107 00:08:35,330 --> 00:08:39,708 way we can do that is, we can say "Well, these these long-lived key pairs that 108 00:08:39,708 --> 00:08:42,429 people have, we'll call them static key pairs; they're going to be Diffie-Hellman 109 00:08:42,429 --> 00:08:48,290 key pairs instead of signature key pairs; and each party is going, to in addition to 110 00:08:48,290 --> 00:08:52,569 doing an ephemeral, do ephemeral DH for forward secrecy, do an ephemeral DH to the 111 00:08:52,569 --> 00:08:56,110 other party's static key for authentication, and then hash all these 112 00:08:56,110 --> 00:09:02,269 DHs together to get a final key. And the reason why this convinces each party that 113 00:09:02,269 --> 00:09:07,339 the other party has agreed to the final key is, because this final key is a hash 114 00:09:07,339 --> 00:09:12,899 that includes the DH of the authentication DH of their ephemeral key, the other 115 00:09:12,899 --> 00:09:16,120 party's static private key -- the only other party who knows the output of that 116 00:09:16,120 --> 00:09:21,790 DH is the other party -- thus, if we do anything with the final shared secret key, 117 00:09:21,790 --> 00:09:25,269 like receive any encrypted message from it, we know that key can only have been 118 00:09:25,269 --> 00:09:31,589 calculated by the correct counterparty. So, we're accomplishing authentication by 119 00:09:31,589 --> 00:09:37,390 using DH instead of signatures here and so this is a... it's a well understood thing, 120 00:09:37,390 --> 00:09:41,040 but I wanted to kind of just touch on that before we talk about... where I dive into 121 00:09:41,040 --> 00:09:44,230 the history of Noise. And the history of Noise is that a few years ago, I was 122 00:09:44,230 --> 00:09:48,920 reading a lot of these papers that talked, Diffie-Hellman-based key exchange, and 123 00:09:48,920 --> 00:09:53,350 looking at a number of these designs where people were doing Diffie-Hellman-based key 124 00:09:53,350 --> 00:09:56,720 exchange and I thought, these were cool designs. I thought, they were elegant; I 125 00:09:56,720 --> 00:10:01,519 thought they were efficient. But every time someone did a new Diffie-Hellman- 126 00:10:01,519 --> 00:10:06,790 based thing, like nTor or salt or CurveCP or OPTLS, they would sort of start from 127 00:10:06,790 --> 00:10:10,889 scratch and they'd say "Okay, how are we going to do key derivation? How are we 128 00:10:10,889 --> 00:10:14,209 going to do transcript hashing? How are we going to do key confirmation?" If they 129 00:10:14,209 --> 00:10:17,420 were doing security analysis, they'd create their own security model; they'd 130 00:10:17,420 --> 00:10:21,579 write their own Gap DH ROM-based security proof that's pretty much the same 131 00:10:21,579 --> 00:10:24,699 as everyone else's security proof, but it's still a lot of work. So, there was a 132 00:10:24,699 --> 00:10:30,040 lot of reused or sort of repeated work being done to build this style of protocol 133 00:10:30,040 --> 00:10:35,399 and so, the the motivating idea for Noise was, whether we could capture that work 134 00:10:35,399 --> 00:10:38,410 into a framework that just provided you some common elements so people could 135 00:10:38,410 --> 00:10:42,670 easily combine those elements together and create a wide range of different protocols 136 00:10:42,670 --> 00:10:47,470 in this style. And so, I started working on ways of kind of connecting protocol 137 00:10:47,470 --> 00:10:53,230 pieces together. Eventually, I talked to Mike Hamburg who's working on something 138 00:10:53,230 --> 00:10:56,779 else -- this Strobe Protocol Framework that was kind of based on sponge-based 139 00:10:56,779 --> 00:11:02,510 cryptography -- and we kind of took some ideas from that. With with all those ideas 140 00:11:02,510 --> 00:11:05,910 we were able to come up with I think a pretty good system for describing a wide 141 00:11:05,910 --> 00:11:09,459 range of protocols just by taking a Diffie-Hellman operation and some simple 142 00:11:09,459 --> 00:11:15,519 other cryptography and combining them in a bunch of different ways. That core design 143 00:11:15,519 --> 00:11:22,509 of noise is what we arrived at by 2015 and it's been stable since then. We know noise 144 00:11:22,509 --> 00:11:25,450 is still a work in progress because we're trying to extend it and add new forms of 145 00:11:25,450 --> 00:11:30,740 cryptography and build more things around this core but we do have a pretty good 146 00:11:30,740 --> 00:11:34,910 core at this point. We've built a small community around it with a mailing list, 147 00:11:34,910 --> 00:11:39,750 website, specifications, test suites, open source libraries in a bunch of common 148 00:11:39,750 --> 00:11:45,149 languages and we also have a couple users: Noise Based Protocol is used by WhatsApp 149 00:11:45,149 --> 00:11:51,269 for client-to-server communication from the app to the server and WireGuard which 150 00:11:51,269 --> 00:11:56,790 is a next generation VPN tunnel project by Jason Donenfeld, it also uses a a noise 151 00:11:56,790 --> 00:12:01,379 based secure channel protocol. We're also getting interest from some some other 152 00:12:01,379 --> 00:12:05,429 directions, from people doing like Internet of Things, embedded systems, 153 00:12:05,429 --> 00:12:11,129 anonymity network type systems, the Lightning Network proposal for Bitcoin 154 00:12:11,129 --> 00:12:16,100 which will incorporate a Noise Based Protocol. So I think we're getting 155 00:12:16,100 --> 00:12:21,199 interest from people who potentially want a customized secure channel protocol for a 156 00:12:21,199 --> 00:12:25,480 new area they're working in but don't want to drag in a lot of extraneous complexity. 157 00:12:25,480 --> 00:12:29,670 They want something simple and efficient that addresses their use case. That's what 158 00:12:29,670 --> 00:12:34,830 I think is the sweet spot for Noise so far. For the rest of this talk, what I 159 00:12:34,830 --> 00:12:40,550 want to do is talk about what the components of a secure channel protocol 160 00:12:40,550 --> 00:12:44,989 are, why I think it's a good idea to have a framework that addresses the design of 161 00:12:44,989 --> 00:12:50,209 these things, and then fill in the details on what the Noise framework actually is. 162 00:12:50,209 --> 00:12:54,439 Secure channel protocols all have kind of the same structure: they start with a 163 00:12:54,439 --> 00:12:58,029 handshake phase where parties send a few messages back and forth to get a shared 164 00:12:58,029 --> 00:13:03,040 secret key, then they use this shared secret key for the transport phase of just 165 00:13:03,040 --> 00:13:08,429 doing bulk encryption. The transport phase is a simple thing, it's pretty easy to 166 00:13:08,429 --> 00:13:13,369 just use shared keys to encrypt data back and forth, so I'm not going to say a lot 167 00:13:13,369 --> 00:13:18,420 more about it. The handshake phase is where all the excitement and the 168 00:13:18,420 --> 00:13:25,700 interesting things are. Of course, the main component of a secure protocol, a 169 00:13:25,700 --> 00:13:28,230 secure channel, is the handshake. It's going to be just an authenticated key 170 00:13:28,230 --> 00:13:33,759 exchange, an AKE of some sort, but a lot of secure channel protocols will also have 171 00:13:33,759 --> 00:13:40,679 some sort of negotiation that happens logically before the rest of this that 172 00:13:40,679 --> 00:13:44,860 determines the type of AKE, and the parameters of the AKE, and the parameters 173 00:13:44,860 --> 00:13:49,759 of the encryption such as which cipher to use. You can think of this negotiation 174 00:13:49,759 --> 00:13:53,670 happening logically before everything else because it determines everything else, but 175 00:13:53,670 --> 00:13:58,480 in practice, for efficiency, the negotiation of the AKE are usually 176 00:13:58,480 --> 00:14:03,239 overlaid or woven together a little bit. So I might send an initial message from 177 00:14:03,239 --> 00:14:08,009 the client that says "I'm speculatively executing this AKE protocol but I'm 178 00:14:08,009 --> 00:14:11,439 willing to execute these other protocols and I'm willing to use these ciphers for 179 00:14:11,439 --> 00:14:15,180 the transport phase", and then the server can respond by saying "I want you to do a 180 00:14:15,180 --> 00:14:19,519 different AKE, I want you to use these ciphers at the end of it". So you have 181 00:14:19,519 --> 00:14:23,730 these negotiation in AKE happening kind of simultaneously, which is one of the 182 00:14:23,730 --> 00:14:28,879 reasons these protocols are a little complicated to think about. But anyways, 183 00:14:28,879 --> 00:14:33,800 if we were building a single secure channel protocol, we would be trying to 184 00:14:33,800 --> 00:14:37,630 fill in these elements. We would be saying, okay, what AKE do we want to use, 185 00:14:37,630 --> 00:14:40,930 how do we want to instantiate the cryptography within them, and then how do 186 00:14:40,930 --> 00:14:46,119 we want to design a negotiation structure that can select one of these different 187 00:14:46,119 --> 00:14:52,399 things, and how do we assemble all that together. We're not trying to build a a 188 00:14:52,399 --> 00:14:57,300 single AKE protocol, we're trying to build a framework for building AKE protocols, so 189 00:14:57,300 --> 00:15:04,949 we're doing something a little bit more confusing and the reason is pretty simple. 190 00:15:04,949 --> 00:15:11,480 If you're trying to build a single protocol, you have a hard decision, and a 191 00:15:11,480 --> 00:15:15,869 difficult trade-off to manage between adding features into this protocol and 192 00:15:15,869 --> 00:15:19,769 keeping it simple. Because the more features you add, the more negotiations 193 00:15:19,769 --> 00:15:25,230 you have, the more different branches your protocol can take, the more complexity 194 00:15:25,230 --> 00:15:29,179 every implementer has to deal with, the more attack service you have, because if 195 00:15:29,179 --> 00:15:33,119 there's any bug in any of these features that an attacker can navigate to, that's 196 00:15:33,119 --> 00:15:38,670 potentially a problem. We want to work on things that have a lot of features that 197 00:15:38,670 --> 00:15:42,790 address a lot of cases, but we also want to keep things simple. So if we think of 198 00:15:42,790 --> 00:15:46,850 ourselves as creating not just a single protocol, but a framework of protocols, we 199 00:15:46,850 --> 00:15:50,670 can kind of manage that tension a little bit better by imagining that we have all 200 00:15:50,670 --> 00:15:55,269 these features and all these capabilities off to the side, and a library or a tool 201 00:15:55,269 --> 00:15:58,329 somewhere. And when we build a concrete protocol, we're just going to select a 202 00:15:58,329 --> 00:16:01,879 bunch of features and hopefully have some simple combination rules for putting them 203 00:16:01,879 --> 00:16:07,369 together and to get a very customized protocol that does exactly what we want 204 00:16:07,369 --> 00:16:12,759 and not anything that we we don't want. That means that working with Noise is 205 00:16:12,759 --> 00:16:18,889 different from working with something like TLS because with most cryptographic 206 00:16:18,889 --> 00:16:22,589 protocols, you probably can just take a TLS library, point it at another TLS 207 00:16:22,589 --> 00:16:26,470 library, and they'll figure out how to connect. They'll do negotiations, fall 208 00:16:26,470 --> 00:16:31,059 backs, retries, ... and they'll find the intersection of cipher suites and 209 00:16:31,059 --> 00:16:35,809 versions, etc. that they support, and will connect to each other. That's a feat of 210 00:16:35,809 --> 00:16:39,069 engineering, but there's a lot of complexity that lies behind that, and 211 00:16:39,069 --> 00:16:44,690 there's a lot of opacity in understanding what you're really getting. To use Noise, 212 00:16:44,690 --> 00:16:49,230 on the other hand, you have to think in advance about what you want to use, what 213 00:16:49,230 --> 00:16:51,879 AKEs you want to use, what cryptography you're gonna get... You're going to choose 214 00:16:51,879 --> 00:16:55,480 all these things. You're going to have to understand why you want the sequence of 215 00:16:55,480 --> 00:16:58,160 messages, you're going to put them together, and you're going to end up with 216 00:16:58,160 --> 00:17:03,410 something that very much addresses your use case, hopefully, but is not going to 217 00:17:03,410 --> 00:17:07,459 have a lot of extraneous complexity. So that's a different way of working with 218 00:17:07,459 --> 00:17:11,730 protocols and thinking about protocols, but I think it's the right answer for a 219 00:17:11,730 --> 00:17:16,670 lot of cases. At least that's our goal. We want to build as a framework where we can 220 00:17:16,670 --> 00:17:25,079 choose a bunch of things, combine them together, and then end up with a wide 221 00:17:25,079 --> 00:17:29,240 range of different protocols. But to get there is a little bit complicated. To get 222 00:17:29,240 --> 00:17:33,779 there, we're gonna have to take our structure of a secure channel protocol and 223 00:17:33,779 --> 00:17:37,309 break it up into some different elements so that we can mix and match these 224 00:17:37,309 --> 00:17:42,169 elements and get different protocols. We're gonna break it up in a couple 225 00:17:42,169 --> 00:17:46,240 different ways. The first way we're going to do that is we're gonna separate out all 226 00:17:46,240 --> 00:17:52,471 the points in the protocol where runtime decisions are made from all the points of 227 00:17:52,471 --> 00:17:57,040 the protocol, we can think of, it's just straight line, linear code. And the reason 228 00:17:57,040 --> 00:18:01,700 why is because, if we have straight line, just linear cryptographic code that just 229 00:18:01,700 --> 00:18:06,500 does one thing after another and sends one message after another, and does nothing 230 00:18:06,500 --> 00:18:10,960 else, except maybe erroring if it detects, say, it detects cryptographic 231 00:18:10,960 --> 00:18:14,500 authentication failure. We have code like that. It's very easy to test, it's easy to 232 00:18:14,500 --> 00:18:19,059 think about, it's easy to design things around because it just does one thing in a 233 00:18:19,059 --> 00:18:23,549 sequence. And so that's… Noise is very much going to be about forcing people to 234 00:18:23,549 --> 00:18:29,880 use straight line code with no branches as much as possible. Our idea of being a 235 00:18:29,880 --> 00:18:33,370 framework hopefully helps with that because we've moved a lot of decisions 236 00:18:33,370 --> 00:18:37,820 that might have been runtime decisions, negotiation decision in a full protocol, 237 00:18:37,820 --> 00:18:41,951 we're moving them to, hopefully, design time decisions within a framework. But we 238 00:18:41,951 --> 00:18:45,510 might still have some negotiation decisions remaining about, like, which 239 00:18:45,510 --> 00:18:51,081 cipher to use or, you know like, if we try to do a zero round-trip encryption, we 240 00:18:51,081 --> 00:18:53,840 might have to fall back to something else. So there might be some decisions that 241 00:18:53,840 --> 00:18:57,200 remain. We're going to try to compress all those decisions into kind of one, and say 242 00:18:57,200 --> 00:19:01,360 there's only one point in this framework where runtime decisions get made, which is 243 00:19:01,360 --> 00:19:05,789 selecting what we're going to call a Noise protocol. And the Noise… And this notion 244 00:19:05,789 --> 00:19:08,950 of the Noise protocol is going to encapsulate everything else that happens. 245 00:19:08,950 --> 00:19:13,169 It's just a linear sequence of code, it's going to be the AKE plus whatever 246 00:19:13,169 --> 00:19:18,100 transport encryption happens after that. So with this framework we've hopefully… 247 00:19:18,100 --> 00:19:20,809 You know, we hate decision-making at runtime but we're going to compress it 248 00:19:20,809 --> 00:19:24,120 down to one if we have to and then call everything else just a straight line 249 00:19:24,120 --> 00:19:28,220 sequence of code. The next thing we're going to do to make this framework sort of 250 00:19:28,220 --> 00:19:33,830 manageable and break it down, is zoom in on this notion of the Noise protocol and 251 00:19:33,830 --> 00:19:36,920 break that into pieces too. And so we're going to view that as a combination of, 252 00:19:36,920 --> 00:19:41,679 what we call a handshake pattern, with some actual crypto algorithms. And a 253 00:19:41,679 --> 00:19:46,299 handshake pattern is going to be like an abstract notion of an AKE, so it's going 254 00:19:46,299 --> 00:19:50,730 to be an AKE protocol that just says: do some sort of Diffie-Hellman, encrypt this 255 00:19:50,730 --> 00:19:54,470 in some way, hash this in some way, but it's not going to tell you what crypto to 256 00:19:54,470 --> 00:19:58,140 use. You're going to plug in crypto, and it's that combination of things is gonna 257 00:19:58,140 --> 00:20:03,840 give you a concrete Noise protocol, which is in kind of an implementable unit of 258 00:20:03,840 --> 00:20:09,851 this framework. So, the whole framework then kind of ends up being like this: the 259 00:20:09,851 --> 00:20:13,380 sort of core central piece is this notion of the Noise protocol which is, what we've 260 00:20:13,380 --> 00:20:17,420 probably spent most of our engineering effort on, where we combine some abstract 261 00:20:17,420 --> 00:20:22,250 notion of an AKE, a handshake pattern, with some crypto to get a Noise protocol. 262 00:20:22,250 --> 00:20:25,010 We're going to imagine a negotiation layer that can really just make one decision 263 00:20:25,010 --> 00:20:29,350 which is: does the server want to switch from the initial noise protocol to a 264 00:20:29,350 --> 00:20:31,950 different one. So we're only going to allow one transition, just to make things 265 00:20:31,950 --> 00:20:37,210 really simple. And then the only other layer we're going to add, is this notion 266 00:20:37,210 --> 00:20:41,960 of an encoding layer which is that, we might want to send our messages over TCP, 267 00:20:41,960 --> 00:20:46,070 in which case we'd have to add length fields. Or we might send them over HTTP, 268 00:20:46,070 --> 00:20:49,309 in which case we'll have to encode them as HTTP requests. So we have this kind of 269 00:20:49,309 --> 00:20:52,580 abstract notion of our protocol, but we might need to add a little bit more 270 00:20:52,580 --> 00:20:56,990 encoding to actually fit it into a particular context. And that's, you know, 271 00:20:56,990 --> 00:21:02,080 that's gonna be kind of just the whole way we build secure channel protocols. So, the 272 00:21:02,080 --> 00:21:09,660 main thing that you're going to interact with, is, or the kind of central piece of 273 00:21:09,660 --> 00:21:13,649 this is the Noise protocol and the main way that you're going to interact with 274 00:21:13,649 --> 00:21:19,170 Noise protocols and design them as a user, is by just giving them names. And so we 275 00:21:19,170 --> 00:21:22,960 have this notion of, you can precisely name a Noise protocol and then that just, 276 00:21:22,960 --> 00:21:30,190 kind of like, defines the entire protocol. So here we have a Noise protocol that's, 277 00:21:30,190 --> 00:21:35,470 you know, this is a concrete implementable thing: it uses the NX pattern which, I 278 00:21:35,470 --> 00:21:39,730 haven't explained what that means, but it also combines that pattern that AKE notion 279 00:21:39,730 --> 00:21:44,009 with Curve25519 for Diffie-Hellman, with AES-GCM for encryption, with SHA-256 for 280 00:21:44,009 --> 00:21:51,920 hashing, we can plug in or out different options of any one of these things. So we 281 00:21:51,920 --> 00:21:57,100 could have different patterns, different ciphers, etc. to get a Noise protocol and 282 00:21:57,100 --> 00:22:01,120 then the specification, and most of our Noise libraries can take this name and 283 00:22:01,120 --> 00:22:05,009 will just automatically know what to do. They'll synthesize a whole protocol around 284 00:22:05,009 --> 00:22:11,110 this, just with some some pretty simple rules. And, so the pattern notion and the 285 00:22:11,110 --> 00:22:15,850 way we're naming patterns… There is a naming convention here but I think more 286 00:22:15,850 --> 00:22:18,480 important than understanding the naming convention, is understanding this simple 287 00:22:18,480 --> 00:22:23,860 language that it's built on top of. And, so we're gonna have a sort of simple 288 00:22:23,860 --> 00:22:30,350 language for describing a range of sort of abstract AKE patterns based on, based on 289 00:22:30,350 --> 00:22:35,509 this set of concepts, based on just saying we have Alice and Bob, they each might 290 00:22:35,509 --> 00:22:39,299 have a static key and they might have an ephemeral key, and the only things we're 291 00:22:39,299 --> 00:22:43,899 gonna allow them to do, as part of their AKE protocol, is send their public keys 292 00:22:43,899 --> 00:22:47,570 back and forth and do Diffie-Hellman operations and the only Diffie-Hellman 293 00:22:47,570 --> 00:22:52,350 operations they can do are, you know, these four involving some combination of 294 00:22:52,350 --> 00:22:56,110 their keys which you can just read from left to right, so they can do this static- 295 00:22:56,110 --> 00:23:00,509 static Diffie-Hellman, they can do the Alice's static to Bob's ephemeral which 296 00:23:00,509 --> 00:23:04,570 sort of authenticates Alice, you can do Alice's ephemeral to Bob's static which 297 00:23:04,570 --> 00:23:09,679 authenticates Bob, or they can do this EE Diffie-Hellman for forward secrecy. So 298 00:23:09,679 --> 00:23:13,100 we're going to allow them just to combine these units in different ways and get a 299 00:23:13,100 --> 00:23:18,502 wide range of different AKEs out of this. So let's start demonstrate... I'm going to 300 00:23:18,502 --> 00:23:20,649 demonstrate a bunch of patterns and kind of go through them quickly, and let's 301 00:23:20,649 --> 00:23:23,710 start with something that's very simple, which is just a public key encryption. So 302 00:23:23,710 --> 00:23:27,790 this AKE pattern doesn't even describe an interactive protocol, it's just Alice 303 00:23:27,790 --> 00:23:32,930 encrypting a message to Bob. And so, our little language here, we're going to add 304 00:23:32,930 --> 00:23:38,120 three dots to indicate when Alice has prior knowledge of something before the 305 00:23:38,120 --> 00:23:42,879 protocol starts. So this is a protocol where Alice knows Bob's public key at the 306 00:23:42,879 --> 00:23:45,820 outset. She's going to send one message which is an ephemeral public key she 307 00:23:45,820 --> 00:23:49,950 chooses. She's going to do an ES, Ephemeral Static Diffie-Hellman, to 308 00:23:49,950 --> 00:23:54,289 authenticate Bob and that's going to give her public key encryption because then 309 00:23:54,289 --> 00:23:57,789 she's going to have keys that she can use for sort of the transport phase encryption 310 00:23:57,789 --> 00:24:01,789 of the message she's sending to Bob. So that's just--you could think of this as in 311 00:24:01,789 --> 00:24:06,039 like an ECIES or an ephemeral static public key encryption. We could make this 312 00:24:06,039 --> 00:24:09,779 more complicated by saying both parties know their public keys and we want Alice 313 00:24:09,779 --> 00:24:13,220 to authenticate to Bob, and now we just throw in the static-static encryption and 314 00:24:13,220 --> 00:24:17,830 now we have Alice authenticating herself to Bob. We could make another step in 315 00:24:17,830 --> 00:24:21,929 complexity and say we want Alice to authenticate herself to Bob and also send 316 00:24:21,929 --> 00:24:25,809 her public key to Bob, and she might also have to send certificates and things like 317 00:24:25,809 --> 00:24:29,649 that to convince Bob her public key is to be trusted. That can go in the transport 318 00:24:29,649 --> 00:24:34,389 payload, but the point is now we've taken Alice's public key and say instead of it 319 00:24:34,389 --> 00:24:39,750 being prior knowledge of Bob's, it's transported in the message itself, and 320 00:24:39,750 --> 00:24:45,140 we're going to have this additional rule which is that any time we send the static 321 00:24:45,140 --> 00:24:48,450 public key we're gonna encrypt it with all the other keys that have come before. So 322 00:24:48,450 --> 00:24:53,250 in this case Alice's static public key is encrypted with the output of the ephemeral 323 00:24:53,250 --> 00:24:57,070 static DH, which provides some identity hiding, so someone looking at the wire 324 00:24:57,070 --> 00:25:03,720 doesn't know who Alice's is, even though Bob knows. We can move on to interactive 325 00:25:03,720 --> 00:25:07,429 protocols and look at unauthenticated Diffie-Hellman, just looks like this: an 326 00:25:07,429 --> 00:25:12,170 exchange of the ephemeral public keys and a Diffie-Hellman. You could add server 327 00:25:12,170 --> 00:25:17,000 authentication to that, where the server just sends its static public key and does 328 00:25:17,000 --> 00:25:22,309 a Diffie-Hellman. You could imagine that the server's public key is known in 329 00:25:22,309 --> 00:25:30,990 advance by the client and in this case we're not transporting it from the server, 330 00:25:30,990 --> 00:25:34,789 but if we're in this case we can use something even better, which is kind of a 331 00:25:34,789 --> 00:25:40,170 nice property of the style of protocol. We can move that ephemeral static DH from the 332 00:25:40,170 --> 00:25:46,529 second message to the first and say Alice can actually do zero round-trip encryption 333 00:25:46,529 --> 00:25:50,500 to Bob or to the server's public key. So she does--the first message there is 334 00:25:50,500 --> 00:25:53,169 essentially what I earlier called the public key encryption. She's just 335 00:25:53,169 --> 00:25:57,049 encrypting straight away to Bob in her first message, and that's something we can 336 00:25:57,049 --> 00:26:00,809 do with a Diffie-Hellman-based AKE that you can't do with say a signature-based 337 00:26:00,809 --> 00:26:04,750 AKE, because if Bob's static key is the signing key you would not be able to 338 00:26:04,750 --> 00:26:10,700 encrypt to it. So, you know, that's kind of an example of some nice features we get 339 00:26:10,700 --> 00:26:15,809 from this style of AKE. We could continue making things more complicated. So we 340 00:26:15,809 --> 00:26:19,549 could add not just zero round-trip encryption, zero round-trip 341 00:26:19,549 --> 00:26:26,610 authentication, in this first flow by having Alice send her identity and doing 342 00:26:26,610 --> 00:26:32,360 an additional Diffie-Hellman. And if we're doing that we should probably also refresh 343 00:26:32,360 --> 00:26:38,029 the authentication in the second message with this ES so that Bob's authentication 344 00:26:38,029 --> 00:26:42,590 of Alice is based on a fresh ephemeral instead of a long-term static key which 345 00:26:42,590 --> 00:26:46,590 could potentially be compromised. And if we do all this, we get actually--this is 346 00:26:46,590 --> 00:26:51,639 very close to WireGuard's pattern. WireGuard adds an additional feature that 347 00:26:51,639 --> 00:26:58,210 is a pre-shared symmetric key, and that's something that, you know, we designed 348 00:26:58,210 --> 00:27:02,460 working with the WireGuard designer Jason Donenfeld that just allows you to add an 349 00:27:02,460 --> 00:27:09,080 extra key that gets mixed into everything. The idea being that in a VPN context the 350 00:27:09,080 --> 00:27:13,389 two parties want to share a secret key, then your security will depend on either 351 00:27:13,389 --> 00:27:17,100 that or all these Diffie-Hellmans, and so even if someone is able to break Diffie- 352 00:27:17,100 --> 00:27:23,129 Hellman through cryptanalysis or a quantum computer, if you've shared a secret key 353 00:27:23,129 --> 00:27:27,320 through some other means they would not be able to go back and break your traffic. So 354 00:27:27,320 --> 00:27:31,649 that's kind of just an example of how we can take this language that is a fairly 355 00:27:31,649 --> 00:27:35,809 simple language, extend it with new features, and we're interested in 356 00:27:35,809 --> 00:27:39,519 continuing that process and adding new features onto this. So, you know things 357 00:27:39,519 --> 00:27:42,970 that are there in the mix is trying to figure out how to add you know post 358 00:27:42,970 --> 00:27:46,559 quantum resistant algorithms to provide hybrid forward secrecy onto these 359 00:27:46,559 --> 00:27:51,821 protocols, even going back and adding the notions of signatures into this. Because 360 00:27:51,821 --> 00:27:56,350 just like all this machinery we have is good for Diffie-Hellman based protocols, 361 00:27:56,350 --> 00:27:59,940 probably we can take all these notions of patterns and of Noise protocols and how 362 00:27:59,940 --> 00:28:03,909 our approach to negotiation and apply them even to more conventional AKEs 363 00:28:03,909 --> 00:28:08,330 into other things as well. So that's sort of our framework, you know it ends up 364 00:28:08,330 --> 00:28:12,340 looking kind of like this, with some, you know, a very simple negotiation layer 365 00:28:12,340 --> 00:28:16,920 switching to this very linear notion of a fixed Noise protocol that you can assemble 366 00:28:16,920 --> 00:28:21,360 together by taking an abstract notion of patterns and combining it with 367 00:28:21,360 --> 00:28:25,450 cryptography of your choice. You know we're still working on a lot of extensions 368 00:28:25,450 --> 00:28:29,679 for this, I'd love to get more people who wanted to experiment with it or use it for 369 00:28:29,679 --> 00:28:34,070 anything. You can find more on our website which has links to our mailing list as 370 00:28:34,070 --> 00:28:38,110 well. I'm happy to talk about it with anyone. There's gonna be a WireGuard meet 371 00:28:38,110 --> 00:28:43,250 up tomorrow at 3 o'clock and I'll probably be milling around there as well, but if 372 00:28:43,250 --> 00:28:46,210 you want to talk to Jason and other WireGuard people and see how all this 373 00:28:46,210 --> 00:28:50,370 works in a concrete context, that would be you know a good way to learn more about 374 00:28:50,370 --> 00:28:55,410 it. Thank you for listening, and do I have time for questions? Maybe a brief amount 375 00:28:55,410 --> 00:29:08,399 of time. applause 376 00:29:08,399 --> 00:29:22,159 Herald-Angel: Microphone one. Question: So in the context of like multi- 377 00:29:22,159 --> 00:29:27,559 party systems, if you have like a person that has either multiple devices or 378 00:29:27,559 --> 00:29:34,830 multiple keys, is there anything that you could use inside Noise to work with that 379 00:29:34,830 --> 00:29:39,320 so that you have like messages being sent to both identities, or would you recommend 380 00:29:39,320 --> 00:29:44,360 some doing something like that over like a central registry and then linking the keys 381 00:29:44,360 --> 00:29:48,009 and having it sent to one and the devices sharing with each other? 382 00:29:48,009 --> 00:29:50,950 Answer: Yeah that's a good question, I mean I think that really gets into the 383 00:29:50,950 --> 00:29:54,029 scope of what like secure messaging protocols try to address, is when you have 384 00:29:54,029 --> 00:29:57,230 notions of groups and want to be consistent with the group and you want to 385 00:29:57,230 --> 00:29:59,809 talk to everyone in the group and maybe everyone in the group isn't online at the 386 00:29:59,809 --> 00:30:03,539 same time, and I would say that's a different and more complex class of 387 00:30:03,539 --> 00:30:07,230 protocols that we're kind of just not trying to handle here. I think with Noise 388 00:30:07,230 --> 00:30:09,929 hopefully we're looking at something that's a very simple and well understood 389 00:30:09,929 --> 00:30:13,350 design space so we can build a lot of machinery around it, because it's so 390 00:30:13,350 --> 00:30:16,269 simple, and these other cases you're talking about I think just add a lot of 391 00:30:16,269 --> 00:30:20,090 complexity about how you would want to do all those things. So we've kind of just 392 00:30:20,090 --> 00:30:25,799 chosen a narrow scope to make this specific problem a lot easier, I would 393 00:30:25,799 --> 00:30:29,330 say. Q: Okay, thanks! 394 00:30:29,330 --> 00:30:33,190 Q: Does Noise include any of the ratcheting or sort of key evolution over 395 00:30:33,190 --> 00:30:36,320 time properties that we've seen in protocols like this in the past? 396 00:30:36,320 --> 00:30:40,799 A: No, so Noise has a pretty simple model of just you have like a handshake phase 397 00:30:40,799 --> 00:30:44,350 and a transport phase and the transport phase just uses a key. Now we have added a 398 00:30:44,350 --> 00:30:49,280 notion of being able to like update this key by just replacing it with, like, you 399 00:30:49,280 --> 00:30:52,559 know, some of its own output, essentially. So we can kind of roll it forward in a 400 00:30:52,559 --> 00:30:56,190 very simple way and we have an efficient way of doing that, so you could do things 401 00:30:56,190 --> 00:30:59,090 like have every one of your messages update the key to the next key, and then 402 00:30:59,090 --> 00:31:02,820 you have within the protocol forward secrecy. We don't try to do like more 403 00:31:02,820 --> 00:31:09,669 complicated things with Diffie-Hellman ratchets or anything like that, 404 00:31:09,669 --> 00:31:16,110 Q: When would be--what's the simple sales pitch for why to use Noise over TLS? 405 00:31:16,110 --> 00:31:20,830 A: You know, probably the simplest sales pitch would be like, if you really really 406 00:31:20,830 --> 00:31:24,720 want your protocol to just do like one thing and you don't want to drag around a 407 00:31:24,720 --> 00:31:27,809 lot of code that does like a lot of things, you know like Noise will let you 408 00:31:27,809 --> 00:31:32,259 produce a very fine-tuned protocol that's a very small amount of code that just does 409 00:31:32,259 --> 00:31:35,100 like one thing pretty easily. 410 00:31:35,100 --> 00:31:37,150 Herald: That's it, thanks a lot 411 00:31:37,150 --> 00:31:41,819 Perrin: Thank you. applause 412 00:31:41,819 --> 00:31:59,440 postroll music