[Script Info]
Title: 
[Events]
Format: Layer, Start, End, Style, Name, MarginL, MarginR, MarginV, Effect, Text
Dialogue: 0,0:00:00.00,0:00:15.53,Default,,0000,0000,0000,,{\i1}preroll music{\i0}
Dialogue: 0,0:00:15.53,0:00:22.54,Default,,0000,0000,0000,,Herald: So, the next talk would be from\NTrevor Perrin. He has been called -- wait
Dialogue: 0,0:00:22.54,0:00:29.43,Default,,0000,0000,0000,,for it -- "Living Evangelist in\Ncryptographic protocol modernization"; he
Dialogue: 0,0:00:29.43,0:00:34.81,Default,,0000,0000,0000,,helped out design some of the protocols\Nthat your phone right now is executing and
Dialogue: 0,0:00:34.81,0:00:42.72,Default,,0000,0000,0000,,sending to that AP over there. Like\Nsignal, which gave him the award of the
Dialogue: 0,0:00:42.72,0:00:46.45,Default,,0000,0000,0000,,Levchin Prize and the Noise Protocol\NFramework, which is used by WhatsApp for
Dialogue: 0,0:00:46.45,0:00:51.11,Default,,0000,0000,0000,,client-to-server communication and\NWireGuard, the VPN from Jason Donenfeld,
Dialogue: 0,0:00:51.11,0:00:56.23,Default,,0000,0000,0000,,which I don't see around here... Anyways,\Nthe talk will focus on the Noise Protocol
Dialogue: 0,0:00:56.23,0:01:02.01,Default,,0000,0000,0000,,Framework. What is the rationale behind it\Nand how to use it. Please hand of
Dialogue: 0,0:01:02.01,0:01:09.25,Default,,0000,0000,0000,,applause.\N{\i1}applause{\i0}
Dialogue: 0,0:01:09.25,0:01:13.54,Default,,0000,0000,0000,,Trevor: All right, thank you everyone for\Nbeing here. My name is Trevor Perrin; I do
Dialogue: 0,0:01:13.54,0:01:18.85,Default,,0000,0000,0000,,cryptography, consulting and secure\Nprotocol design. I'm going to be talking
Dialogue: 0,0:01:18.85,0:01:25.88,Default,,0000,0000,0000,,to you this evening about a project I've\Nbeen working on for the last few years in
Dialogue: 0,0:01:25.88,0:01:32.98,Default,,0000,0000,0000,,the field of protocol design, which is the\NNoise Protocol Framework. Noise is a
Dialogue: 0,0:01:32.98,0:01:39.96,Default,,0000,0000,0000,,framework that helps you in creating\Ncryptographic secure channel protocols.
Dialogue: 0,0:01:39.96,0:01:45.71,Default,,0000,0000,0000,,The sort of protocols it addresses is\Nthings like TLS or SSH or IPSec, where you
Dialogue: 0,0:01:45.71,0:01:49.25,Default,,0000,0000,0000,,have 2 parties -- they're online at the\Nsame time, for example an internet client
Dialogue: 0,0:01:49.25,0:01:53.19,Default,,0000,0000,0000,,talking to an internet server -- they're\Ngoing to want to exchange a few messages
Dialogue: 0,0:01:53.19,0:01:57.57,Default,,0000,0000,0000,,to authenticate each other and then\Nestablish some some shared secret keys,
Dialogue: 0,0:01:57.57,0:02:01.90,Default,,0000,0000,0000,,which they can use for further\Ncommunication. Secure channel protocols
Dialogue: 0,0:02:01.90,0:02:05.92,Default,,0000,0000,0000,,like this are the the workhorses of\Npractical cryptography; most the time when
Dialogue: 0,0:02:05.92,0:02:11.53,Default,,0000,0000,0000,,crypto is used, it's within the context of\Nsome sort of secure channel protocol.
Dialogue: 0,0:02:11.53,0:02:14.81,Default,,0000,0000,0000,,There's other sorts of protocols, like\Nsecure messaging and cryptocurrency and
Dialogue: 0,0:02:14.81,0:02:19.07,Default,,0000,0000,0000,,all sorts of other things, but Noise is\Nspecifically focused on secure channels,
Dialogue: 0,0:02:19.07,0:02:25.05,Default,,0000,0000,0000,,so that's what I'm going to be talking\Nabout in this talk. And probably a lot of
Dialogue: 0,0:02:25.05,0:02:28.58,Default,,0000,0000,0000,,people, just kind of off the bat, have a\Nreaction to that of being like "Well, why?
Dialogue: 0,0:02:28.58,0:02:33.27,Default,,0000,0000,0000,,We we have secure channel protocols\Nalready: We have TLS; we have SSH; we have
Dialogue: 0,0:02:33.27,0:02:38.02,Default,,0000,0000,0000,,IPSec; and these things have been a huge\Namount of effort to design over the last
Dialogue: 0,0:02:38.02,0:02:42.27,Default,,0000,0000,0000,,20+ years. We've been bolting features\Nonto them and picking bugs out of them.
Dialogue: 0,0:02:42.27,0:02:46.85,Default,,0000,0000,0000,,Why would we want to start down that road\Nagain and build different and newer
Dialogue: 0,0:02:46.85,0:02:51.43,Default,,0000,0000,0000,,protocols?" And I think, that's a very\Nlegitimate question and source of
Dialogue: 0,0:02:51.43,0:02:58.65,Default,,0000,0000,0000,,skepticism. And my feelings about this is\Nas follows: It's that, what a secure
Dialogue: 0,0:02:58.65,0:03:02.59,Default,,0000,0000,0000,,channel protocol does is really a very\Nsimple thing; it just sends a couple
Dialogue: 0,0:03:02.59,0:03:08.21,Default,,0000,0000,0000,,messages -- 2 or 3, maybe 4 -- sets up a\Nsecure channel. So, these protocols really
Dialogue: 0,0:03:08.21,0:03:11.90,Default,,0000,0000,0000,,should be pretty simple; they should be\Nsimple to implement; they should be simple
Dialogue: 0,0:03:11.90,0:03:14.43,Default,,0000,0000,0000,,to design; and I think, a lot of the ones\Nthat we find ourselves with -- the
Dialogue: 0,0:03:14.43,0:03:18.90,Default,,0000,0000,0000,,mainstream ones -- for what they do, for\Nwhat they actually accomplish, I think,
Dialogue: 0,0:03:18.90,0:03:24.82,Default,,0000,0000,0000,,they're probably often too complex, too\Ncomplicated and too difficult to extend.
Dialogue: 0,0:03:24.82,0:03:29.87,Default,,0000,0000,0000,,And I think, we need to extend them; we're\Ngoing to need to keep adding features and
Dialogue: 0,0:03:29.87,0:03:33.07,Default,,0000,0000,0000,,extending them into new areas and with new\Ntypes of cryptography. So, it's important
Dialogue: 0,0:03:33.07,0:03:36.51,Default,,0000,0000,0000,,to have good frameworks and good ways of\Ndoing this. I think, this is an area where
Dialogue: 0,0:03:36.51,0:03:42.30,Default,,0000,0000,0000,,we need a lot of room for improvement. And\Nso, Noise is a somewhat, I guess,
Dialogue: 0,0:03:42.30,0:03:46.27,Default,,0000,0000,0000,,ambitious effort in that direction. It's\Nambitious in the sense that I love to get
Dialogue: 0,0:03:46.27,0:03:51.18,Default,,0000,0000,0000,,it to a point where people could use Noise\Nfor building all sorts of new and future
Dialogue: 0,0:03:51.18,0:03:55.62,Default,,0000,0000,0000,,protocols. I'll be the first to admit that\Nit's a work in progress; it hasn't
Dialogue: 0,0:03:55.62,0:03:59.52,Default,,0000,0000,0000,,achieved all of its ambitions yet; its\Nachieved some of them. But we're still
Dialogue: 0,0:03:59.52,0:04:05.44,Default,,0000,0000,0000,,working to extend it and if, by the end of\Nthis talk, I have then convinced people in
Dialogue: 0,0:04:05.44,0:04:09.92,Default,,0000,0000,0000,,the next 20 minutes to try to use Noise\Nfor all your new protocol design...
Dialogue: 0,0:04:09.92,0:04:14.74,Default,,0000,0000,0000,,Challenges, that's going to be okay. What\NI mainly want to get across is, just
Dialogue: 0,0:04:14.74,0:04:18.09,Default,,0000,0000,0000,,something about how these protocols work,\Nthe components that go into them, the
Dialogue: 0,0:04:18.09,0:04:21.71,Default,,0000,0000,0000,,design space they're a part of, because I\Nthink, these protocols are so essential to
Dialogue: 0,0:04:21.71,0:04:26.78,Default,,0000,0000,0000,,computer security, it's helpful for\Neveryone to understand, how they work and
Dialogue: 0,0:04:26.78,0:04:31.18,Default,,0000,0000,0000,,what they do, and not just think of them\Nas kind of black magic that only a few
Dialogue: 0,0:04:31.18,0:04:37.29,Default,,0000,0000,0000,,wizards can ever touch. So, to understand\Nthese sorts of protocols, secure channel
Dialogue: 0,0:04:37.29,0:04:41.01,Default,,0000,0000,0000,,protocols, I'm going to want to start by\Ngiving just some background on the type of
Dialogue: 0,0:04:41.01,0:04:46.19,Default,,0000,0000,0000,,cryptography that's involved in them: And\Nthe main cryptographic construct in any
Dialogue: 0,0:04:46.19,0:04:49.68,Default,,0000,0000,0000,,secure channel protocol is going to be\Nwhat cryptographers call an "Authenticated
Dialogue: 0,0:04:49.68,0:04:54.68,Default,,0000,0000,0000,,Key Exchange" or "AKE protocol" . And an\NAKE is just a sequence of messages that go
Dialogue: 0,0:04:54.68,0:04:58.69,Default,,0000,0000,0000,,back and forth between 2 parties, between\NAlice and Bob, so they can authenticate
Dialogue: 0,0:04:58.69,0:05:02.21,Default,,0000,0000,0000,,each other and then, at the end of that,\Nhave a shared secret key that they know
Dialogue: 0,0:05:02.21,0:05:08.04,Default,,0000,0000,0000,,they share with their authenticated party.\NThese protocols, these AKE protocols, can
Dialogue: 0,0:05:08.04,0:05:11.30,Default,,0000,0000,0000,,have different properties: All the ones\Nwe're going to look at have forward
Dialogue: 0,0:05:11.30,0:05:15.01,Default,,0000,0000,0000,,secrecy; they might have mutual\Nauthentication of both parties; they might
Dialogue: 0,0:05:15.01,0:05:19.56,Default,,0000,0000,0000,,have one-way authentication; how they\Nhandled identity information might be
Dialogue: 0,0:05:19.56,0:05:24.54,Default,,0000,0000,0000,,different in different AKEs, so maybe in\Nsome AKEs, both parties start off knowing
Dialogue: 0,0:05:24.54,0:05:28.72,Default,,0000,0000,0000,,each other's identity and public key and\Nsome AKEs will have to transmit this
Dialogue: 0,0:05:28.72,0:05:33.60,Default,,0000,0000,0000,,information. In other AKEs, they might\Nwant to transmit this information, but do
Dialogue: 0,0:05:33.60,0:05:38.41,Default,,0000,0000,0000,,it only after the other party has\Nnegotiated some encryption, so that their
Dialogue: 0,0:05:38.41,0:05:43.14,Default,,0000,0000,0000,,identity information is encrypted, is\Nprotected on the wire. So, there are
Dialogue: 0,0:05:43.14,0:05:46.01,Default,,0000,0000,0000,,different properties of how these things\Nwork; there are different types of crypto
Dialogue: 0,0:05:46.01,0:05:51.54,Default,,0000,0000,0000,,we can use to design AKEs that have these\Nproperties. And I want to expand on this a
Dialogue: 0,0:05:51.54,0:05:57.10,Default,,0000,0000,0000,,little bit, because most AKEs that people\Nhave experience with, the mainstream ones,
Dialogue: 0,0:05:57.10,0:06:03.02,Default,,0000,0000,0000,,all do their AKE in kind of the same way:\NThey do a AKE using signatures for
Dialogue: 0,0:06:03.02,0:06:08.39,Default,,0000,0000,0000,,authenticaton and Diffie-Hellman for a key\Nagreement. But in the last... that's a 10
Dialogue: 0,0:06:08.39,0:06:12.02,Default,,0000,0000,0000,,or so... 10+ years, there has been a\Ngrowing interest in doing AKEs that are
Dialogue: 0,0:06:12.02,0:06:17.02,Default,,0000,0000,0000,,just purely based on Diffie-Hellman key\Nagreement without signatures, and there
Dialogue: 0,0:06:17.02,0:06:22.06,Default,,0000,0000,0000,,has been a bunch of papers that analyze\Nsecurity models and do proofs for this
Dialogue: 0,0:06:22.06,0:06:27.10,Default,,0000,0000,0000,,sort of AKE. People have put this into\Npractice in things like Tor and Tor key
Dialogue: 0,0:06:27.10,0:06:32.57,Default,,0000,0000,0000,,agreement by Ian Goldberg and a number of\Ndesigns by Daniel Bernstein and others,
Dialogue: 0,0:06:32.57,0:06:37.85,Default,,0000,0000,0000,,like SALT cryptoboxes, CurveCP, etc. So,\Nthere has been a kind of interest in doing
Dialogue: 0,0:06:37.85,0:06:42.42,Default,,0000,0000,0000,,this and Noise is particularly trying to\Ntake this idea and run with it. So, I want
Dialogue: 0,0:06:42.42,0:06:47.85,Default,,0000,0000,0000,,to explain a little bit more about how\Nthese sorts of Diffie-Hellman-centric AKEs
Dialogue: 0,0:06:47.85,0:06:53.25,Default,,0000,0000,0000,,work. And so, we'll start by looking at\Njust the key exchange part of an AKE and
Dialogue: 0,0:06:53.25,0:06:56.76,Default,,0000,0000,0000,,this is part is going to be sort of\Ngeneric to all the protocols, all the AKE
Dialogue: 0,0:06:56.76,0:07:01.20,Default,,0000,0000,0000,,protocols, we talked about, which is just\Ngoing to be an unauthenticated dDffie-
Dialogue: 0,0:07:01.20,0:07:05.75,Default,,0000,0000,0000,,Hellman key exchange. The way you think\Nabout Diffie-Hellman is that there's Alice
Dialogue: 0,0:07:05.75,0:07:09.29,Default,,0000,0000,0000,,and Bob: They each have a key pair, a\Nprivate key and a public key; they're each
Dialogue: 0,0:07:09.29,0:07:12.61,Default,,0000,0000,0000,,going to exchange their public key with\Nthe others; then they're going to take
Dialogue: 0,0:07:12.61,0:07:15.38,Default,,0000,0000,0000,,their public key, they're going to take\Ntheir private key; they're going to
Dialogue: 0,0:07:15.38,0:07:20.80,Default,,0000,0000,0000,,combine these two and get a shared secret,\Nwhich is the same for both parties. So,
Dialogue: 0,0:07:20.80,0:07:25.24,Default,,0000,0000,0000,,that's just a basic Diffie-Hellman to\Nadd... to key agreement, to turn it into
Dialogue: 0,0:07:25.24,0:07:30.56,Default,,0000,0000,0000,,an authenticated key exchange, you\Nexchange, we're going to add
Dialogue: 0,0:07:30.56,0:07:34.59,Default,,0000,0000,0000,,authentication. And so, we can do that by\Nadding signatures in a very conventional
Dialogue: 0,0:07:34.59,0:07:38.99,Default,,0000,0000,0000,,way: Let's say both parties know each\Nother's public keys, so Bob just has to
Dialogue: 0,0:07:38.99,0:07:41.99,Default,,0000,0000,0000,,send an encrypted signature to Alice;\NAlice responds with an encrypted
Dialogue: 0,0:07:41.99,0:07:47.77,Default,,0000,0000,0000,,signature; now we have an AKE. And this\Ndesign is called Sigma, it's essentially
Dialogue: 0,0:07:47.77,0:07:51.98,Default,,0000,0000,0000,,Sigma, and it's essentially how something\Nlike TLS 1.3 works, where you first get a
Dialogue: 0,0:07:51.98,0:07:57.87,Default,,0000,0000,0000,,secret key, then send signatures as\Nauthenticators under the encryption. And
Dialogue: 0,0:07:57.87,0:08:02.15,Default,,0000,0000,0000,,there's nothing wrong with this design,\Nit's a good design. We can look at that
Dialogue: 0,0:08:02.15,0:08:06.59,Default,,0000,0000,0000,,schematically by imagining that what's\Nhappening if we don't consider the message
Dialogue: 0,0:08:06.59,0:08:10.65,Default,,0000,0000,0000,,sequences: Alice and Bob are each signing\Nthe key agreement, so that once they get a
Dialogue: 0,0:08:10.65,0:08:14.96,Default,,0000,0000,0000,,shared key, they know that the other party\Nagrees with this shared key by verifying
Dialogue: 0,0:08:14.96,0:08:20.47,Default,,0000,0000,0000,,the signature. If we want to do an AKE\Nthat's entirely signature-based, we're
Dialogue: 0,0:08:20.47,0:08:23.88,Default,,0000,0000,0000,,going to have to replace these signatures\Nwith some sort of Diffie-Hellman, while
Dialogue: 0,0:08:23.88,0:08:28.45,Default,,0000,0000,0000,,still getting that same confidence and\Nthat same guarantee, that the other party
Dialogue: 0,0:08:28.45,0:08:35.33,Default,,0000,0000,0000,,agrees on the ultimate, final, shared\Nsecret key we get out of this AKE. So, the
Dialogue: 0,0:08:35.33,0:08:39.71,Default,,0000,0000,0000,,way we can do that is, we can say "Well,\Nthese these long-lived key pairs that
Dialogue: 0,0:08:39.71,0:08:42.43,Default,,0000,0000,0000,,people have, we'll call them static key\Npairs; they're going to be Diffie-Hellman
Dialogue: 0,0:08:42.43,0:08:48.29,Default,,0000,0000,0000,,key pairs instead of signature key pairs;\Nand each party is going, to in addition to
Dialogue: 0,0:08:48.29,0:08:52.57,Default,,0000,0000,0000,,doing an ephemeral, do ephemeral DH for\Nforward secrecy, do an ephemeral DH to the
Dialogue: 0,0:08:52.57,0:08:56.11,Default,,0000,0000,0000,,other party's static key for\Nauthentication, and then hash all these
Dialogue: 0,0:08:56.11,0:09:02.27,Default,,0000,0000,0000,,DHs together to get a final key. And the\Nreason why this convinces each party that
Dialogue: 0,0:09:02.27,0:09:07.34,Default,,0000,0000,0000,,the other party has agreed to the final\Nkey is, because this final key is a hash
Dialogue: 0,0:09:07.34,0:09:12.90,Default,,0000,0000,0000,,that includes the DH of the authentication\NDH of their ephemeral key, the other
Dialogue: 0,0:09:12.90,0:09:16.12,Default,,0000,0000,0000,,party's static private key -- the only\Nother party who knows the output of that
Dialogue: 0,0:09:16.12,0:09:21.79,Default,,0000,0000,0000,,DH is the other party -- thus, if we do\Nanything with the final shared secret key,
Dialogue: 0,0:09:21.79,0:09:25.27,Default,,0000,0000,0000,,like receive any encrypted message from\Nit, we know that key can only have been
Dialogue: 0,0:09:25.27,0:09:31.59,Default,,0000,0000,0000,,calculated by the correct counterparty.\NSo, we're accomplishing authentication by
Dialogue: 0,0:09:31.59,0:09:37.39,Default,,0000,0000,0000,,using DH instead of signatures here and so\Nthis is a... it's a well understood thing,
Dialogue: 0,0:09:37.39,0:09:41.04,Default,,0000,0000,0000,,but I wanted to kind of just touch on that\Nbefore we talk about... where I dive into
Dialogue: 0,0:09:41.04,0:09:44.23,Default,,0000,0000,0000,,the history of Noise. And the history of\NNoise is that a few years ago, I was
Dialogue: 0,0:09:44.23,0:09:48.92,Default,,0000,0000,0000,,reading a lot of these papers that talked,\NDiffie-Hellman-based key exchange, and
Dialogue: 0,0:09:48.92,0:09:53.35,Default,,0000,0000,0000,,looking at a number of these designs where\Npeople were doing Diffie-Hellman-based key
Dialogue: 0,0:09:53.35,0:09:56.72,Default,,0000,0000,0000,,exchange and I thought, these were cool\Ndesigns. I thought, they were elegant; I
Dialogue: 0,0:09:56.72,0:10:01.52,Default,,0000,0000,0000,,thought they were efficient. But every\Ntime someone did a new Diffie-Hellman-
Dialogue: 0,0:10:01.52,0:10:06.79,Default,,0000,0000,0000,,based thing, like nTor or salt or CurveCP\Nor OPTLS, they would sort of start from
Dialogue: 0,0:10:06.79,0:10:10.89,Default,,0000,0000,0000,,scratch and they'd say "Okay, how are we\Ngoing to do key derivation? How are we
Dialogue: 0,0:10:10.89,0:10:14.21,Default,,0000,0000,0000,,going to do transcript hashing? How are we\Ngoing to do key confirmation?" If they
Dialogue: 0,0:10:14.21,0:10:17.42,Default,,0000,0000,0000,,were doing security analysis, they'd\Ncreate their own security model; they'd
Dialogue: 0,0:10:17.42,0:10:21.58,Default,,0000,0000,0000,,write their own Gap DH ROM-based\Nsecurity proof that's pretty much the same
Dialogue: 0,0:10:21.58,0:10:24.70,Default,,0000,0000,0000,,as everyone else's security proof, but\Nit's still a lot of work. So, there was a
Dialogue: 0,0:10:24.70,0:10:30.04,Default,,0000,0000,0000,,lot of reused or sort of repeated work\Nbeing done to build this style of protocol
Dialogue: 0,0:10:30.04,0:10:35.40,Default,,0000,0000,0000,,and so, the the motivating idea for Noise\Nwas, whether we could capture that work
Dialogue: 0,0:10:35.40,0:10:38.41,Default,,0000,0000,0000,,into a framework that just provided you\Nsome common elements so people could
Dialogue: 0,0:10:38.41,0:10:42.67,Default,,0000,0000,0000,,easily combine those elements together and\Ncreate a wide range of different protocols
Dialogue: 0,0:10:42.67,0:10:47.47,Default,,0000,0000,0000,,in this style. And so, I started working\Non ways of kind of connecting protocol
Dialogue: 0,0:10:47.47,0:10:53.23,Default,,0000,0000,0000,,pieces together. Eventually, I talked to\NMike Hamburg who's working on something
Dialogue: 0,0:10:53.23,0:10:56.78,Default,,0000,0000,0000,,else -- this Strobe Protocol Framework\Nthat was kind of based on sponge-based
Dialogue: 0,0:10:56.78,0:11:02.51,Default,,0000,0000,0000,,cryptography -- and we kind of took some\Nideas from that. With with all those ideas
Dialogue: 0,0:11:02.51,0:11:05.91,Default,,0000,0000,0000,,we were able to come up with I think a\Npretty good system for describing a wide
Dialogue: 0,0:11:05.91,0:11:09.46,Default,,0000,0000,0000,,range of protocols just by taking a\NDiffie-Hellman operation and some simple
Dialogue: 0,0:11:09.46,0:11:15.52,Default,,0000,0000,0000,,other cryptography and combining them in a\Nbunch of different ways. That core design
Dialogue: 0,0:11:15.52,0:11:22.51,Default,,0000,0000,0000,,of noise is what we arrived at by 2015 and\Nit's been stable since then. We know noise
Dialogue: 0,0:11:22.51,0:11:25.45,Default,,0000,0000,0000,,is still a work in progress because we're\Ntrying to extend it and add new forms of
Dialogue: 0,0:11:25.45,0:11:30.74,Default,,0000,0000,0000,,cryptography and build more things around\Nthis core but we do have a pretty good
Dialogue: 0,0:11:30.74,0:11:34.91,Default,,0000,0000,0000,,core at this point. We've built a small\Ncommunity around it with a mailing list,
Dialogue: 0,0:11:34.91,0:11:39.75,Default,,0000,0000,0000,,website, specifications, test suites, open\Nsource libraries in a bunch of common
Dialogue: 0,0:11:39.75,0:11:45.15,Default,,0000,0000,0000,,languages and we also have a couple users:\NNoise Based Protocol is used by WhatsApp
Dialogue: 0,0:11:45.15,0:11:51.27,Default,,0000,0000,0000,,for client-to-server communication from\Nthe app to the server and WireGuard which
Dialogue: 0,0:11:51.27,0:11:56.79,Default,,0000,0000,0000,,is a next generation VPN tunnel project by\NJason Donenfeld, it also uses a a noise
Dialogue: 0,0:11:56.79,0:12:01.38,Default,,0000,0000,0000,,based secure channel protocol. We're also\Ngetting interest from some some other
Dialogue: 0,0:12:01.38,0:12:05.43,Default,,0000,0000,0000,,directions, from people doing like\NInternet of Things, embedded systems,
Dialogue: 0,0:12:05.43,0:12:11.13,Default,,0000,0000,0000,,anonymity network type systems, the\NLightning Network proposal for Bitcoin
Dialogue: 0,0:12:11.13,0:12:16.10,Default,,0000,0000,0000,,which will incorporate a Noise Based\NProtocol. So I think we're getting
Dialogue: 0,0:12:16.10,0:12:21.20,Default,,0000,0000,0000,,interest from people who potentially want\Na customized secure channel protocol for a
Dialogue: 0,0:12:21.20,0:12:25.48,Default,,0000,0000,0000,,new area they're working in but don't want\Nto drag in a lot of extraneous complexity.
Dialogue: 0,0:12:25.48,0:12:29.67,Default,,0000,0000,0000,,They want something simple and efficient\Nthat addresses their use case. That's what
Dialogue: 0,0:12:29.67,0:12:34.83,Default,,0000,0000,0000,,I think is the sweet spot for Noise so\Nfar. For the rest of this talk, what I
Dialogue: 0,0:12:34.83,0:12:40.55,Default,,0000,0000,0000,,want to do is talk about what the\Ncomponents of a secure channel protocol
Dialogue: 0,0:12:40.55,0:12:44.99,Default,,0000,0000,0000,,are, why I think it's a good idea to have\Na framework that addresses the design of
Dialogue: 0,0:12:44.99,0:12:50.21,Default,,0000,0000,0000,,these things, and then fill in the details\Non what the Noise framework actually is.
Dialogue: 0,0:12:50.21,0:12:54.44,Default,,0000,0000,0000,,Secure channel protocols all have kind of\Nthe same structure: they start with a
Dialogue: 0,0:12:54.44,0:12:58.03,Default,,0000,0000,0000,,handshake phase where parties send a few\Nmessages back and forth to get a shared
Dialogue: 0,0:12:58.03,0:13:03.04,Default,,0000,0000,0000,,secret key, then they use this shared\Nsecret key for the transport phase of just
Dialogue: 0,0:13:03.04,0:13:08.43,Default,,0000,0000,0000,,doing bulk encryption. The transport phase\Nis a simple thing, it's pretty easy to
Dialogue: 0,0:13:08.43,0:13:13.37,Default,,0000,0000,0000,,just use shared keys to encrypt data back\Nand forth, so I'm not going to say a lot
Dialogue: 0,0:13:13.37,0:13:18.42,Default,,0000,0000,0000,,more about it. The handshake phase is\Nwhere all the excitement and the
Dialogue: 0,0:13:18.42,0:13:25.70,Default,,0000,0000,0000,,interesting things are. Of course, the\Nmain component of a secure protocol, a
Dialogue: 0,0:13:25.70,0:13:28.23,Default,,0000,0000,0000,,secure channel, is the handshake. It's\Ngoing to be just an authenticated key
Dialogue: 0,0:13:28.23,0:13:33.76,Default,,0000,0000,0000,,exchange, an AKE of some sort, but a lot\Nof secure channel protocols will also have
Dialogue: 0,0:13:33.76,0:13:40.68,Default,,0000,0000,0000,,some sort of negotiation that happens\Nlogically before the rest of this that
Dialogue: 0,0:13:40.68,0:13:44.86,Default,,0000,0000,0000,,determines the type of AKE, and the\Nparameters of the AKE, and the parameters
Dialogue: 0,0:13:44.86,0:13:49.76,Default,,0000,0000,0000,,of the encryption such as which cipher to\Nuse. You can think of this negotiation
Dialogue: 0,0:13:49.76,0:13:53.67,Default,,0000,0000,0000,,happening logically before everything else\Nbecause it determines everything else, but
Dialogue: 0,0:13:53.67,0:13:58.48,Default,,0000,0000,0000,,in practice, for efficiency, the\Nnegotiation of the AKE are usually
Dialogue: 0,0:13:58.48,0:14:03.24,Default,,0000,0000,0000,,overlaid or woven together a little bit.\NSo I might send an initial message from
Dialogue: 0,0:14:03.24,0:14:08.01,Default,,0000,0000,0000,,the client that says "I'm speculatively\Nexecuting this AKE protocol but I'm
Dialogue: 0,0:14:08.01,0:14:11.44,Default,,0000,0000,0000,,willing to execute these other protocols\Nand I'm willing to use these ciphers for
Dialogue: 0,0:14:11.44,0:14:15.18,Default,,0000,0000,0000,,the transport phase", and then the server\Ncan respond by saying "I want you to do a
Dialogue: 0,0:14:15.18,0:14:19.52,Default,,0000,0000,0000,,different AKE, I want you to use these\Nciphers at the end of it". So you have
Dialogue: 0,0:14:19.52,0:14:23.73,Default,,0000,0000,0000,,these negotiation in AKE happening kind of\Nsimultaneously, which is one of the
Dialogue: 0,0:14:23.73,0:14:28.88,Default,,0000,0000,0000,,reasons these protocols are a little\Ncomplicated to think about. But anyways,
Dialogue: 0,0:14:28.88,0:14:33.80,Default,,0000,0000,0000,,if we were building a single secure\Nchannel protocol, we would be trying to
Dialogue: 0,0:14:33.80,0:14:37.63,Default,,0000,0000,0000,,fill in these elements. We would be\Nsaying, okay, what AKE do we want to use,
Dialogue: 0,0:14:37.63,0:14:40.93,Default,,0000,0000,0000,,how do we want to instantiate the\Ncryptography within them, and then how do
Dialogue: 0,0:14:40.93,0:14:46.12,Default,,0000,0000,0000,,we want to design a negotiation structure\Nthat can select one of these different
Dialogue: 0,0:14:46.12,0:14:52.40,Default,,0000,0000,0000,,things, and how do we assemble all that\Ntogether. We're not trying to build a a
Dialogue: 0,0:14:52.40,0:14:57.30,Default,,0000,0000,0000,,single AKE protocol, we're trying to build\Na framework for building AKE protocols, so
Dialogue: 0,0:14:57.30,0:15:04.95,Default,,0000,0000,0000,,we're doing something a little bit more\Nconfusing and the reason is pretty simple.
Dialogue: 0,0:15:04.95,0:15:11.48,Default,,0000,0000,0000,,If you're trying to build a single\Nprotocol, you have a hard decision, and a
Dialogue: 0,0:15:11.48,0:15:15.87,Default,,0000,0000,0000,,difficult trade-off to manage between\Nadding features into this protocol and
Dialogue: 0,0:15:15.87,0:15:19.77,Default,,0000,0000,0000,,keeping it simple. Because the more\Nfeatures you add, the more negotiations
Dialogue: 0,0:15:19.77,0:15:25.23,Default,,0000,0000,0000,,you have, the more different branches your\Nprotocol can take, the more complexity
Dialogue: 0,0:15:25.23,0:15:29.18,Default,,0000,0000,0000,,every implementer has to deal with, the\Nmore attack service you have, because if
Dialogue: 0,0:15:29.18,0:15:33.12,Default,,0000,0000,0000,,there's any bug in any of these features\Nthat an attacker can navigate to, that's
Dialogue: 0,0:15:33.12,0:15:38.67,Default,,0000,0000,0000,,potentially a problem. We want to work on\Nthings that have a lot of features that
Dialogue: 0,0:15:38.67,0:15:42.79,Default,,0000,0000,0000,,address a lot of cases, but we also want\Nto keep things simple. So if we think of
Dialogue: 0,0:15:42.79,0:15:46.85,Default,,0000,0000,0000,,ourselves as creating not just a single\Nprotocol, but a framework of protocols, we
Dialogue: 0,0:15:46.85,0:15:50.67,Default,,0000,0000,0000,,can kind of manage that tension a little\Nbit better by imagining that we have all
Dialogue: 0,0:15:50.67,0:15:55.27,Default,,0000,0000,0000,,these features and all these capabilities\Noff to the side, and a library or a tool
Dialogue: 0,0:15:55.27,0:15:58.33,Default,,0000,0000,0000,,somewhere. And when we build a concrete\Nprotocol, we're just going to select a
Dialogue: 0,0:15:58.33,0:16:01.88,Default,,0000,0000,0000,,bunch of features and hopefully have some\Nsimple combination rules for putting them
Dialogue: 0,0:16:01.88,0:16:07.37,Default,,0000,0000,0000,,together and to get a very customized\Nprotocol that does exactly what we want
Dialogue: 0,0:16:07.37,0:16:12.76,Default,,0000,0000,0000,,and not anything that we we don't want.\NThat means that working with Noise is
Dialogue: 0,0:16:12.76,0:16:18.89,Default,,0000,0000,0000,,different from working with something like\NTLS because with most cryptographic
Dialogue: 0,0:16:18.89,0:16:22.59,Default,,0000,0000,0000,,protocols, you probably can just take a\NTLS library, point it at another TLS
Dialogue: 0,0:16:22.59,0:16:26.47,Default,,0000,0000,0000,,library, and they'll figure out how to\Nconnect. They'll do negotiations, fall
Dialogue: 0,0:16:26.47,0:16:31.06,Default,,0000,0000,0000,,backs, retries, ... and they'll find the\Nintersection of cipher suites and
Dialogue: 0,0:16:31.06,0:16:35.81,Default,,0000,0000,0000,,versions, etc. that they support, and will\Nconnect to each other. That's a feat of
Dialogue: 0,0:16:35.81,0:16:39.07,Default,,0000,0000,0000,,engineering, but there's a lot of\Ncomplexity that lies behind that, and
Dialogue: 0,0:16:39.07,0:16:44.69,Default,,0000,0000,0000,,there's a lot of opacity in understanding\Nwhat you're really getting. To use Noise,
Dialogue: 0,0:16:44.69,0:16:49.23,Default,,0000,0000,0000,,on the other hand, you have to think in\Nadvance about what you want to use, what
Dialogue: 0,0:16:49.23,0:16:51.88,Default,,0000,0000,0000,,AKEs you want to use, what cryptography\Nyou're gonna get... You're going to choose
Dialogue: 0,0:16:51.88,0:16:55.48,Default,,0000,0000,0000,,all these things. You're going to have to\Nunderstand why you want the sequence of
Dialogue: 0,0:16:55.48,0:16:58.16,Default,,0000,0000,0000,,messages, you're going to put them\Ntogether, and you're going to end up with
Dialogue: 0,0:16:58.16,0:17:03.41,Default,,0000,0000,0000,,something that very much addresses your\Nuse case, hopefully, but is not going to
Dialogue: 0,0:17:03.41,0:17:07.46,Default,,0000,0000,0000,,have a lot of extraneous complexity. So\Nthat's a different way of working with
Dialogue: 0,0:17:07.46,0:17:11.73,Default,,0000,0000,0000,,protocols and thinking about protocols,\Nbut I think it's the right answer for a
Dialogue: 0,0:17:11.73,0:17:16.67,Default,,0000,0000,0000,,lot of cases. At least that's our goal. We\Nwant to build as a framework where we can
Dialogue: 0,0:17:16.67,0:17:25.08,Default,,0000,0000,0000,,choose a bunch of things, combine them\Ntogether, and then end up with a wide
Dialogue: 0,0:17:25.08,0:17:29.24,Default,,0000,0000,0000,,range of different protocols. But to get\Nthere is a little bit complicated. To get
Dialogue: 0,0:17:29.24,0:17:33.78,Default,,0000,0000,0000,,there, we're gonna have to take our\Nstructure of a secure channel protocol and
Dialogue: 0,0:17:33.78,0:17:37.31,Default,,0000,0000,0000,,break it up into some different elements\Nso that we can mix and match these
Dialogue: 0,0:17:37.31,0:17:42.17,Default,,0000,0000,0000,,elements and get different protocols.\NWe're gonna break it up in a couple
Dialogue: 0,0:17:42.17,0:17:46.24,Default,,0000,0000,0000,,different ways. The first way we're going\Nto do that is we're gonna separate out all
Dialogue: 0,0:17:46.24,0:17:52.47,Default,,0000,0000,0000,,the points in the protocol where runtime\Ndecisions are made from all the points of
Dialogue: 0,0:17:52.47,0:17:57.04,Default,,0000,0000,0000,,the protocol, we can think of, it's just\Nstraight line, linear code. And the reason
Dialogue: 0,0:17:57.04,0:18:01.70,Default,,0000,0000,0000,,why is because, if we have straight line,\Njust linear cryptographic code that just
Dialogue: 0,0:18:01.70,0:18:06.50,Default,,0000,0000,0000,,does one thing after another and sends one\Nmessage after another, and does nothing
Dialogue: 0,0:18:06.50,0:18:10.96,Default,,0000,0000,0000,,else, except maybe erroring if it detects,\Nsay, it detects cryptographic
Dialogue: 0,0:18:10.96,0:18:14.50,Default,,0000,0000,0000,,authentication failure. We have code like\Nthat. It's very easy to test, it's easy to
Dialogue: 0,0:18:14.50,0:18:19.06,Default,,0000,0000,0000,,think about, it's easy to design things\Naround because it just does one thing in a
Dialogue: 0,0:18:19.06,0:18:23.55,Default,,0000,0000,0000,,sequence. And so that's… Noise is very\Nmuch going to be about forcing people to
Dialogue: 0,0:18:23.55,0:18:29.88,Default,,0000,0000,0000,,use straight line code with no branches as\Nmuch as possible. Our idea of being a
Dialogue: 0,0:18:29.88,0:18:33.37,Default,,0000,0000,0000,,framework hopefully helps with that\Nbecause we've moved a lot of decisions
Dialogue: 0,0:18:33.37,0:18:37.82,Default,,0000,0000,0000,,that might have been runtime decisions,\Nnegotiation decision in a full protocol,
Dialogue: 0,0:18:37.82,0:18:41.95,Default,,0000,0000,0000,,we're moving them to, hopefully, design\Ntime decisions within a framework. But we
Dialogue: 0,0:18:41.95,0:18:45.51,Default,,0000,0000,0000,,might still have some negotiation\Ndecisions remaining about, like, which
Dialogue: 0,0:18:45.51,0:18:51.08,Default,,0000,0000,0000,,cipher to use or, you know like, if we try\Nto do a zero round-trip encryption, we
Dialogue: 0,0:18:51.08,0:18:53.84,Default,,0000,0000,0000,,might have to fall back to something else.\NSo there might be some decisions that
Dialogue: 0,0:18:53.84,0:18:57.20,Default,,0000,0000,0000,,remain. We're going to try to compress all\Nthose decisions into kind of one, and say
Dialogue: 0,0:18:57.20,0:19:01.36,Default,,0000,0000,0000,,there's only one point in this framework\Nwhere runtime decisions get made, which is
Dialogue: 0,0:19:01.36,0:19:05.79,Default,,0000,0000,0000,,selecting what we're going to call a Noise\Nprotocol. And the Noise… And this notion
Dialogue: 0,0:19:05.79,0:19:08.95,Default,,0000,0000,0000,,of the Noise protocol is going to\Nencapsulate everything else that happens.
Dialogue: 0,0:19:08.95,0:19:13.17,Default,,0000,0000,0000,,It's just a linear sequence of code, it's\Ngoing to be the AKE plus whatever
Dialogue: 0,0:19:13.17,0:19:18.10,Default,,0000,0000,0000,,transport encryption happens after that.\NSo with this framework we've hopefully…
Dialogue: 0,0:19:18.10,0:19:20.81,Default,,0000,0000,0000,,You know, we hate decision-making at\Nruntime but we're going to compress it
Dialogue: 0,0:19:20.81,0:19:24.12,Default,,0000,0000,0000,,down to one if we have to and then call\Neverything else just a straight line
Dialogue: 0,0:19:24.12,0:19:28.22,Default,,0000,0000,0000,,sequence of code. The next thing we're\Ngoing to do to make this framework sort of
Dialogue: 0,0:19:28.22,0:19:33.83,Default,,0000,0000,0000,,manageable and break it down, is zoom in\Non this notion of the Noise protocol and
Dialogue: 0,0:19:33.83,0:19:36.92,Default,,0000,0000,0000,,break that into pieces too. And so we're\Ngoing to view that as a combination of,
Dialogue: 0,0:19:36.92,0:19:41.68,Default,,0000,0000,0000,,what we call a handshake pattern, with\Nsome actual crypto algorithms. And a
Dialogue: 0,0:19:41.68,0:19:46.30,Default,,0000,0000,0000,,handshake pattern is going to be like an\Nabstract notion of an AKE, so it's going
Dialogue: 0,0:19:46.30,0:19:50.73,Default,,0000,0000,0000,,to be an AKE protocol that just says: do\Nsome sort of Diffie-Hellman, encrypt this
Dialogue: 0,0:19:50.73,0:19:54.47,Default,,0000,0000,0000,,in some way, hash this in some way, but\Nit's not going to tell you what crypto to
Dialogue: 0,0:19:54.47,0:19:58.14,Default,,0000,0000,0000,,use. You're going to plug in crypto, and\Nit's that combination of things is gonna
Dialogue: 0,0:19:58.14,0:20:03.84,Default,,0000,0000,0000,,give you a concrete Noise protocol, which\Nis in kind of an implementable unit of
Dialogue: 0,0:20:03.84,0:20:09.85,Default,,0000,0000,0000,,this framework. So, the whole framework\Nthen kind of ends up being like this: the
Dialogue: 0,0:20:09.85,0:20:13.38,Default,,0000,0000,0000,,sort of core central piece is this notion\Nof the Noise protocol which is, what we've
Dialogue: 0,0:20:13.38,0:20:17.42,Default,,0000,0000,0000,,probably spent most of our engineering\Neffort on, where we combine some abstract
Dialogue: 0,0:20:17.42,0:20:22.25,Default,,0000,0000,0000,,notion of an AKE, a handshake pattern,\Nwith some crypto to get a Noise protocol.
Dialogue: 0,0:20:22.25,0:20:25.01,Default,,0000,0000,0000,,We're going to imagine a negotiation layer\Nthat can really just make one decision
Dialogue: 0,0:20:25.01,0:20:29.35,Default,,0000,0000,0000,,which is: does the server want to switch\Nfrom the initial noise protocol to a
Dialogue: 0,0:20:29.35,0:20:31.95,Default,,0000,0000,0000,,different one. So we're only going to\Nallow one transition, just to make things
Dialogue: 0,0:20:31.95,0:20:37.21,Default,,0000,0000,0000,,really simple. And then the only other\Nlayer we're going to add, is this notion
Dialogue: 0,0:20:37.21,0:20:41.96,Default,,0000,0000,0000,,of an encoding layer which is that, we\Nmight want to send our messages over TCP,
Dialogue: 0,0:20:41.96,0:20:46.07,Default,,0000,0000,0000,,in which case we'd have to add length\Nfields. Or we might send them over HTTP,
Dialogue: 0,0:20:46.07,0:20:49.31,Default,,0000,0000,0000,,in which case we'll have to encode them as\NHTTP requests. So we have this kind of
Dialogue: 0,0:20:49.31,0:20:52.58,Default,,0000,0000,0000,,abstract notion of our protocol, but we\Nmight need to add a little bit more
Dialogue: 0,0:20:52.58,0:20:56.99,Default,,0000,0000,0000,,encoding to actually fit it into a\Nparticular context. And that's, you know,
Dialogue: 0,0:20:56.99,0:21:02.08,Default,,0000,0000,0000,,that's gonna be kind of just the whole way\Nwe build secure channel protocols. So, the
Dialogue: 0,0:21:02.08,0:21:09.66,Default,,0000,0000,0000,,main thing that you're going to interact\Nwith, is, or the kind of central piece of
Dialogue: 0,0:21:09.66,0:21:13.65,Default,,0000,0000,0000,,this is the Noise protocol and the main\Nway that you're going to interact with
Dialogue: 0,0:21:13.65,0:21:19.17,Default,,0000,0000,0000,,Noise protocols and design them as a user,\Nis by just giving them names. And so we
Dialogue: 0,0:21:19.17,0:21:22.96,Default,,0000,0000,0000,,have this notion of, you can precisely\Nname a Noise protocol and then that just,
Dialogue: 0,0:21:22.96,0:21:30.19,Default,,0000,0000,0000,,kind of like, defines the entire protocol.\NSo here we have a Noise protocol that's,
Dialogue: 0,0:21:30.19,0:21:35.47,Default,,0000,0000,0000,,you know, this is a concrete implementable\Nthing: it uses the NX pattern which, I
Dialogue: 0,0:21:35.47,0:21:39.73,Default,,0000,0000,0000,,haven't explained what that means, but it\Nalso combines that pattern that AKE notion
Dialogue: 0,0:21:39.73,0:21:44.01,Default,,0000,0000,0000,,with Curve25519 for Diffie-Hellman, with\NAES-GCM for encryption, with SHA-256 for
Dialogue: 0,0:21:44.01,0:21:51.92,Default,,0000,0000,0000,,hashing, we can plug in or out different\Noptions of any one of these things. So we
Dialogue: 0,0:21:51.92,0:21:57.10,Default,,0000,0000,0000,,could have different patterns, different\Nciphers, etc. to get a Noise protocol and
Dialogue: 0,0:21:57.10,0:22:01.12,Default,,0000,0000,0000,,then the specification, and most of our\NNoise libraries can take this name and
Dialogue: 0,0:22:01.12,0:22:05.01,Default,,0000,0000,0000,,will just automatically know what to do.\NThey'll synthesize a whole protocol around
Dialogue: 0,0:22:05.01,0:22:11.11,Default,,0000,0000,0000,,this, just with some some pretty simple\Nrules. And, so the pattern notion and the
Dialogue: 0,0:22:11.11,0:22:15.85,Default,,0000,0000,0000,,way we're naming patterns… There is a\Nnaming convention here but I think more
Dialogue: 0,0:22:15.85,0:22:18.48,Default,,0000,0000,0000,,important than understanding the naming\Nconvention, is understanding this simple
Dialogue: 0,0:22:18.48,0:22:23.86,Default,,0000,0000,0000,,language that it's built on top of. And,\Nso we're gonna have a sort of simple
Dialogue: 0,0:22:23.86,0:22:30.35,Default,,0000,0000,0000,,language for describing a range of sort of\Nabstract AKE patterns based on, based on
Dialogue: 0,0:22:30.35,0:22:35.51,Default,,0000,0000,0000,,this set of concepts, based on just saying\Nwe have Alice and Bob, they each might
Dialogue: 0,0:22:35.51,0:22:39.30,Default,,0000,0000,0000,,have a static key and they might have an\Nephemeral key, and the only things we're
Dialogue: 0,0:22:39.30,0:22:43.90,Default,,0000,0000,0000,,gonna allow them to do, as part of their\NAKE protocol, is send their public keys
Dialogue: 0,0:22:43.90,0:22:47.57,Default,,0000,0000,0000,,back and forth and do Diffie-Hellman\Noperations and the only Diffie-Hellman
Dialogue: 0,0:22:47.57,0:22:52.35,Default,,0000,0000,0000,,operations they can do are, you know,\Nthese four involving some combination of
Dialogue: 0,0:22:52.35,0:22:56.11,Default,,0000,0000,0000,,their keys which you can just read from\Nleft to right, so they can do this static-
Dialogue: 0,0:22:56.11,0:23:00.51,Default,,0000,0000,0000,,static Diffie-Hellman, they can do the\NAlice's static to Bob's ephemeral which
Dialogue: 0,0:23:00.51,0:23:04.57,Default,,0000,0000,0000,,sort of authenticates Alice, you can do\NAlice's ephemeral to Bob's static which
Dialogue: 0,0:23:04.57,0:23:09.68,Default,,0000,0000,0000,,authenticates Bob, or they can do this EE\NDiffie-Hellman for forward secrecy. So
Dialogue: 0,0:23:09.68,0:23:13.10,Default,,0000,0000,0000,,we're going to allow them just to combine\Nthese units in different ways and get a
Dialogue: 0,0:23:13.10,0:23:18.50,Default,,0000,0000,0000,,wide range of different AKEs out of this.\NSo let's start demonstrate... I'm going to
Dialogue: 0,0:23:18.50,0:23:20.65,Default,,0000,0000,0000,,demonstrate a bunch of patterns and kind\Nof go through them quickly, and let's
Dialogue: 0,0:23:20.65,0:23:23.71,Default,,0000,0000,0000,,start with something that's very simple,\Nwhich is just a public key encryption. So
Dialogue: 0,0:23:23.71,0:23:27.79,Default,,0000,0000,0000,,this AKE pattern doesn't even describe an\Ninteractive protocol, it's just Alice
Dialogue: 0,0:23:27.79,0:23:32.93,Default,,0000,0000,0000,,encrypting a message to Bob. And so, our\Nlittle language here, we're going to add
Dialogue: 0,0:23:32.93,0:23:38.12,Default,,0000,0000,0000,,three dots to indicate when Alice has\Nprior knowledge of something before the
Dialogue: 0,0:23:38.12,0:23:42.88,Default,,0000,0000,0000,,protocol starts. So this is a protocol\Nwhere Alice knows Bob's public key at the
Dialogue: 0,0:23:42.88,0:23:45.82,Default,,0000,0000,0000,,outset. She's going to send one message\Nwhich is an ephemeral public key she
Dialogue: 0,0:23:45.82,0:23:49.95,Default,,0000,0000,0000,,chooses. She's going to do an ES,\NEphemeral Static Diffie-Hellman, to
Dialogue: 0,0:23:49.95,0:23:54.29,Default,,0000,0000,0000,,authenticate Bob and that's going to give\Nher public key encryption because then
Dialogue: 0,0:23:54.29,0:23:57.79,Default,,0000,0000,0000,,she's going to have keys that she can use\Nfor sort of the transport phase encryption
Dialogue: 0,0:23:57.79,0:24:01.79,Default,,0000,0000,0000,,of the message she's sending to Bob. So\Nthat's just--you could think of this as in
Dialogue: 0,0:24:01.79,0:24:06.04,Default,,0000,0000,0000,,like an ECIES or an ephemeral static\Npublic key encryption. We could make this
Dialogue: 0,0:24:06.04,0:24:09.78,Default,,0000,0000,0000,,more complicated by saying both parties\Nknow their public keys and we want Alice
Dialogue: 0,0:24:09.78,0:24:13.22,Default,,0000,0000,0000,,to authenticate to Bob, and now we just\Nthrow in the static-static encryption and
Dialogue: 0,0:24:13.22,0:24:17.83,Default,,0000,0000,0000,,now we have Alice authenticating herself\Nto Bob. We could make another step in
Dialogue: 0,0:24:17.83,0:24:21.93,Default,,0000,0000,0000,,complexity and say we want Alice to\Nauthenticate herself to Bob and also send
Dialogue: 0,0:24:21.93,0:24:25.81,Default,,0000,0000,0000,,her public key to Bob, and she might also\Nhave to send certificates and things like
Dialogue: 0,0:24:25.81,0:24:29.65,Default,,0000,0000,0000,,that to convince Bob her public key is to\Nbe trusted. That can go in the transport
Dialogue: 0,0:24:29.65,0:24:34.39,Default,,0000,0000,0000,,payload, but the point is now we've taken\NAlice's public key and say instead of it
Dialogue: 0,0:24:34.39,0:24:39.75,Default,,0000,0000,0000,,being prior knowledge of Bob's, it's\Ntransported in the message itself, and
Dialogue: 0,0:24:39.75,0:24:45.14,Default,,0000,0000,0000,,we're going to have this additional rule\Nwhich is that any time we send the static
Dialogue: 0,0:24:45.14,0:24:48.45,Default,,0000,0000,0000,,public key we're gonna encrypt it with all\Nthe other keys that have come before. So
Dialogue: 0,0:24:48.45,0:24:53.25,Default,,0000,0000,0000,,in this case Alice's static public key is\Nencrypted with the output of the ephemeral
Dialogue: 0,0:24:53.25,0:24:57.07,Default,,0000,0000,0000,,static DH, which provides some identity\Nhiding, so someone looking at the wire
Dialogue: 0,0:24:57.07,0:25:03.72,Default,,0000,0000,0000,,doesn't know who Alice's is, even though\NBob knows. We can move on to interactive
Dialogue: 0,0:25:03.72,0:25:07.43,Default,,0000,0000,0000,,protocols and look at unauthenticated\NDiffie-Hellman, just looks like this: an
Dialogue: 0,0:25:07.43,0:25:12.17,Default,,0000,0000,0000,,exchange of the ephemeral public keys and\Na Diffie-Hellman. You could add server
Dialogue: 0,0:25:12.17,0:25:17.00,Default,,0000,0000,0000,,authentication to that, where the server\Njust sends its static public key and does
Dialogue: 0,0:25:17.00,0:25:22.31,Default,,0000,0000,0000,,a Diffie-Hellman. You could imagine that\Nthe server's public key is known in
Dialogue: 0,0:25:22.31,0:25:30.99,Default,,0000,0000,0000,,advance by the client and in this case\Nwe're not transporting it from the server,
Dialogue: 0,0:25:30.99,0:25:34.79,Default,,0000,0000,0000,,but if we're in this case we can use\Nsomething even better, which is kind of a
Dialogue: 0,0:25:34.79,0:25:40.17,Default,,0000,0000,0000,,nice property of the style of protocol. We\Ncan move that ephemeral static DH from the
Dialogue: 0,0:25:40.17,0:25:46.53,Default,,0000,0000,0000,,second message to the first and say Alice\Ncan actually do zero round-trip encryption
Dialogue: 0,0:25:46.53,0:25:50.50,Default,,0000,0000,0000,,to Bob or to the server's public key. So\Nshe does--the first message there is
Dialogue: 0,0:25:50.50,0:25:53.17,Default,,0000,0000,0000,,essentially what I earlier called the\Npublic key encryption. She's just
Dialogue: 0,0:25:53.17,0:25:57.05,Default,,0000,0000,0000,,encrypting straight away to Bob in her\Nfirst message, and that's something we can
Dialogue: 0,0:25:57.05,0:26:00.81,Default,,0000,0000,0000,,do with a Diffie-Hellman-based AKE that\Nyou can't do with say a signature-based
Dialogue: 0,0:26:00.81,0:26:04.75,Default,,0000,0000,0000,,AKE, because if Bob's static key is the\Nsigning key you would not be able to
Dialogue: 0,0:26:04.75,0:26:10.70,Default,,0000,0000,0000,,encrypt to it. So, you know, that's kind\Nof an example of some nice features we get
Dialogue: 0,0:26:10.70,0:26:15.81,Default,,0000,0000,0000,,from this style of AKE. We could continue\Nmaking things more complicated. So we
Dialogue: 0,0:26:15.81,0:26:19.55,Default,,0000,0000,0000,,could add not just zero round-trip\Nencryption, zero round-trip
Dialogue: 0,0:26:19.55,0:26:26.61,Default,,0000,0000,0000,,authentication, in this first flow by\Nhaving Alice send her identity and doing
Dialogue: 0,0:26:26.61,0:26:32.36,Default,,0000,0000,0000,,an additional Diffie-Hellman. And if we're\Ndoing that we should probably also refresh
Dialogue: 0,0:26:32.36,0:26:38.03,Default,,0000,0000,0000,,the authentication in the second message\Nwith this ES so that Bob's authentication
Dialogue: 0,0:26:38.03,0:26:42.59,Default,,0000,0000,0000,,of Alice is based on a fresh ephemeral\Ninstead of a long-term static key which
Dialogue: 0,0:26:42.59,0:26:46.59,Default,,0000,0000,0000,,could potentially be compromised. And if\Nwe do all this, we get actually--this is
Dialogue: 0,0:26:46.59,0:26:51.64,Default,,0000,0000,0000,,very close to WireGuard's pattern.\NWireGuard adds an additional feature that
Dialogue: 0,0:26:51.64,0:26:58.21,Default,,0000,0000,0000,,is a pre-shared symmetric key, and that's\Nsomething that, you know, we designed
Dialogue: 0,0:26:58.21,0:27:02.46,Default,,0000,0000,0000,,working with the WireGuard designer Jason\NDonenfeld that just allows you to add an
Dialogue: 0,0:27:02.46,0:27:09.08,Default,,0000,0000,0000,,extra key that gets mixed into everything.\NThe idea being that in a VPN context the
Dialogue: 0,0:27:09.08,0:27:13.39,Default,,0000,0000,0000,,two parties want to share a secret key,\Nthen your security will depend on either
Dialogue: 0,0:27:13.39,0:27:17.10,Default,,0000,0000,0000,,that or all these Diffie-Hellmans, and so\Neven if someone is able to break Diffie-
Dialogue: 0,0:27:17.10,0:27:23.13,Default,,0000,0000,0000,,Hellman through cryptanalysis or a quantum\Ncomputer, if you've shared a secret key
Dialogue: 0,0:27:23.13,0:27:27.32,Default,,0000,0000,0000,,through some other means they would not be\Nable to go back and break your traffic. So
Dialogue: 0,0:27:27.32,0:27:31.65,Default,,0000,0000,0000,,that's kind of just an example of how we\Ncan take this language that is a fairly
Dialogue: 0,0:27:31.65,0:27:35.81,Default,,0000,0000,0000,,simple language, extend it with new\Nfeatures, and we're interested in
Dialogue: 0,0:27:35.81,0:27:39.52,Default,,0000,0000,0000,,continuing that process and adding new\Nfeatures onto this. So, you know things
Dialogue: 0,0:27:39.52,0:27:42.97,Default,,0000,0000,0000,,that are there in the mix is trying to\Nfigure out how to add you know post
Dialogue: 0,0:27:42.97,0:27:46.56,Default,,0000,0000,0000,,quantum resistant algorithms to provide\Nhybrid forward secrecy onto these
Dialogue: 0,0:27:46.56,0:27:51.82,Default,,0000,0000,0000,,protocols, even going back and adding the\Nnotions of signatures into this. Because
Dialogue: 0,0:27:51.82,0:27:56.35,Default,,0000,0000,0000,,just like all this machinery we have is\Ngood for Diffie-Hellman based protocols,
Dialogue: 0,0:27:56.35,0:27:59.94,Default,,0000,0000,0000,,probably we can take all these notions of\Npatterns and of Noise protocols and how
Dialogue: 0,0:27:59.94,0:28:03.91,Default,,0000,0000,0000,,our approach to negotiation and\Napply them even to more conventional AKEs
Dialogue: 0,0:28:03.91,0:28:08.33,Default,,0000,0000,0000,,into other things as well. So that's sort\Nof our framework, you know it ends up
Dialogue: 0,0:28:08.33,0:28:12.34,Default,,0000,0000,0000,,looking kind of like this, with some, you\Nknow, a very simple negotiation layer
Dialogue: 0,0:28:12.34,0:28:16.92,Default,,0000,0000,0000,,switching to this very linear notion of a\Nfixed Noise protocol that you can assemble
Dialogue: 0,0:28:16.92,0:28:21.36,Default,,0000,0000,0000,,together by taking an abstract notion of\Npatterns and combining it with
Dialogue: 0,0:28:21.36,0:28:25.45,Default,,0000,0000,0000,,cryptography of your choice. You know\Nwe're still working on a lot of extensions
Dialogue: 0,0:28:25.45,0:28:29.68,Default,,0000,0000,0000,,for this, I'd love to get more people who\Nwanted to experiment with it or use it for
Dialogue: 0,0:28:29.68,0:28:34.07,Default,,0000,0000,0000,,anything. You can find more on our website\Nwhich has links to our mailing list as
Dialogue: 0,0:28:34.07,0:28:38.11,Default,,0000,0000,0000,,well. I'm happy to talk about it with\Nanyone. There's gonna be a WireGuard meet
Dialogue: 0,0:28:38.11,0:28:43.25,Default,,0000,0000,0000,,up tomorrow at 3 o'clock and I'll probably\Nbe milling around there as well, but if
Dialogue: 0,0:28:43.25,0:28:46.21,Default,,0000,0000,0000,,you want to talk to Jason and other\NWireGuard people and see how all this
Dialogue: 0,0:28:46.21,0:28:50.37,Default,,0000,0000,0000,,works in a concrete context, that would be\Nyou know a good way to learn more about
Dialogue: 0,0:28:50.37,0:28:55.41,Default,,0000,0000,0000,,it. Thank you for listening, and do I have\Ntime for questions? Maybe a brief amount
Dialogue: 0,0:28:55.41,0:29:08.40,Default,,0000,0000,0000,,of time.\N{\i1}applause{\i0}
Dialogue: 0,0:29:08.40,0:29:22.16,Default,,0000,0000,0000,,Herald-Angel: Microphone one.\NQuestion: So in the context of like multi-
Dialogue: 0,0:29:22.16,0:29:27.56,Default,,0000,0000,0000,,party systems, if you have like a person\Nthat has either multiple devices or
Dialogue: 0,0:29:27.56,0:29:34.83,Default,,0000,0000,0000,,multiple keys, is there anything that you\Ncould use inside Noise to work with that
Dialogue: 0,0:29:34.83,0:29:39.32,Default,,0000,0000,0000,,so that you have like messages being sent\Nto both identities, or would you recommend
Dialogue: 0,0:29:39.32,0:29:44.36,Default,,0000,0000,0000,,some doing something like that over like a\Ncentral registry and then linking the keys
Dialogue: 0,0:29:44.36,0:29:48.01,Default,,0000,0000,0000,,and having it sent to one and the devices\Nsharing with each other?
Dialogue: 0,0:29:48.01,0:29:50.95,Default,,0000,0000,0000,,Answer: Yeah that's a good question, I\Nmean I think that really gets into the
Dialogue: 0,0:29:50.95,0:29:54.03,Default,,0000,0000,0000,,scope of what like secure messaging\Nprotocols try to address, is when you have
Dialogue: 0,0:29:54.03,0:29:57.23,Default,,0000,0000,0000,,notions of groups and want to be\Nconsistent with the group and you want to
Dialogue: 0,0:29:57.23,0:29:59.81,Default,,0000,0000,0000,,talk to everyone in the group and maybe\Neveryone in the group isn't online at the
Dialogue: 0,0:29:59.81,0:30:03.54,Default,,0000,0000,0000,,same time, and I would say that's a\Ndifferent and more complex class of
Dialogue: 0,0:30:03.54,0:30:07.23,Default,,0000,0000,0000,,protocols that we're kind of just not\Ntrying to handle here. I think with Noise
Dialogue: 0,0:30:07.23,0:30:09.93,Default,,0000,0000,0000,,hopefully we're looking at something\Nthat's a very simple and well understood
Dialogue: 0,0:30:09.93,0:30:13.35,Default,,0000,0000,0000,,design space so we can build a lot of\Nmachinery around it, because it's so
Dialogue: 0,0:30:13.35,0:30:16.27,Default,,0000,0000,0000,,simple, and these other cases you're\Ntalking about I think just add a lot of
Dialogue: 0,0:30:16.27,0:30:20.09,Default,,0000,0000,0000,,complexity about how you would want to do\Nall those things. So we've kind of just
Dialogue: 0,0:30:20.09,0:30:25.80,Default,,0000,0000,0000,,chosen a narrow scope to make this\Nspecific problem a lot easier, I would
Dialogue: 0,0:30:25.80,0:30:29.33,Default,,0000,0000,0000,,say.\NQ: Okay, thanks!
Dialogue: 0,0:30:29.33,0:30:33.19,Default,,0000,0000,0000,,Q: Does Noise include any of the\Nratcheting or sort of key evolution over
Dialogue: 0,0:30:33.19,0:30:36.32,Default,,0000,0000,0000,,time properties that we've seen in\Nprotocols like this in the past?
Dialogue: 0,0:30:36.32,0:30:40.80,Default,,0000,0000,0000,,A: No, so Noise has a pretty simple model\Nof just you have like a handshake phase
Dialogue: 0,0:30:40.80,0:30:44.35,Default,,0000,0000,0000,,and a transport phase and the transport\Nphase just uses a key. Now we have added a
Dialogue: 0,0:30:44.35,0:30:49.28,Default,,0000,0000,0000,,notion of being able to like update this\Nkey by just replacing it with, like, you
Dialogue: 0,0:30:49.28,0:30:52.56,Default,,0000,0000,0000,,know, some of its own output, essentially.\NSo we can kind of roll it forward in a
Dialogue: 0,0:30:52.56,0:30:56.19,Default,,0000,0000,0000,,very simple way and we have an efficient\Nway of doing that, so you could do things
Dialogue: 0,0:30:56.19,0:30:59.09,Default,,0000,0000,0000,,like have every one of your messages\Nupdate the key to the next key, and then
Dialogue: 0,0:30:59.09,0:31:02.82,Default,,0000,0000,0000,,you have within the protocol forward\Nsecrecy. We don't try to do like more
Dialogue: 0,0:31:02.82,0:31:09.67,Default,,0000,0000,0000,,complicated things with Diffie-Hellman\Nratchets or anything like that,
Dialogue: 0,0:31:09.67,0:31:16.11,Default,,0000,0000,0000,,Q: When would be--what's the simple sales\Npitch for why to use Noise over TLS?
Dialogue: 0,0:31:16.11,0:31:20.83,Default,,0000,0000,0000,,A: You know, probably the simplest sales\Npitch would be like, if you really really
Dialogue: 0,0:31:20.83,0:31:24.72,Default,,0000,0000,0000,,want your protocol to just do like one\Nthing and you don't want to drag around a
Dialogue: 0,0:31:24.72,0:31:27.81,Default,,0000,0000,0000,,lot of code that does like a lot of\Nthings, you know like Noise will let you
Dialogue: 0,0:31:27.81,0:31:32.26,Default,,0000,0000,0000,,produce a very fine-tuned protocol that's\Na very small amount of code that just does
Dialogue: 0,0:31:32.26,0:31:35.10,Default,,0000,0000,0000,,like one thing pretty easily.
Dialogue: 0,0:31:35.10,0:31:37.15,Default,,0000,0000,0000,,Herald: That's it, thanks a lot
Dialogue: 0,0:31:37.15,0:31:41.82,Default,,0000,0000,0000,,Perrin: Thank you.\N{\i1}applause{\i0}
Dialogue: 0,0:31:41.82,0:31:47.62,Default,,0000,0000,0000,,{\i1}postroll music{\i0}
Dialogue: 0,0:31:47.62,0:32:03.00,Default,,0000,0000,0000,,subtitles created by c3subtitles.de\Nin the year 2018. Join, and help us!