0:00:00.000,0:00:15.534
preroll music
0:00:15.534,0:00:22.540
Herald: So, the next talk would be from[br]Trevor Perrin. He has been called -- wait
0:00:22.540,0:00:29.431
for it -- "Living Evangelist in[br]cryptographic protocol modernization"; he
0:00:29.431,0:00:34.809
helped out design some of the protocols[br]that your phone right now is executing and
0:00:34.809,0:00:42.719
sending to that AP over there. Like[br]signal, which gave him the award of the
0:00:42.719,0:00:46.449
Levchin Prize and the Noise Protocol[br]Framework, which is used by WhatsApp for
0:00:46.449,0:00:51.109
client-to-server communication and[br]WireGuard, the VPN from Jason Donenfeld,
0:00:51.109,0:00:56.231
which I don't see around here... Anyways,[br]the talk will focus on the Noise Protocol
0:00:56.231,0:01:02.010
Framework. What is the rationale behind it[br]and how to use it. Please hand of
0:01:02.010,0:01:09.250
applause.[br]applause
0:01:09.252,0:01:13.540
Trevor: All right, thank you everyone for[br]being here. My name is Trevor Perrin; I do
0:01:13.540,0:01:18.850
cryptography, consulting and secure[br]protocol design. I'm going to be talking
0:01:18.850,0:01:25.880
to you this evening about a project I've[br]been working on for the last few years in
0:01:25.880,0:01:32.979
the field of protocol design, which is the[br]Noise Protocol Framework. Noise is a
0:01:32.979,0:01:39.960
framework that helps you in creating[br]cryptographic secure channel protocols.
0:01:39.960,0:01:45.710
The sort of protocols it addresses is[br]things like TLS or SSH or IPSec, where you
0:01:45.710,0:01:49.249
have 2 parties -- they're online at the[br]same time, for example an internet client
0:01:49.249,0:01:53.189
talking to an internet server -- they're[br]going to want to exchange a few messages
0:01:53.189,0:01:57.569
to authenticate each other and then[br]establish some some shared secret keys,
0:01:57.569,0:02:01.899
which they can use for further[br]communication. Secure channel protocols
0:02:01.899,0:02:05.920
like this are the the workhorses of[br]practical cryptography; most the time when
0:02:05.920,0:02:11.530
crypto is used, it's within the context of[br]some sort of secure channel protocol.
0:02:11.530,0:02:14.810
There's other sorts of protocols, like[br]secure messaging and cryptocurrency and
0:02:14.810,0:02:19.070
all sorts of other things, but Noise is[br]specifically focused on secure channels,
0:02:19.070,0:02:25.050
so that's what I'm going to be talking[br]about in this talk. And probably a lot of
0:02:25.050,0:02:28.580
people, just kind of off the bat, have a[br]reaction to that of being like "Well, why?
0:02:28.580,0:02:33.270
We we have secure channel protocols[br]already: We have TLS; we have SSH; we have
0:02:33.270,0:02:38.020
IPSec; and these things have been a huge[br]amount of effort to design over the last
0:02:38.020,0:02:42.270
20+ years. We've been bolting features[br]onto them and picking bugs out of them.
0:02:42.270,0:02:46.850
Why would we want to start down that road[br]again and build different and newer
0:02:46.850,0:02:51.430
protocols?" And I think, that's a very[br]legitimate question and source of
0:02:51.430,0:02:58.650
skepticism. And my feelings about this is[br]as follows: It's that, what a secure
0:02:58.650,0:03:02.590
channel protocol does is really a very[br]simple thing; it just sends a couple
0:03:02.590,0:03:08.210
messages -- 2 or 3, maybe 4 -- sets up a[br]secure channel. So, these protocols really
0:03:08.210,0:03:11.900
should be pretty simple; they should be[br]simple to implement; they should be simple
0:03:11.900,0:03:14.430
to design; and I think, a lot of the ones[br]that we find ourselves with -- the
0:03:14.430,0:03:18.900
mainstream ones -- for what they do, for[br]what they actually accomplish, I think,
0:03:18.900,0:03:24.820
they're probably often too complex, too[br]complicated and too difficult to extend.
0:03:24.820,0:03:29.870
And I think, we need to extend them; we're[br]going to need to keep adding features and
0:03:29.870,0:03:33.070
extending them into new areas and with new[br]types of cryptography. So, it's important
0:03:33.070,0:03:36.510
to have good frameworks and good ways of[br]doing this. I think, this is an area where
0:03:36.510,0:03:42.300
we need a lot of room for improvement. And[br]so, Noise is a somewhat, I guess,
0:03:42.300,0:03:46.270
ambitious effort in that direction. It's[br]ambitious in the sense that I love to get
0:03:46.270,0:03:51.180
it to a point where people could use Noise[br]for building all sorts of new and future
0:03:51.180,0:03:55.620
protocols. I'll be the first to admit that[br]it's a work in progress; it hasn't
0:03:55.620,0:03:59.520
achieved all of its ambitions yet; its[br]achieved some of them. But we're still
0:03:59.520,0:04:05.441
working to extend it and if, by the end of[br]this talk, I have then convinced people in
0:04:05.441,0:04:09.920
the next 20 minutes to try to use Noise[br]for all your new protocol design...
0:04:09.920,0:04:14.740
Challenges, that's going to be okay. What[br]I mainly want to get across is, just
0:04:14.740,0:04:18.089
something about how these protocols work,[br]the components that go into them, the
0:04:18.089,0:04:21.709
design space they're a part of, because I[br]think, these protocols are so essential to
0:04:21.709,0:04:26.780
computer security, it's helpful for[br]everyone to understand, how they work and
0:04:26.780,0:04:31.180
what they do, and not just think of them[br]as kind of black magic that only a few
0:04:31.180,0:04:37.290
wizards can ever touch. So, to understand[br]these sorts of protocols, secure channel
0:04:37.290,0:04:41.010
protocols, I'm going to want to start by[br]giving just some background on the type of
0:04:41.010,0:04:46.190
cryptography that's involved in them: And[br]the main cryptographic construct in any
0:04:46.190,0:04:49.680
secure channel protocol is going to be[br]what cryptographers call an "Authenticated
0:04:49.680,0:04:54.680
Key Exchange" or "AKE protocol" . And an[br]AKE is just a sequence of messages that go
0:04:54.680,0:04:58.690
back and forth between 2 parties, between[br]Alice and Bob, so they can authenticate
0:04:58.690,0:05:02.210
each other and then, at the end of that,[br]have a shared secret key that they know
0:05:02.210,0:05:08.040
they share with their authenticated party.[br]These protocols, these AKE protocols, can
0:05:08.040,0:05:11.300
have different properties: All the ones[br]we're going to look at have forward
0:05:11.300,0:05:15.010
secrecy; they might have mutual[br]authentication of both parties; they might
0:05:15.010,0:05:19.560
have one-way authentication; how they[br]handled identity information might be
0:05:19.560,0:05:24.540
different in different AKEs, so maybe in[br]some AKEs, both parties start off knowing
0:05:24.540,0:05:28.720
each other's identity and public key and[br]some AKEs will have to transmit this
0:05:28.720,0:05:33.600
information. In other AKEs, they might[br]want to transmit this information, but do
0:05:33.600,0:05:38.410
it only after the other party has[br]negotiated some encryption, so that their
0:05:38.410,0:05:43.139
identity information is encrypted, is[br]protected on the wire. So, there are
0:05:43.139,0:05:46.010
different properties of how these things[br]work; there are different types of crypto
0:05:46.010,0:05:51.540
we can use to design AKEs that have these[br]properties. And I want to expand on this a
0:05:51.540,0:05:57.100
little bit, because most AKEs that people[br]have experience with, the mainstream ones,
0:05:57.100,0:06:03.020
all do their AKE in kind of the same way:[br]They do a AKE using signatures for
0:06:03.020,0:06:08.389
authenticaton and Diffie-Hellman for a key[br]agreement. But in the last... that's a 10
0:06:08.389,0:06:12.020
or so... 10+ years, there has been a[br]growing interest in doing AKEs that are
0:06:12.020,0:06:17.020
just purely based on Diffie-Hellman key[br]agreement without signatures, and there
0:06:17.020,0:06:22.060
has been a bunch of papers that analyze[br]security models and do proofs for this
0:06:22.060,0:06:27.100
sort of AKE. People have put this into[br]practice in things like Tor and Tor key
0:06:27.100,0:06:32.570
agreement by Ian Goldberg and a number of[br]designs by Daniel Bernstein and others,
0:06:32.570,0:06:37.850
like SALT cryptoboxes, CurveCP, etc. So,[br]there has been a kind of interest in doing
0:06:37.850,0:06:42.420
this and Noise is particularly trying to[br]take this idea and run with it. So, I want
0:06:42.420,0:06:47.850
to explain a little bit more about how[br]these sorts of Diffie-Hellman-centric AKEs
0:06:47.850,0:06:53.250
work. And so, we'll start by looking at[br]just the key exchange part of an AKE and
0:06:53.250,0:06:56.760
this is part is going to be sort of[br]generic to all the protocols, all the AKE
0:06:56.760,0:07:01.199
protocols, we talked about, which is just[br]going to be an unauthenticated dDffie-
0:07:01.199,0:07:05.750
Hellman key exchange. The way you think[br]about Diffie-Hellman is that there's Alice
0:07:05.750,0:07:09.290
and Bob: They each have a key pair, a[br]private key and a public key; they're each
0:07:09.290,0:07:12.610
going to exchange their public key with[br]the others; then they're going to take
0:07:12.610,0:07:15.380
their public key, they're going to take[br]their private key; they're going to
0:07:15.380,0:07:20.800
combine these two and get a shared secret,[br]which is the same for both parties. So,
0:07:20.800,0:07:25.240
that's just a basic Diffie-Hellman to[br]add... to key agreement, to turn it into
0:07:25.240,0:07:30.560
an authenticated key exchange, you[br]exchange, we're going to add
0:07:30.560,0:07:34.590
authentication. And so, we can do that by[br]adding signatures in a very conventional
0:07:34.590,0:07:38.990
way: Let's say both parties know each[br]other's public keys, so Bob just has to
0:07:38.990,0:07:41.990
send an encrypted signature to Alice;[br]Alice responds with an encrypted
0:07:41.990,0:07:47.770
signature; now we have an AKE. And this[br]design is called Sigma, it's essentially
0:07:47.770,0:07:51.980
Sigma, and it's essentially how something[br]like TLS 1.3 works, where you first get a
0:07:51.980,0:07:57.870
secret key, then send signatures as[br]authenticators under the encryption. And
0:07:57.870,0:08:02.150
there's nothing wrong with this design,[br]it's a good design. We can look at that
0:08:02.150,0:08:06.590
schematically by imagining that what's[br]happening if we don't consider the message
0:08:06.590,0:08:10.650
sequences: Alice and Bob are each signing[br]the key agreement, so that once they get a
0:08:10.650,0:08:14.960
shared key, they know that the other party[br]agrees with this shared key by verifying
0:08:14.960,0:08:20.470
the signature. If we want to do an AKE[br]that's entirely signature-based, we're
0:08:20.470,0:08:23.880
going to have to replace these signatures[br]with some sort of Diffie-Hellman, while
0:08:23.880,0:08:28.451
still getting that same confidence and[br]that same guarantee, that the other party
0:08:28.451,0:08:35.330
agrees on the ultimate, final, shared[br]secret key we get out of this AKE. So, the
0:08:35.330,0:08:39.708
way we can do that is, we can say "Well,[br]these these long-lived key pairs that
0:08:39.708,0:08:42.429
people have, we'll call them static key[br]pairs; they're going to be Diffie-Hellman
0:08:42.429,0:08:48.290
key pairs instead of signature key pairs;[br]and each party is going, to in addition to
0:08:48.290,0:08:52.569
doing an ephemeral, do ephemeral DH for[br]forward secrecy, do an ephemeral DH to the
0:08:52.569,0:08:56.110
other party's static key for[br]authentication, and then hash all these
0:08:56.110,0:09:02.269
DHs together to get a final key. And the[br]reason why this convinces each party that
0:09:02.269,0:09:07.339
the other party has agreed to the final[br]key is, because this final key is a hash
0:09:07.339,0:09:12.899
that includes the DH of the authentication[br]DH of their ephemeral key, the other
0:09:12.899,0:09:16.120
party's static private key -- the only[br]other party who knows the output of that
0:09:16.120,0:09:21.790
DH is the other party -- thus, if we do[br]anything with the final shared secret key,
0:09:21.790,0:09:25.269
like receive any encrypted message from[br]it, we know that key can only have been
0:09:25.269,0:09:31.589
calculated by the correct counterparty.[br]So, we're accomplishing authentication by
0:09:31.589,0:09:37.390
using DH instead of signatures here and so[br]this is a... it's a well understood thing,
0:09:37.390,0:09:41.040
but I wanted to kind of just touch on that[br]before we talk about... where I dive into
0:09:41.040,0:09:44.230
the history of Noise. And the history of[br]Noise is that a few years ago, I was
0:09:44.230,0:09:48.920
reading a lot of these papers that talked,[br]Diffie-Hellman-based key exchange, and
0:09:48.920,0:09:53.350
looking at a number of these designs where[br]people were doing Diffie-Hellman-based key
0:09:53.350,0:09:56.720
exchange and I thought, these were cool[br]designs. I thought, they were elegant; I
0:09:56.720,0:10:01.519
thought they were efficient. But every[br]time someone did a new Diffie-Hellman-
0:10:01.519,0:10:06.790
based thing, like nTor or salt or CurveCP[br]or OPTLS, they would sort of start from
0:10:06.790,0:10:10.889
scratch and they'd say "Okay, how are we[br]going to do key derivation? How are we
0:10:10.889,0:10:14.209
going to do transcript hashing? How are we[br]going to do key confirmation?" If they
0:10:14.209,0:10:17.420
were doing security analysis, they'd[br]create their own security model; they'd
0:10:17.420,0:10:21.579
write their own Gap DH ROM-based[br]security proof that's pretty much the same
0:10:21.579,0:10:24.699
as everyone else's security proof, but[br]it's still a lot of work. So, there was a
0:10:24.699,0:10:30.040
lot of reused or sort of repeated work[br]being done to build this style of protocol
0:10:30.040,0:10:35.399
and so, the the motivating idea for Noise[br]was, whether we could capture that work
0:10:35.399,0:10:38.410
into a framework that just provided you[br]some common elements so people could
0:10:38.410,0:10:42.670
easily combine those elements together and[br]create a wide range of different protocols
0:10:42.670,0:10:47.470
in this style. And so, I started working[br]on ways of kind of connecting protocol
0:10:47.470,0:10:53.230
pieces together. Eventually, I talked to[br]Mike Hamburg who's working on something
0:10:53.230,0:10:56.779
else -- this Strobe Protocol Framework[br]that was kind of based on sponge-based
0:10:56.779,0:11:02.510
cryptography -- and we kind of took some[br]ideas from that. With with all those ideas
0:11:02.510,0:11:05.910
we were able to come up with I think a[br]pretty good system for describing a wide
0:11:05.910,0:11:09.459
range of protocols just by taking a[br]Diffie-Hellman operation and some simple
0:11:09.459,0:11:15.519
other cryptography and combining them in a[br]bunch of different ways. That core design
0:11:15.519,0:11:22.509
of noise is what we arrived at by 2015 and[br]it's been stable since then. We know noise
0:11:22.509,0:11:25.450
is still a work in progress because we're[br]trying to extend it and add new forms of
0:11:25.450,0:11:30.740
cryptography and build more things around[br]this core but we do have a pretty good
0:11:30.740,0:11:34.910
core at this point. We've built a small[br]community around it with a mailing list,
0:11:34.910,0:11:39.750
website, specifications, test suites, open[br]source libraries in a bunch of common
0:11:39.750,0:11:45.149
languages and we also have a couple users:[br]Noise Based Protocol is used by WhatsApp
0:11:45.149,0:11:51.269
for client-to-server communication from[br]the app to the server and WireGuard which
0:11:51.269,0:11:56.790
is a next generation VPN tunnel project by[br]Jason Donenfeld, it also uses a a noise
0:11:56.790,0:12:01.379
based secure channel protocol. We're also[br]getting interest from some some other
0:12:01.379,0:12:05.429
directions, from people doing like[br]Internet of Things, embedded systems,
0:12:05.429,0:12:11.129
anonymity network type systems, the[br]Lightning Network proposal for Bitcoin
0:12:11.129,0:12:16.100
which will incorporate a Noise Based[br]Protocol. So I think we're getting
0:12:16.100,0:12:21.199
interest from people who potentially want[br]a customized secure channel protocol for a
0:12:21.199,0:12:25.480
new area they're working in but don't want[br]to drag in a lot of extraneous complexity.
0:12:25.480,0:12:29.670
They want something simple and efficient[br]that addresses their use case. That's what
0:12:29.670,0:12:34.830
I think is the sweet spot for Noise so[br]far. For the rest of this talk, what I
0:12:34.830,0:12:40.550
want to do is talk about what the[br]components of a secure channel protocol
0:12:40.550,0:12:44.989
are, why I think it's a good idea to have[br]a framework that addresses the design of
0:12:44.989,0:12:50.209
these things, and then fill in the details[br]on what the Noise framework actually is.
0:12:50.209,0:12:54.439
Secure channel protocols all have kind of[br]the same structure: they start with a
0:12:54.439,0:12:58.029
handshake phase where parties send a few[br]messages back and forth to get a shared
0:12:58.029,0:13:03.040
secret key, then they use this shared[br]secret key for the transport phase of just
0:13:03.040,0:13:08.429
doing bulk encryption. The transport phase[br]is a simple thing, it's pretty easy to
0:13:08.429,0:13:13.369
just use shared keys to encrypt data back[br]and forth, so I'm not going to say a lot
0:13:13.369,0:13:18.420
more about it. The handshake phase is[br]where all the excitement and the
0:13:18.420,0:13:25.700
interesting things are. Of course, the[br]main component of a secure protocol, a
0:13:25.700,0:13:28.230
secure channel, is the handshake. It's[br]going to be just an authenticated key
0:13:28.230,0:13:33.759
exchange, an AKE of some sort, but a lot[br]of secure channel protocols will also have
0:13:33.759,0:13:40.679
some sort of negotiation that happens[br]logically before the rest of this that
0:13:40.679,0:13:44.860
determines the type of AKE, and the[br]parameters of the AKE, and the parameters
0:13:44.860,0:13:49.759
of the encryption such as which cipher to[br]use. You can think of this negotiation
0:13:49.759,0:13:53.670
happening logically before everything else[br]because it determines everything else, but
0:13:53.670,0:13:58.480
in practice, for efficiency, the[br]negotiation of the AKE are usually
0:13:58.480,0:14:03.239
overlaid or woven together a little bit.[br]So I might send an initial message from
0:14:03.239,0:14:08.009
the client that says "I'm speculatively[br]executing this AKE protocol but I'm
0:14:08.009,0:14:11.439
willing to execute these other protocols[br]and I'm willing to use these ciphers for
0:14:11.439,0:14:15.180
the transport phase", and then the server[br]can respond by saying "I want you to do a
0:14:15.180,0:14:19.519
different AKE, I want you to use these[br]ciphers at the end of it". So you have
0:14:19.519,0:14:23.730
these negotiation in AKE happening kind of[br]simultaneously, which is one of the
0:14:23.730,0:14:28.879
reasons these protocols are a little[br]complicated to think about. But anyways,
0:14:28.879,0:14:33.800
if we were building a single secure[br]channel protocol, we would be trying to
0:14:33.800,0:14:37.630
fill in these elements. We would be[br]saying, okay, what AKE do we want to use,
0:14:37.630,0:14:40.930
how do we want to instantiate the[br]cryptography within them, and then how do
0:14:40.930,0:14:46.119
we want to design a negotiation structure[br]that can select one of these different
0:14:46.119,0:14:52.399
things, and how do we assemble all that[br]together. We're not trying to build a a
0:14:52.399,0:14:57.300
single AKE protocol, we're trying to build[br]a framework for building AKE protocols, so
0:14:57.300,0:15:04.949
we're doing something a little bit more[br]confusing and the reason is pretty simple.
0:15:04.949,0:15:11.480
If you're trying to build a single[br]protocol, you have a hard decision, and a
0:15:11.480,0:15:15.869
difficult trade-off to manage between[br]adding features into this protocol and
0:15:15.869,0:15:19.769
keeping it simple. Because the more[br]features you add, the more negotiations
0:15:19.769,0:15:25.230
you have, the more different branches your[br]protocol can take, the more complexity
0:15:25.230,0:15:29.179
every implementer has to deal with, the[br]more attack service you have, because if
0:15:29.179,0:15:33.119
there's any bug in any of these features[br]that an attacker can navigate to, that's
0:15:33.119,0:15:38.670
potentially a problem. We want to work on[br]things that have a lot of features that
0:15:38.670,0:15:42.790
address a lot of cases, but we also want[br]to keep things simple. So if we think of
0:15:42.790,0:15:46.850
ourselves as creating not just a single[br]protocol, but a framework of protocols, we
0:15:46.850,0:15:50.670
can kind of manage that tension a little[br]bit better by imagining that we have all
0:15:50.670,0:15:55.269
these features and all these capabilities[br]off to the side, and a library or a tool
0:15:55.269,0:15:58.329
somewhere. And when we build a concrete[br]protocol, we're just going to select a
0:15:58.329,0:16:01.879
bunch of features and hopefully have some[br]simple combination rules for putting them
0:16:01.879,0:16:07.369
together and to get a very customized[br]protocol that does exactly what we want
0:16:07.369,0:16:12.759
and not anything that we we don't want.[br]That means that working with Noise is
0:16:12.759,0:16:18.889
different from working with something like[br]TLS because with most cryptographic
0:16:18.889,0:16:22.589
protocols, you probably can just take a[br]TLS library, point it at another TLS
0:16:22.589,0:16:26.470
library, and they'll figure out how to[br]connect. They'll do negotiations, fall
0:16:26.470,0:16:31.059
backs, retries, ... and they'll find the[br]intersection of cipher suites and
0:16:31.059,0:16:35.809
versions, etc. that they support, and will[br]connect to each other. That's a feat of
0:16:35.809,0:16:39.069
engineering, but there's a lot of[br]complexity that lies behind that, and
0:16:39.069,0:16:44.690
there's a lot of opacity in understanding[br]what you're really getting. To use Noise,
0:16:44.690,0:16:49.230
on the other hand, you have to think in[br]advance about what you want to use, what
0:16:49.230,0:16:51.879
AKEs you want to use, what cryptography[br]you're gonna get... You're going to choose
0:16:51.879,0:16:55.480
all these things. You're going to have to[br]understand why you want the sequence of
0:16:55.480,0:16:58.160
messages, you're going to put them[br]together, and you're going to end up with
0:16:58.160,0:17:03.410
something that very much addresses your[br]use case, hopefully, but is not going to
0:17:03.410,0:17:07.459
have a lot of extraneous complexity. So[br]that's a different way of working with
0:17:07.459,0:17:11.730
protocols and thinking about protocols,[br]but I think it's the right answer for a
0:17:11.730,0:17:16.670
lot of cases. At least that's our goal. We[br]want to build as a framework where we can
0:17:16.670,0:17:25.079
choose a bunch of things, combine them[br]together, and then end up with a wide
0:17:25.079,0:17:29.240
range of different protocols. But to get[br]there is a little bit complicated. To get
0:17:29.240,0:17:33.779
there, we're gonna have to take our[br]structure of a secure channel protocol and
0:17:33.779,0:17:37.309
break it up into some different elements[br]so that we can mix and match these
0:17:37.309,0:17:42.169
elements and get different protocols.[br]We're gonna break it up in a couple
0:17:42.169,0:17:46.240
different ways. The first way we're going[br]to do that is we're gonna separate out all
0:17:46.240,0:17:52.471
the points in the protocol where runtime[br]decisions are made from all the points of
0:17:52.471,0:17:57.040
the protocol, we can think of, it's just[br]straight line, linear code. And the reason
0:17:57.040,0:18:01.700
why is because, if we have straight line,[br]just linear cryptographic code that just
0:18:01.700,0:18:06.500
does one thing after another and sends one[br]message after another, and does nothing
0:18:06.500,0:18:10.960
else, except maybe erroring if it detects,[br]say, it detects cryptographic
0:18:10.960,0:18:14.500
authentication failure. We have code like[br]that. It's very easy to test, it's easy to
0:18:14.500,0:18:19.059
think about, it's easy to design things[br]around because it just does one thing in a
0:18:19.059,0:18:23.549
sequence. And so that's… Noise is very[br]much going to be about forcing people to
0:18:23.549,0:18:29.880
use straight line code with no branches as[br]much as possible. Our idea of being a
0:18:29.880,0:18:33.370
framework hopefully helps with that[br]because we've moved a lot of decisions
0:18:33.370,0:18:37.820
that might have been runtime decisions,[br]negotiation decision in a full protocol,
0:18:37.820,0:18:41.951
we're moving them to, hopefully, design[br]time decisions within a framework. But we
0:18:41.951,0:18:45.510
might still have some negotiation[br]decisions remaining about, like, which
0:18:45.510,0:18:51.081
cipher to use or, you know like, if we try[br]to do a zero round-trip encryption, we
0:18:51.081,0:18:53.840
might have to fall back to something else.[br]So there might be some decisions that
0:18:53.840,0:18:57.200
remain. We're going to try to compress all[br]those decisions into kind of one, and say
0:18:57.200,0:19:01.360
there's only one point in this framework[br]where runtime decisions get made, which is
0:19:01.360,0:19:05.789
selecting what we're going to call a Noise[br]protocol. And the Noise… And this notion
0:19:05.789,0:19:08.950
of the Noise protocol is going to[br]encapsulate everything else that happens.
0:19:08.950,0:19:13.169
It's just a linear sequence of code, it's[br]going to be the AKE plus whatever
0:19:13.169,0:19:18.100
transport encryption happens after that.[br]So with this framework we've hopefully…
0:19:18.100,0:19:20.809
You know, we hate decision-making at[br]runtime but we're going to compress it
0:19:20.809,0:19:24.120
down to one if we have to and then call[br]everything else just a straight line
0:19:24.120,0:19:28.220
sequence of code. The next thing we're[br]going to do to make this framework sort of
0:19:28.220,0:19:33.830
manageable and break it down, is zoom in[br]on this notion of the Noise protocol and
0:19:33.830,0:19:36.920
break that into pieces too. And so we're[br]going to view that as a combination of,
0:19:36.920,0:19:41.679
what we call a handshake pattern, with[br]some actual crypto algorithms. And a
0:19:41.679,0:19:46.299
handshake pattern is going to be like an[br]abstract notion of an AKE, so it's going
0:19:46.299,0:19:50.730
to be an AKE protocol that just says: do[br]some sort of Diffie-Hellman, encrypt this
0:19:50.730,0:19:54.470
in some way, hash this in some way, but[br]it's not going to tell you what crypto to
0:19:54.470,0:19:58.140
use. You're going to plug in crypto, and[br]it's that combination of things is gonna
0:19:58.140,0:20:03.840
give you a concrete Noise protocol, which[br]is in kind of an implementable unit of
0:20:03.840,0:20:09.851
this framework. So, the whole framework[br]then kind of ends up being like this: the
0:20:09.851,0:20:13.380
sort of core central piece is this notion[br]of the Noise protocol which is, what we've
0:20:13.380,0:20:17.420
probably spent most of our engineering[br]effort on, where we combine some abstract
0:20:17.420,0:20:22.250
notion of an AKE, a handshake pattern,[br]with some crypto to get a Noise protocol.
0:20:22.250,0:20:25.010
We're going to imagine a negotiation layer[br]that can really just make one decision
0:20:25.010,0:20:29.350
which is: does the server want to switch[br]from the initial noise protocol to a
0:20:29.350,0:20:31.950
different one. So we're only going to[br]allow one transition, just to make things
0:20:31.950,0:20:37.210
really simple. And then the only other[br]layer we're going to add, is this notion
0:20:37.210,0:20:41.960
of an encoding layer which is that, we[br]might want to send our messages over TCP,
0:20:41.960,0:20:46.070
in which case we'd have to add length[br]fields. Or we might send them over HTTP,
0:20:46.070,0:20:49.309
in which case we'll have to encode them as[br]HTTP requests. So we have this kind of
0:20:49.309,0:20:52.580
abstract notion of our protocol, but we[br]might need to add a little bit more
0:20:52.580,0:20:56.990
encoding to actually fit it into a[br]particular context. And that's, you know,
0:20:56.990,0:21:02.080
that's gonna be kind of just the whole way[br]we build secure channel protocols. So, the
0:21:02.080,0:21:09.660
main thing that you're going to interact[br]with, is, or the kind of central piece of
0:21:09.660,0:21:13.649
this is the Noise protocol and the main[br]way that you're going to interact with
0:21:13.649,0:21:19.170
Noise protocols and design them as a user,[br]is by just giving them names. And so we
0:21:19.170,0:21:22.960
have this notion of, you can precisely[br]name a Noise protocol and then that just,
0:21:22.960,0:21:30.190
kind of like, defines the entire protocol.[br]So here we have a Noise protocol that's,
0:21:30.190,0:21:35.470
you know, this is a concrete implementable[br]thing: it uses the NX pattern which, I
0:21:35.470,0:21:39.730
haven't explained what that means, but it[br]also combines that pattern that AKE notion
0:21:39.730,0:21:44.009
with Curve25519 for Diffie-Hellman, with[br]AES-GCM for encryption, with SHA-256 for
0:21:44.009,0:21:51.920
hashing, we can plug in or out different[br]options of any one of these things. So we
0:21:51.920,0:21:57.100
could have different patterns, different[br]ciphers, etc. to get a Noise protocol and
0:21:57.100,0:22:01.120
then the specification, and most of our[br]Noise libraries can take this name and
0:22:01.120,0:22:05.009
will just automatically know what to do.[br]They'll synthesize a whole protocol around
0:22:05.009,0:22:11.110
this, just with some some pretty simple[br]rules. And, so the pattern notion and the
0:22:11.110,0:22:15.850
way we're naming patterns… There is a[br]naming convention here but I think more
0:22:15.850,0:22:18.480
important than understanding the naming[br]convention, is understanding this simple
0:22:18.480,0:22:23.860
language that it's built on top of. And,[br]so we're gonna have a sort of simple
0:22:23.860,0:22:30.350
language for describing a range of sort of[br]abstract AKE patterns based on, based on
0:22:30.350,0:22:35.509
this set of concepts, based on just saying[br]we have Alice and Bob, they each might
0:22:35.509,0:22:39.299
have a static key and they might have an[br]ephemeral key, and the only things we're
0:22:39.299,0:22:43.899
gonna allow them to do, as part of their[br]AKE protocol, is send their public keys
0:22:43.899,0:22:47.570
back and forth and do Diffie-Hellman[br]operations and the only Diffie-Hellman
0:22:47.570,0:22:52.350
operations they can do are, you know,[br]these four involving some combination of
0:22:52.350,0:22:56.110
their keys which you can just read from[br]left to right, so they can do this static-
0:22:56.110,0:23:00.509
static Diffie-Hellman, they can do the[br]Alice's static to Bob's ephemeral which
0:23:00.509,0:23:04.570
sort of authenticates Alice, you can do[br]Alice's ephemeral to Bob's static which
0:23:04.570,0:23:09.679
authenticates Bob, or they can do this EE[br]Diffie-Hellman for forward secrecy. So
0:23:09.679,0:23:13.100
we're going to allow them just to combine[br]these units in different ways and get a
0:23:13.100,0:23:18.502
wide range of different AKEs out of this.[br]So let's start demonstrate... I'm going to
0:23:18.502,0:23:20.649
demonstrate a bunch of patterns and kind[br]of go through them quickly, and let's
0:23:20.649,0:23:23.710
start with something that's very simple,[br]which is just a public key encryption. So
0:23:23.710,0:23:27.790
this AKE pattern doesn't even describe an[br]interactive protocol, it's just Alice
0:23:27.790,0:23:32.930
encrypting a message to Bob. And so, our[br]little language here, we're going to add
0:23:32.930,0:23:38.120
three dots to indicate when Alice has[br]prior knowledge of something before the
0:23:38.120,0:23:42.879
protocol starts. So this is a protocol[br]where Alice knows Bob's public key at the
0:23:42.879,0:23:45.820
outset. She's going to send one message[br]which is an ephemeral public key she
0:23:45.820,0:23:49.950
chooses. She's going to do an ES,[br]Ephemeral Static Diffie-Hellman, to
0:23:49.950,0:23:54.289
authenticate Bob and that's going to give[br]her public key encryption because then
0:23:54.289,0:23:57.789
she's going to have keys that she can use[br]for sort of the transport phase encryption
0:23:57.789,0:24:01.789
of the message she's sending to Bob. So[br]that's just--you could think of this as in
0:24:01.789,0:24:06.039
like an ECIES or an ephemeral static[br]public key encryption. We could make this
0:24:06.039,0:24:09.779
more complicated by saying both parties[br]know their public keys and we want Alice
0:24:09.779,0:24:13.220
to authenticate to Bob, and now we just[br]throw in the static-static encryption and
0:24:13.220,0:24:17.830
now we have Alice authenticating herself[br]to Bob. We could make another step in
0:24:17.830,0:24:21.929
complexity and say we want Alice to[br]authenticate herself to Bob and also send
0:24:21.929,0:24:25.809
her public key to Bob, and she might also[br]have to send certificates and things like
0:24:25.809,0:24:29.649
that to convince Bob her public key is to[br]be trusted. That can go in the transport
0:24:29.649,0:24:34.389
payload, but the point is now we've taken[br]Alice's public key and say instead of it
0:24:34.389,0:24:39.750
being prior knowledge of Bob's, it's[br]transported in the message itself, and
0:24:39.750,0:24:45.140
we're going to have this additional rule[br]which is that any time we send the static
0:24:45.140,0:24:48.450
public key we're gonna encrypt it with all[br]the other keys that have come before. So
0:24:48.450,0:24:53.250
in this case Alice's static public key is[br]encrypted with the output of the ephemeral
0:24:53.250,0:24:57.070
static DH, which provides some identity[br]hiding, so someone looking at the wire
0:24:57.070,0:25:03.720
doesn't know who Alice's is, even though[br]Bob knows. We can move on to interactive
0:25:03.720,0:25:07.429
protocols and look at unauthenticated[br]Diffie-Hellman, just looks like this: an
0:25:07.429,0:25:12.170
exchange of the ephemeral public keys and[br]a Diffie-Hellman. You could add server
0:25:12.170,0:25:17.000
authentication to that, where the server[br]just sends its static public key and does
0:25:17.000,0:25:22.309
a Diffie-Hellman. You could imagine that[br]the server's public key is known in
0:25:22.309,0:25:30.990
advance by the client and in this case[br]we're not transporting it from the server,
0:25:30.990,0:25:34.789
but if we're in this case we can use[br]something even better, which is kind of a
0:25:34.789,0:25:40.170
nice property of the style of protocol. We[br]can move that ephemeral static DH from the
0:25:40.170,0:25:46.529
second message to the first and say Alice[br]can actually do zero round-trip encryption
0:25:46.529,0:25:50.500
to Bob or to the server's public key. So[br]she does--the first message there is
0:25:50.500,0:25:53.169
essentially what I earlier called the[br]public key encryption. She's just
0:25:53.169,0:25:57.049
encrypting straight away to Bob in her[br]first message, and that's something we can
0:25:57.049,0:26:00.809
do with a Diffie-Hellman-based AKE that[br]you can't do with say a signature-based
0:26:00.809,0:26:04.750
AKE, because if Bob's static key is the[br]signing key you would not be able to
0:26:04.750,0:26:10.700
encrypt to it. So, you know, that's kind[br]of an example of some nice features we get
0:26:10.700,0:26:15.809
from this style of AKE. We could continue[br]making things more complicated. So we
0:26:15.809,0:26:19.549
could add not just zero round-trip[br]encryption, zero round-trip
0:26:19.549,0:26:26.610
authentication, in this first flow by[br]having Alice send her identity and doing
0:26:26.610,0:26:32.360
an additional Diffie-Hellman. And if we're[br]doing that we should probably also refresh
0:26:32.360,0:26:38.029
the authentication in the second message[br]with this ES so that Bob's authentication
0:26:38.029,0:26:42.590
of Alice is based on a fresh ephemeral[br]instead of a long-term static key which
0:26:42.590,0:26:46.590
could potentially be compromised. And if[br]we do all this, we get actually--this is
0:26:46.590,0:26:51.639
very close to WireGuard's pattern.[br]WireGuard adds an additional feature that
0:26:51.639,0:26:58.210
is a pre-shared symmetric key, and that's[br]something that, you know, we designed
0:26:58.210,0:27:02.460
working with the WireGuard designer Jason[br]Donenfeld that just allows you to add an
0:27:02.460,0:27:09.080
extra key that gets mixed into everything.[br]The idea being that in a VPN context the
0:27:09.080,0:27:13.389
two parties want to share a secret key,[br]then your security will depend on either
0:27:13.389,0:27:17.100
that or all these Diffie-Hellmans, and so[br]even if someone is able to break Diffie-
0:27:17.100,0:27:23.129
Hellman through cryptanalysis or a quantum[br]computer, if you've shared a secret key
0:27:23.129,0:27:27.320
through some other means they would not be[br]able to go back and break your traffic. So
0:27:27.320,0:27:31.649
that's kind of just an example of how we[br]can take this language that is a fairly
0:27:31.649,0:27:35.809
simple language, extend it with new[br]features, and we're interested in
0:27:35.809,0:27:39.519
continuing that process and adding new[br]features onto this. So, you know things
0:27:39.519,0:27:42.970
that are there in the mix is trying to[br]figure out how to add you know post
0:27:42.970,0:27:46.559
quantum resistant algorithms to provide[br]hybrid forward secrecy onto these
0:27:46.559,0:27:51.821
protocols, even going back and adding the[br]notions of signatures into this. Because
0:27:51.821,0:27:56.350
just like all this machinery we have is[br]good for Diffie-Hellman based protocols,
0:27:56.350,0:27:59.940
probably we can take all these notions of[br]patterns and of Noise protocols and how
0:27:59.940,0:28:03.909
our approach to negotiation and[br]apply them even to more conventional AKEs
0:28:03.909,0:28:08.330
into other things as well. So that's sort[br]of our framework, you know it ends up
0:28:08.330,0:28:12.340
looking kind of like this, with some, you[br]know, a very simple negotiation layer
0:28:12.340,0:28:16.920
switching to this very linear notion of a[br]fixed Noise protocol that you can assemble
0:28:16.920,0:28:21.360
together by taking an abstract notion of[br]patterns and combining it with
0:28:21.360,0:28:25.450
cryptography of your choice. You know[br]we're still working on a lot of extensions
0:28:25.450,0:28:29.679
for this, I'd love to get more people who[br]wanted to experiment with it or use it for
0:28:29.679,0:28:34.070
anything. You can find more on our website[br]which has links to our mailing list as
0:28:34.070,0:28:38.110
well. I'm happy to talk about it with[br]anyone. There's gonna be a WireGuard meet
0:28:38.110,0:28:43.250
up tomorrow at 3 o'clock and I'll probably[br]be milling around there as well, but if
0:28:43.250,0:28:46.210
you want to talk to Jason and other[br]WireGuard people and see how all this
0:28:46.210,0:28:50.370
works in a concrete context, that would be[br]you know a good way to learn more about
0:28:50.370,0:28:55.410
it. Thank you for listening, and do I have[br]time for questions? Maybe a brief amount
0:28:55.410,0:29:08.399
of time.[br]applause
0:29:08.399,0:29:22.159
Herald-Angel: Microphone one.[br]Question: So in the context of like multi-
0:29:22.159,0:29:27.559
party systems, if you have like a person[br]that has either multiple devices or
0:29:27.559,0:29:34.830
multiple keys, is there anything that you[br]could use inside Noise to work with that
0:29:34.830,0:29:39.320
so that you have like messages being sent[br]to both identities, or would you recommend
0:29:39.320,0:29:44.360
some doing something like that over like a[br]central registry and then linking the keys
0:29:44.360,0:29:48.009
and having it sent to one and the devices[br]sharing with each other?
0:29:48.009,0:29:50.950
Answer: Yeah that's a good question, I[br]mean I think that really gets into the
0:29:50.950,0:29:54.029
scope of what like secure messaging[br]protocols try to address, is when you have
0:29:54.029,0:29:57.230
notions of groups and want to be[br]consistent with the group and you want to
0:29:57.230,0:29:59.809
talk to everyone in the group and maybe[br]everyone in the group isn't online at the
0:29:59.809,0:30:03.539
same time, and I would say that's a[br]different and more complex class of
0:30:03.539,0:30:07.230
protocols that we're kind of just not[br]trying to handle here. I think with Noise
0:30:07.230,0:30:09.929
hopefully we're looking at something[br]that's a very simple and well understood
0:30:09.929,0:30:13.350
design space so we can build a lot of[br]machinery around it, because it's so
0:30:13.350,0:30:16.269
simple, and these other cases you're[br]talking about I think just add a lot of
0:30:16.269,0:30:20.090
complexity about how you would want to do[br]all those things. So we've kind of just
0:30:20.090,0:30:25.799
chosen a narrow scope to make this[br]specific problem a lot easier, I would
0:30:25.799,0:30:29.330
say.[br]Q: Okay, thanks!
0:30:29.330,0:30:33.190
Q: Does Noise include any of the[br]ratcheting or sort of key evolution over
0:30:33.190,0:30:36.320
time properties that we've seen in[br]protocols like this in the past?
0:30:36.320,0:30:40.799
A: No, so Noise has a pretty simple model[br]of just you have like a handshake phase
0:30:40.799,0:30:44.350
and a transport phase and the transport[br]phase just uses a key. Now we have added a
0:30:44.350,0:30:49.280
notion of being able to like update this[br]key by just replacing it with, like, you
0:30:49.280,0:30:52.559
know, some of its own output, essentially.[br]So we can kind of roll it forward in a
0:30:52.559,0:30:56.190
very simple way and we have an efficient[br]way of doing that, so you could do things
0:30:56.190,0:30:59.090
like have every one of your messages[br]update the key to the next key, and then
0:30:59.090,0:31:02.820
you have within the protocol forward[br]secrecy. We don't try to do like more
0:31:02.820,0:31:09.669
complicated things with Diffie-Hellman[br]ratchets or anything like that,
0:31:09.669,0:31:16.110
Q: When would be--what's the simple sales[br]pitch for why to use Noise over TLS?
0:31:16.110,0:31:20.830
A: You know, probably the simplest sales[br]pitch would be like, if you really really
0:31:20.830,0:31:24.720
want your protocol to just do like one[br]thing and you don't want to drag around a
0:31:24.720,0:31:27.809
lot of code that does like a lot of[br]things, you know like Noise will let you
0:31:27.809,0:31:32.259
produce a very fine-tuned protocol that's[br]a very small amount of code that just does
0:31:32.259,0:31:35.100
like one thing pretty easily.
0:31:35.100,0:31:37.150
Herald: That's it, thanks a lot
0:31:37.150,0:31:41.819
Perrin: Thank you.[br]applause
0:31:41.819,0:31:47.619
postroll music
0:31:47.619,0:32:03.000
subtitles created by c3subtitles.de[br]in the year 2018. Join, and help us!