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