0:00:00.320,0:00:17.689
Herald: Our next talk is on "the plain simple[br]reality of entropy", and

0:00:17.689,0:00:21.570
we all know that you need randomness and entropy

0:00:21.570,0:00:23.990
if you want to do something like encryption

0:00:23.990,0:00:26.140
or generate keys.

0:00:26.140,0:00:28.830
And if you don't want to do it the xkcd way,

0:00:28.830,0:00:31.779
using only 4 as the random number,

0:00:31.779,0:00:37.430
you need a cryptographically secure pseudorandom[br]number generator,

0:00:37.430,0:00:39.710
and what is this, how it works,

0:00:39.710,0:00:41.719
and where you can find one,

0:00:41.719,0:00:44.170
will be the topic of this talk.

0:00:44.170,0:00:47.170
So I present to you Filippo Valsorda,

0:00:47.170,0:00:52.440
on "How I learned to stop worrying and love[br]urandom".

0:00:52.440,0:00:59.230
applause

0:00:59.230,0:01:03.440
FV: Hello. Okay, I'm very glad so many people[br]showed up,

0:01:03.440,0:01:06.580
even if I essentially gave away the entire[br]content of the talk

0:01:06.580,0:01:09.700
in the description.

0:01:09.700,0:01:11.430
Want me to stop, to leave, something?

0:01:11.430,0:01:12.479
Okay? No.

0:01:12.479,0:01:15.100
Anyway, hi! I'm Filippo Valsorda,

0:01:15.100,0:01:16.490
I work for CloudFlare,

0:01:16.490,0:01:18.869
I do cryptography and systems engineering,

0:01:18.869,0:01:22.950
I recently implemented the DNSSEC implementation

0:01:22.950,0:01:25.829
of the CloudFlare DNS server,

0:01:25.829,0:01:31.750
and maybe in April 2014, you used my Heartbleed[br]test.

0:01:31.750,0:01:33.200
Anyway,

0:01:33.200,0:01:34.659
applause

0:01:34.659,0:01:39.020
Well, thank you!

0:01:39.020,0:01:44.360
Okay. Anyway, I'm here to tell you about random[br]bytes.

0:01:44.360,0:01:46.369
So, here are some random bytes.

0:01:46.369,0:01:50.119
They're pretty good, you can use them.

0:01:50.119,0:01:52.479
laughter

0:01:52.479,0:01:55.649
But, if you need more,

0:01:55.649,0:01:59.420
Amazon sells this excellent book

0:01:59.420,0:02:04.820
full of a million random numbers.

0:02:04.820,0:02:07.670
Anyway. More seriously,

0:02:07.670,0:02:10.630
random numbers are central to a lot of

0:02:10.630,0:02:16.050
the security protocols and systems of our[br]modern technology.

0:02:16.050,0:02:19.310
The most obvious is encryption keys.

0:02:19.310,0:02:22.020
You obviously want your encryption key to[br]be random,

0:02:22.020,0:02:24.220
to be really hard to predict,

0:02:24.220,0:02:26.140
and you want your encryption key to be different

0:02:26.140,0:02:29.080
from the person next to you.

0:02:29.080,0:02:30.250
Unless you're doing key escrow,

0:02:30.250,0:02:32.520
which, well, we don't point.

0:02:32.520,0:02:37.160
So, a lot of other different systems

0:02:37.160,0:02:41.130
use randomness to prevent all kinds of attack.

0:02:41.130,0:02:43.600
In particular, one amongst many,

0:02:43.600,0:02:45.780
DNS, using random query IDs

0:02:45.780,0:02:48.640
to prevent Kaminsky attacks.

0:02:48.640,0:02:55.450
So, what makes a stream, a source of random[br]bytes, good?

0:02:55.450,0:02:59.190
What are we looking for when we look for good[br]random bytes?

0:02:59.190,0:03:03.560
First of all, we look for uniform random bytes.

0:03:03.560,0:03:07.380
Every time we draw a random byte from our[br]random byte source

0:03:07.380,0:03:09.510
we want to have the same probability

0:03:09.510,0:03:13.590
to get all values, from 0 to 255.

0:03:13.590,0:03:18.510
For example, you don't want your distribution[br]to look like this.

0:03:18.510,0:03:21.150
This is RC4.

0:03:21.150,0:03:23.880
But that's not enough.

0:03:23.880,0:03:28.370
You also want your random bytes to be completely[br]unpredictable.

0:03:28.370,0:03:33.190
And here is where the task actually becomes[br]difficult.

0:03:33.190,0:03:36.640
Because if you think about it, we are programming[br]computers.

0:03:36.640,0:03:38.650
Computers are very deterministic machines,

0:03:38.650,0:03:43.770
even if they don't feel like they are.

0:03:43.770,0:03:45.830
And they're essentially machines built

0:03:45.830,0:03:51.870
to sequentially execute always the same set[br]of instructions,

0:03:51.870,0:03:54.450
which we call code.

0:03:54.450,0:03:56.560
And when we ask them, at some point,

0:03:56.560,0:03:58.950
to do something that is completely different

0:03:58.950,0:04:00.900
every time they do it,

0:04:00.900,0:04:03.730
and two equal computers should do it differently,

0:04:03.730,0:04:05.260
we get in trouble.

0:04:05.260,0:04:11.310
So, where can a computer source this randomness?

0:04:11.310,0:04:15.220
Where can a computer find unpredictability,

0:04:15.220,0:04:17.579
if it can't have its own?

0:04:17.579,0:04:21.700
Obviously, in our messy meat world.

0:04:21.700,0:04:23.440
In our physical world,

0:04:23.440,0:04:27.970
where everything is not always happening the[br]same way.

0:04:27.970,0:04:32.060
So, user input: every time you type on the[br]keyboard,

0:04:32.060,0:04:33.820
you do that with different timings.

0:04:33.820,0:04:35.180
When you move your mouse around,

0:04:35.180,0:04:37.320
you do that differently every time.

0:04:37.320,0:04:40.720
Or, simply, reading from disk.

0:04:40.720,0:04:45.190
Every time your computer reads something from[br]disk,

0:04:45.190,0:04:49.210
it takes a slightly different amount of time.

0:04:49.210,0:04:53.400
Or interrupt times, I/O, you get the idea.

0:04:53.400,0:04:56.880
So, all these events are visible to the kernel.

0:04:56.880,0:04:59.190
The kernel is the component of your system

0:04:59.190,0:05:03.250
which is controlling all these interactions

0:05:03.250,0:05:05.820
with the outside world, and can measure them

0:05:05.820,0:05:09.850
and observe them with the right precision.

0:05:09.850,0:05:14.100
And each of these events can have

0:05:14.100,0:05:16.990
a wide or narrow range of possible values,

0:05:16.990,0:05:19.200
for example, when you read from disk,

0:05:19.200,0:05:25.190
it might take from 0.17 nanoseconds to 1.3[br]nanoseconds.

0:05:25.190,0:05:29.070
I made numbers up.

0:05:29.070,0:05:33.600
How wide this range is what we call entropy.

0:05:33.600,0:05:36.140
Essentially it is how many different values,

0:05:36.140,0:05:40.750
how spread apart the values are,

0:05:40.750,0:05:45.250
which also means how easy they are to predict.

0:05:45.250,0:05:48.610
But something they definitely aren't is uniform.

0:05:48.610,0:05:51.140
Because as I said, for example, reading from[br]disk

0:05:51.140,0:05:53.420
might take in a specific range,

0:05:53.420,0:05:56.510
definitely not from 0 to 255 nanoseconds.

0:05:56.510,0:05:58.990
That would be...

0:05:58.990,0:06:01.310
And usually they're not enough to satisfy

0:06:01.310,0:06:04.310
all our random bytes needs.

0:06:04.310,0:06:07.680
So, now we have some unpredictability.

0:06:07.680,0:06:12.150
We have some events that we can see from our[br]system,

0:06:12.150,0:06:15.900
and we want to turn that into a stream of[br]random bytes

0:06:15.900,0:06:18.770
that we can use to generate SSH keys,

0:06:18.770,0:06:21.950
and DNS query IDs, etc.

0:06:21.950,0:06:24.870
Enter a CSPRNG.

0:06:24.870,0:06:29.220
Cryptographers like their acronyms very long.

0:06:29.220,0:06:33.500
It's a cryptographically secure pseudorandom[br]number generator.

0:06:33.500,0:06:36.630
applause

0:06:36.630,0:06:39.910
It's not that hard to pronounce!

0:06:39.910,0:06:41.670
Okay, it is.

0:06:41.670,0:06:45.620
Anyway, it's nothing else than a cryptographic[br]tool

0:06:45.620,0:06:51.560
that takes some input and generates an unlimited,

0:06:51.560,0:06:52.590
reasonably unlimited,

0:06:52.590,0:06:56.990
stream of random uniform bytes,

0:06:56.990,0:07:03.340
which depend on all and only the input you[br]gave to the CSPRNG.

0:07:03.340,0:07:05.780
So you can see how we can use this.

0:07:05.780,0:07:09.930
We have this amount of random events,

0:07:09.930,0:07:13.090
we feed that into the CSPRNG,

0:07:13.090,0:07:17.010
and we get out random bytes that we can use[br]for everything.

0:07:17.010,0:07:21.940
So, to understand how a CSPRNG works,

0:07:21.940,0:07:26.620
I decided to simply present you with a very[br]simple one.

0:07:26.620,0:07:28.560
One based on hash functions.

0:07:28.560,0:07:31.889
I assume that everyone in the hall

0:07:31.889,0:07:34.950
knows essentially what hash functions are.

0:07:34.950,0:07:39.370
But the properties we care about today of[br]hash functions are:

0:07:39.370,0:07:43.090
The fact that the output is uniform.

0:07:43.090,0:07:45.870
If you take the output of a hash function,

0:07:45.870,0:07:48.490
all the bits should be indistinguishable from[br]random,

0:07:48.490,0:07:51.660
if you don't know the input.

0:07:51.660,0:07:54.730
It's impossible to reverse a hash function.

0:07:54.730,0:07:57.180
If I give you the output of a hash function,

0:07:57.180,0:07:59.690
you should know nothing more than before

0:07:59.690,0:08:03.120
about what the input of the hash function[br]is,

0:08:03.120,0:08:05.970
unless you can specifically figure out the[br]input

0:08:05.970,0:08:09.840
and try the hash function.

0:08:09.840,0:08:13.430
And finally, it takes a limited amount of[br]input,

0:08:13.430,0:08:16.540
and makes a fixed amount of output.

0:08:16.540,0:08:18.820
These are the properties we are going to use

0:08:18.820,0:08:23.639
to build a CSPRNG out of hash functions.

0:08:23.639,0:08:26.699
So. This is how it works.

0:08:26.699,0:08:27.919
We start with a pool.

0:08:27.919,0:08:32.169
We call "pool" an array of bytes,

0:08:32.169,0:08:35.150
and we fill it with zeros to start.

0:08:35.150,0:08:37.510
And every time a new event comes in,

0:08:37.510,0:08:40.679
for example, you moved the mouse around,

0:08:40.679,0:08:41.929
we take that event,

0:08:41.929,0:08:44.890
we serialize it to some binary format,

0:08:44.890,0:08:46.040
doesn't really matter.

0:08:46.040,0:08:52.080
For example, mouse is at position 15 to 835.

0:08:52.080,0:08:53.140
And we hash together,

0:08:53.140,0:08:56.830
we hash the concatenation of our pool,

0:08:56.830,0:08:59.330
which for now is just zeros,

0:08:59.330,0:09:03.279
and the serialization of this event.

0:09:03.279,0:09:06.339
We hash them together, we get an output,

0:09:06.339,0:09:10.010
and that's our new value of the pool.

0:09:10.010,0:09:10.970
And we repeat.

0:09:10.970,0:09:15.450
Now, instead of zeros, we have the output[br]from before.

0:09:15.450,0:09:19.940
Now we have this output, and a new event happens.

0:09:19.940,0:09:25.860
A disk read happens, and it takes exactly[br]1.27589 nanoseconds.

0:09:25.860,0:09:33.510
And we hash together the old contents of the[br]pool,

0:09:33.510,0:09:38.390
this information, disk read happened and it[br]took this amount of time,

0:09:38.390,0:09:42.440
we hash them together and we get a new value[br]of the pool.

0:09:42.440,0:09:45.250
You see where this is going.

0:09:45.250,0:09:46.540
We keep doing this.

0:09:46.540,0:09:48.890
Every time a new event comes in,

0:09:48.890,0:09:51.000
every time the mouse moves,

0:09:51.000,0:09:53.630
every time a CPU interrupt is raised,

0:09:53.630,0:09:56.230
every time disk read happens,

0:09:56.230,0:09:58.940
we call this stirring function

0:09:58.940,0:10:02.730
to mix this event into this pool.

0:10:02.730,0:10:04.920
And what do we end up with?

0:10:04.920,0:10:07.640
We end up with what we call an entropy pool.

0:10:07.640,0:10:13.830
Now, to figure this value, you need exactly[br]all the events

0:10:13.830,0:10:16.410
that lead to this value.

0:10:16.410,0:10:19.450
If you're an attacker, and you really want[br]to figure out

0:10:19.450,0:10:21.520
what my entropy pool is,

0:10:21.520,0:10:25.399
you don't, you're not supposed to have any[br]better way

0:10:25.399,0:10:28.810
to figure it out than to guess all the different

0:10:28.810,0:10:32.050
hard disk timings and mouse movements that[br]happened

0:10:32.050,0:10:35.230
all the way up to now.

0:10:35.230,0:10:41.089
Okay? So now we have this essentially unpredictable[br]value,

0:10:41.089,0:10:43.870
but now we want to generate keys out of it,

0:10:43.870,0:10:48.899
and we can't just use these few bytes here.

0:10:48.899,0:10:53.180
So we can use again hash functions.

0:10:53.180,0:10:54.300
Same hash function.

0:10:54.300,0:10:58.310
We take the entropy pool, and we hash it with[br]a counter.

0:10:58.310,0:11:02.800
You want 5000 random bits? Sure.

0:11:02.800,0:11:04.540
You hash entropy pool and 0,

0:11:04.540,0:11:09.860
hash entropy pool and 1, and 2, 3, 4, 5, 6,[br]7, 8, 9.

0:11:09.860,0:11:13.399
You get all these outputs, you concatenate[br]them,

0:11:13.399,0:11:18.660
and now you have 5000 bits, which are as unpredictable

0:11:18.660,0:11:23.420
as all the events that were stirred into the[br]pool.

0:11:23.420,0:11:25.700
Let's think about it for a second.

0:11:25.700,0:11:28.550
We said that hash functions are not invertible,

0:11:28.550,0:11:31.279
so even if you know one of the outputs,

0:11:31.279,0:11:34.410
you can't get back to the entropy pool.

0:11:34.410,0:11:37.110
And we said that hash functions have,

0:11:37.110,0:11:41.480
that with hash functions, all the bits in[br]input

0:11:41.480,0:11:43.670
affect all the bits of the output.

0:11:43.670,0:11:46.790
So even if just the counter changes

0:11:46.790,0:11:50.180
between one rand and the other,

0:11:50.180,0:11:52.250
the output is completely unrelated.

0:11:52.250,0:11:55.970
So, did we get what we want?

0:11:55.970,0:11:58.270
It's uniform, because we said before,

0:11:58.270,0:12:00.930
hash functions' outputs are uniform.

0:12:00.930,0:12:04.380
It's unpredictable, because the only way an[br]attacker has

0:12:04.380,0:12:07.870
to figure out what the output will be

0:12:07.870,0:12:12.890
is imagine or brute-force or observe, I guess,

0:12:12.890,0:12:17.160
all the hard-disk timings and user inputs,

0:12:17.160,0:12:20.380
which is impossible for a third party.

0:12:20.380,0:12:22.380
And it's unlimited, because we can keep

0:12:22.380,0:12:25.260
incrementing that counter forever.

0:12:25.260,0:12:29.010
Now, really please don't go implement this[br]scheme

0:12:29.010,0:12:32.100
and say "Filippo told me it was okay".

0:12:32.100,0:12:33.060
No.

0:12:33.060,0:12:38.160
Also because it's exactly not what this talk[br]is about.

0:12:38.160,0:12:44.550
So, if CSPRNGs, if we have this tool

0:12:44.550,0:12:48.180
to turn some unpredictable events

0:12:48.180,0:12:51.600
into an unlimited stream of random bytes,

0:12:51.600,0:12:53.230
which is what we need,

0:12:53.230,0:12:55.160
and we have all these unpredictable events

0:12:55.160,0:12:57.750
observed by the kernel,

0:12:57.750,0:13:01.990
doesn't it make sense to just put a CSPRNG[br]in the kernel

0:13:01.990,0:13:05.490
and just have the kernel run the CSPRNG

0:13:05.490,0:13:09.250
when we need random bytes?

0:13:09.250,0:13:12.830
It's such a good idea that it's exactly what[br]Linux did,

0:13:12.830,0:13:15.730
and all the other operating systems.

0:13:15.730,0:13:18.850
In Linux, it's called /dev/urandom,

0:13:18.850,0:13:22.740
and it looks like a file, you read it like[br]a file,

0:13:22.740,0:13:25.240
and it's technically a character device

0:13:25.240,0:13:27.800
and every time you read 100 bytes from it,

0:13:27.800,0:13:31.360
it runs a CSPRNG, on an entropy pool

0:13:31.360,0:13:34.920
not different from the one I've presented,

0:13:34.920,0:13:41.279
and this entropy pool is stirred with all[br]the events

0:13:41.279,0:13:46.680
that the kernel saw happen from its privileged[br]position.

0:13:46.680,0:13:50.610
Other operating systems have something similar.

0:13:50.610,0:13:54.890
OS X and BSD have /dev/random

0:13:54.890,0:13:59.170
which is exactly what /dev/urandom is on Linux,

0:13:59.170,0:14:01.110
and on Windows you can get something similar

0:14:01.110,0:14:06.640
with a CryptGenRandom call.

0:14:06.640,0:14:08.260
One last thing.

0:14:08.260,0:14:11.120
Putting the CSPRNG in the kernel

0:14:11.120,0:14:13.390
is not only about convenience,

0:14:13.390,0:14:15.279
it's also about security.

0:14:15.279,0:14:16.740
Because, first of all,

0:14:16.740,0:14:19.540
the kernel is the entity that can observe

0:14:19.540,0:14:21.930
the unpredictable events.

0:14:21.930,0:14:25.660
If you take a CSPRNG, which is just code,

0:14:25.660,0:14:27.640
so you can implement your own,

0:14:27.640,0:14:30.120
and you implement it in your library,

0:14:30.120,0:14:32.100
or in your application,

0:14:32.100,0:14:33.360
now you have the problem of,

0:14:33.360,0:14:38.180
how do you take the random, the unpredictable[br]events

0:14:38.180,0:14:42.130
from the kernel and take them to the application?

0:14:42.130,0:14:45.959
This is something that you can forget to do,

0:14:45.959,0:14:46.790
often,

0:14:46.790,0:14:48.420
or do wrong.

0:14:48.420,0:14:52.459
And, moreover, the kernel can protect

0:14:52.459,0:14:55.430
the memory space of the entropy pool

0:14:55.430,0:14:58.209
much better than applications.

0:14:58.209,0:15:00.180
For example, applications can fork,

0:15:00.180,0:15:02.640
there's a whole lot of different things

0:15:02.640,0:15:05.220
that applications can get wrong.

0:15:05.220,0:15:10.160
And finally, you have one single centralized[br]implementation

0:15:10.160,0:15:13.990
that is reasonably easy to audit.

0:15:13.990,0:15:19.000
I don't know, was anyone managing Debian servers[br]in 2008?

0:15:19.000,0:15:20.410
laughter

0:15:20.410,0:15:24.720
Just asking. Unrelated. Right.

0:15:24.720,0:15:29.000
So, yeah. /dev/urandom.

0:15:29.000,0:15:34.260
So, we have a solution, right?

0:15:34.260,0:15:37.839
We have a tool to turn unpredictable events

0:15:37.839,0:15:42.010
into an unlimited uniform stream of random[br]bytes,

0:15:42.010,0:15:46.339
we have a source of unpredictable events,

0:15:46.339,0:15:48.680
solved!

0:15:48.680,0:15:50.350
What are everybody talking about?

0:15:50.350,0:15:52.800
Why is there even a need for a talk?

0:15:52.800,0:16:01.600
Well. Sadly, there's some common misconceptions[br]in the field,

0:16:01.600,0:16:05.760
which is also why I'm here to give this talk.

0:16:05.760,0:16:10.790
One of the most common is fueled by the very[br]Linux man pages.

0:16:10.790,0:16:13.839
The recent versions are better but

0:16:13.839,0:16:16.510
they still give you this impression

0:16:16.510,0:16:19.890
that if you want real security,

0:16:19.890,0:16:21.589
you should be using /dev/random,

0:16:21.589,0:16:24.820
because /dev/urandom is okay, but, hmm, kinda...

0:16:24.820,0:16:29.459
and, well, we want real security, right?

0:16:29.459,0:16:31.510
But you might ask yourself, okay,

0:16:31.510,0:16:34.430
if /dev/urandom is a CSPRNG,

0:16:34.430,0:16:38.200
and a CSPRNG is all I need,

0:16:38.200,0:16:40.390
what else can I get,

0:16:40.390,0:16:44.800
what does /dev/random have more?

0:16:44.800,0:16:48.100
Well, the idea of this talk is giving you[br]the knowledge

0:16:48.100,0:16:52.450
to figure out by yourself whether you need[br]/dev/random or not.

0:16:52.450,0:16:54.779
So, first I explained how a CSPRNG works,

0:16:54.779,0:16:58.140
now I'm going to go a bit into the details

0:16:58.140,0:17:01.880
of how /dev/urandom and /dev/random work.

0:17:01.880,0:17:06.289
These are taken directly from the kernel source.

0:17:06.289,0:17:11.378
Both /dev/urandom and /dev/random are...

0:17:11.378,0:17:13.689
Yeah. Sorry.

0:17:13.689,0:17:16.409
Essentially, everything I'm going to say now

0:17:16.409,0:17:19.628
applies to both /dev/urandom and /dev/random.

0:17:19.628,0:17:24.189
They both are based on a pool of 4000 bits,

0:17:24.189,0:17:29.149
not dissimilar from the one of the CSPRNG[br]we played with before,

0:17:29.149,0:17:36.340
which is implemented as a series of 32-bits[br]words, I think.

0:17:36.340,0:17:39.409
The pool is mixed with all the unpredictable[br]events,

0:17:39.409,0:17:41.469
using a CRC-like function.

0:17:41.469,0:17:44.539
This is not a cryptographically secure hash[br]function,

0:17:44.539,0:17:47.979
but this is just about how the unpredictable[br]events,

0:17:47.979,0:17:52.519
the interrupts, the disk timings, are stirred

0:17:52.519,0:17:55.649
into the internal pool.

0:17:55.649,0:17:58.009
Every time one of these events happens,

0:17:58.009,0:18:00.330
this very fast function kicks in

0:18:00.330,0:18:07.419
and stirs the pool with the unpredictable[br]event.

0:18:07.419,0:18:13.090
Then extraction, so actual random byte generation,

0:18:13.090,0:18:14.539
happens with SHA-1.

0:18:14.539,0:18:17.019
So you want some random bytes from the kernel,

0:18:17.019,0:18:21.539
what the kernel does is just run SHA-1 on[br]the pool,

0:18:21.539,0:18:22.759
give you the output,

0:18:22.759,0:18:26.799
and also take the output and feed it back[br]into the pool

0:18:26.799,0:18:28.619
using that mixing function.

0:18:28.619,0:18:31.840
This is a big difference, you might have noticed,

0:18:31.840,0:18:35.119
from our design, which is a counter,

0:18:35.119,0:18:38.820
because keeping counters, turns out, is still[br]hard.

0:18:38.820,0:18:43.629
And they can reset, you can lose count, that's[br]bad.

0:18:43.629,0:18:48.739
Also, this has more security properties against[br]compromise.

0:18:48.739,0:18:51.200
So what is does is simply that,

0:18:51.200,0:18:54.149
when it generates output, it also stirs it[br]back,

0:18:54.149,0:18:55.350
and if you need more output,

0:18:55.350,0:18:57.809
SHA-1 again on the new pool

0:18:57.809,0:19:00.509
gives output and stirs it back into the pool,

0:19:00.509,0:19:03.309
so that the pool keeps changing.

0:19:03.309,0:19:06.989
Now, both /dev/urandom and /dev/random

0:19:06.989,0:19:09.730
do the exact same thing.

0:19:09.730,0:19:13.409
Same code, same sizes, same entropy sources,

0:19:13.409,0:19:15.159
literally in the source,

0:19:15.159,0:19:18.070
random_read is a call to extract_entropy_user,

0:19:18.070,0:19:23.210
urandom_read is a call to extract_entropy_user.

0:19:23.210,0:19:26.730
The only difference is

0:19:26.730,0:19:30.119
I finally get to what's special about /dev/random,

0:19:30.119,0:19:34.320
is that it tries to do a couple of really[br]hard and weird things.

0:19:34.320,0:19:39.149
First, it tries to guess how many bits of[br]entropy

0:19:39.149,0:19:43.529
were mixed into the pool after each unpredictable[br]event.

0:19:43.529,0:19:46.450
This is already very hard, because, think[br]about it,

0:19:46.450,0:19:53.190
a disk read took 1.735 nanoseconds. Great.

0:19:53.190,0:19:56.340
We don't know how many different values this[br]might take.

0:19:56.340,0:19:59.570
We don't know if this is a spinning hard disk,

0:19:59.570,0:20:01.950
which has timings all over the place,

0:20:01.950,0:20:05.379
or if it's a SSD which almost always takes[br]the same time.

0:20:05.379,0:20:07.700
So we don't know how much predictable this[br]is.

0:20:07.700,0:20:08.769
So this is already hard,

0:20:08.769,0:20:13.460
figuring out how unpredictable the pool is.

0:20:13.460,0:20:18.359
So it keeps a counter, arbitrary number of[br]how many bits

0:20:18.359,0:20:21.330
of entropy, how much unpredictability

0:20:21.330,0:20:24.590
there is in this pool.

0:20:24.590,0:20:27.860
And then, when you run the hash function on[br]the pool,

0:20:27.860,0:20:30.799
it decreases this count,

0:20:30.799,0:20:33.950
it reduces this number.

0:20:33.950,0:20:37.909
And if this number gets too low, it blocks[br]you.

0:20:37.909,0:20:39.489
So you're reading from /dev/random,

0:20:39.489,0:20:41.479
this number dwindles,

0:20:41.479,0:20:44.210
so now you're still reading from /dev/random

0:20:44.210,0:20:45.320
but you're blocked

0:20:45.320,0:20:48.889
until more unpredictable events happen.

0:20:48.889,0:20:52.379
This is useless in the modern world.

0:20:52.379,0:20:53.889
Because entropy does not decrease.

0:20:53.889,0:20:59.229
Entropy does not run out, and everything freezes.

0:20:59.229,0:21:01.029
Once the pool becomes unpredictable

0:21:01.029,0:21:04.429
because too many different events contributed

0:21:04.429,0:21:06.729
to how the entropy pool looks like,

0:21:06.729,0:21:08.710
it's forever unpredictable,

0:21:08.710,0:21:12.519
because the attacker doesn't learn anything[br]from the output.

0:21:12.519,0:21:15.859
Obviously, unless the CSPRNG is broken

0:21:15.859,0:21:19.629
and is leaking information about the entropy[br]pool.

0:21:19.629,0:21:23.129
However, saying that CSPRNGs are broken

0:21:23.129,0:21:29.229
is equivalent to saying that a lot of cryptography[br]constructs are broken.

0:21:29.229,0:21:31.659
It's saying that stream ciphers are broken,

0:21:31.659,0:21:34.340
it's saying that CTR mode is broken,

0:21:34.340,0:21:36.659
it's saying that TLS and PGP are broken,

0:21:36.659,0:21:39.470
because they're both about reusing the same[br]key

0:21:39.470,0:21:42.299
for multiple packets or messages.

0:21:42.299,0:21:45.269
So if cryptographers didn't know how to build

0:21:45.269,0:21:47.769
a secure CSPRNG,

0:21:47.769,0:21:50.029
it would mean that cryptographers weren't[br]able

0:21:50.029,0:21:54.749
to build most of the things we're relying[br]on today.

0:21:54.749,0:21:57.169
It would mean that cryptography was doomed.

0:21:57.169,0:22:02.059
Now, I'm not DJB, I can't tell you if cryptography[br]is doomed.

0:22:02.059,0:22:05.590
But I can tell you that if cryptography is[br]doomed,

0:22:05.590,0:22:08.210
your problem is not your CSPRNG.

0:22:08.210,0:22:09.330
laughter

0:22:09.330,0:22:12.529
So, cryptography relies on being able

0:22:12.529,0:22:16.389
to build secure CSPRNGs.

0:22:16.389,0:22:17.129
And on the other hand,

0:22:17.129,0:22:20.950
that makes /dev/random blocking useless, obviously.

0:22:20.950,0:22:23.320
It can be unacceptable, too, because

0:22:23.320,0:22:25.700
you get a TLS request, and you're like

0:22:25.700,0:22:29.009
"I have that HTTP page, but wait a second,

0:22:29.009,0:22:31.619
I need someone to start typing

0:22:31.619,0:22:36.720
on the keyboard of the rack to serve it to[br]you."

0:22:36.720,0:22:38.009
And it can even be dangerous,

0:22:38.009,0:22:40.080
because you're essentially giving away information

0:22:40.080,0:22:42.619
about what other users in the system are doing

0:22:42.619,0:22:46.059
to other users.

0:22:46.059,0:22:47.519
On the other hand,

0:22:47.519,0:22:50.320
/dev/urandom is safe for any cryptography[br]use

0:22:50.320,0:22:51.739
you want to use it for.

0:22:51.739,0:22:54.019
You want to generate long-term keys...

0:22:54.019,0:22:59.529
My GPG keys are generated from /dev/urandom.

0:22:59.529,0:23:01.899
And I'm not the only one saying this,

0:23:01.899,0:23:06.369
BoringSSL, Python, Go, Ruby, use /dev/urandom

0:23:06.369,0:23:09.809
as the only source, the only CSPRNG.

0:23:09.809,0:23:13.070
Sandstorm even replaces /dev/random with it.

0:23:13.070,0:23:15.220
And here is a long list of people

0:23:15.220,0:23:20.259
saying exactly what I'm here on stage to tell[br]you.

0:23:20.259,0:23:26.119
So, I hope that at the end of this, you see

0:23:26.119,0:23:29.600
that you don't actually need /dev/random,

0:23:29.600,0:23:31.450
as well as you don't need to keep measuring

0:23:31.450,0:23:33.869
how much entropy you have in the pool,

0:23:33.869,0:23:35.570
you don't need to refill the pool

0:23:35.570,0:23:37.840
with things like haveged or

0:23:37.840,0:23:39.960
I don't know how to pronounce it.

0:23:39.960,0:23:45.919
Actually I've even seen people take output[br]from /dev/urandom

0:23:45.919,0:23:49.349
and pipe it back as root into /dev/random

0:23:49.349,0:23:51.989
so that the entropy doesn't run out,

0:23:51.989,0:23:58.179
which is exactly what the kernel is doing!

0:23:58.179,0:24:03.359
Which is, obviously, a pretty upvoted answer[br]on StackOverflow.

0:24:03.359,0:24:04.779
laughter

0:24:04.779,0:24:08.549
Anyway. And finally,

0:24:08.549,0:24:10.489
random number quality does not decrease,

0:24:10.489,0:24:13.259
there are not like premium-level random numbers

0:24:13.259,0:24:18.169
and then they kinda rot after you use them[br]for a while.

0:24:18.169,0:24:21.419
No, that's not a thing.

0:24:21.419,0:24:26.349
Okay. So, there is only one small case

0:24:26.349,0:24:29.659
in which /dev/urandom does not do exactly

0:24:29.659,0:24:33.590
what we would expect it to do, which is early[br]at boot.

0:24:33.590,0:24:34.389
If you think about it,

0:24:34.389,0:24:38.529
everything we said is about using unpredictable[br]events

0:24:38.529,0:24:40.659
to build up unpredictability.

0:24:40.659,0:24:43.509
As soon as you boot the machine,

0:24:43.509,0:24:47.559
you don't have observed enough events yet.

0:24:47.559,0:24:50.889
So this got embedded devices,

0:24:50.889,0:24:55.519
this got the Raspberry Pi recently,

0:24:55.519,0:24:57.809
essentially it's a Linux shortcoming,

0:24:57.809,0:25:00.200
which by now it's too late to fix,

0:25:00.200,0:25:02.389
which is the fact that /dev/urandom will not[br]block

0:25:02.389,0:25:05.999
even at boot, before being initialized.

0:25:05.999,0:25:09.710
The solution in most cases is just that the[br]distribution

0:25:09.710,0:25:12.809
should save the state of the pool at power-off,

0:25:12.809,0:25:15.570
and reload it at power-on,

0:25:15.570,0:25:18.849
or block until the pool is initialized.

0:25:18.849,0:25:22.999
So, your distribution probably solves this[br]for you anyway.

0:25:22.999,0:25:28.159
So, to sum up, CSPRNGs are pretty cool, and[br]they work.

0:25:28.159,0:25:30.809
You don't need /dev/random.

0:25:30.809,0:25:33.529
You shouldn't use userspace CSPRNGs

0:25:33.529,0:25:35.820
because they're very easy to get wrong.

0:25:35.820,0:25:38.710
And if you need 100 random bytes,

0:25:38.710,0:25:42.029
read 100 bytes from /dev/urandom.

0:25:42.029,0:25:43.699
That's it!

0:25:43.699,0:25:54.529
applause

0:25:54.529,0:25:58.009
I glossed over a lot of different ways to[br]do it wrong,

0:25:58.009,0:26:01.089
so if you have questions about why not this[br]other thing,

0:26:01.089,0:26:03.119
please, come forward.

0:26:03.119,0:26:07.249
Herald: Okay, and because people on the stream[br]can't be here in person,

0:26:07.249,0:26:09.720
we will start with questions from the Internet.

0:26:09.720,0:26:13.960
Q: The first question is: How do you explain,

0:26:13.960,0:26:18.059
regarding what you explained of /dev/random[br]versus /dev/urandom,

0:26:18.059,0:26:21.340
the fact that on the 4.3.3 kernel, /dev/random[br]output

0:26:21.340,0:26:25.710
is identical with something from /dev/input[br]something?

0:26:25.710,0:26:26.710
Someone claimed that.

0:26:26.710,0:26:30.220
FV: I'm sorry, you have to repeat. On the[br]what?

0:26:30.220,0:26:34.489
Q: On a kernel 4.3.3, someone claims that[br]sometimes,

0:26:34.489,0:26:37.220
the output from /dev/random, or /dev/unrandom,

0:26:37.220,0:26:39.700
is identical to something that comes from[br]/dev/input,

0:26:39.700,0:26:41.999
like an input device.

0:26:41.999,0:26:45.659
FV: I'm not sure I got what system, but...

0:26:45.659,0:26:47.450
oh my god, what system?

0:26:47.450,0:26:50.590
Q: Linux, Linux 4.3.3, the guy claims.

0:26:50.590,0:26:53.559
FV: That sounds like a pretty bad bug, but...

0:26:53.559,0:26:55.259
I don't know.

0:26:55.259,0:26:57.580
If that's the case, I'm not aware of it,

0:26:57.580,0:26:59.289
because I read the kernel source,

0:26:59.289,0:27:03.590
and it's really a call to extract_entropy_user.

0:27:03.590,0:27:04.609
File a bug report, maybe?

0:27:04.609,0:27:06.159
No, I mean, I'm joking.

0:27:06.159,0:27:08.720
I would be happy to talk about this offline.

0:27:08.720,0:27:12.039
Herald: Is there another question from the[br]stream?

0:27:12.039,0:27:14.279
Q: Yes, I have two more questions.

0:27:14.279,0:27:17.039
One is: What do you think about hardware entropy[br]generators,

0:27:17.039,0:27:17.830
or hardware random generators?

0:27:17.830,0:27:22.599
FV: Aha! I have a slide for this!

0:27:22.599,0:27:29.379
laughter

0:27:29.379,0:27:32.999
So, hardware random number generators, very[br]quickly.

0:27:32.999,0:27:37.299
Some CPUs on some platforms have real random[br]number generators.

0:27:37.299,0:27:40.570
Essentially, I'm told they use electrical[br]noises

0:27:40.570,0:27:43.499
to give you actual randomness.

0:27:43.499,0:27:47.190
Linux has support for them, and, if they're[br]loaded,

0:27:47.190,0:27:50.169
they will immediately be used to refuel this[br]pool,

0:27:50.169,0:27:53.849
and they will also be used as the initialization[br]vectors

0:27:53.849,0:27:56.219
for the SHA-1 of this extraction.

0:27:56.219,0:27:59.440
So, if they're turned on, you don't have to[br]worry about them,

0:27:59.440,0:28:03.479
and they will make /dev/urandom work even[br]better.

0:28:03.479,0:28:05.019
Yep.

0:28:05.019,0:28:08.779
applause

0:28:08.779,0:28:11.149
Herald: Okay, quick question from the stream.

0:28:11.149,0:28:16.919
Q: Yeah, someone wants your opinion about[br]entropy-gathering daemons

0:28:16.919,0:28:18.200
like havege daemons.

0:28:18.200,0:28:21.210
FV: There was probably a time when they had

0:28:21.210,0:28:26.749
their reason to exist, maybe because Linux[br]implementations

0:28:26.749,0:28:30.080
of this entropy gathering was not that good,

0:28:30.080,0:28:33.309
today they don't really have reason to exist.

0:28:33.309,0:28:36.629
Herald: Okay, thank you. And microphone 4,[br]please.

0:28:36.629,0:28:40.469
Q: Hello. I wanted to ask about the early[br]boot problem.

0:28:40.469,0:28:45.919
You say that we should mix, that we should[br]save the state

0:28:45.919,0:28:51.940
of /dev/urandom, what happens if a machine[br]crashes?

0:28:51.940,0:28:54.769
Wouldn't you restart from an earlier state[br]of /dev/urandom?

0:28:54.769,0:28:59.289
FV: Hm, yeah, I think that the correct way[br]to do this is,

0:28:59.289,0:29:06.019
as soon as, even before the input is used[br]to initialize the pool,

0:29:06.019,0:29:09.409
the one from the last shutdown,

0:29:09.409,0:29:12.379
it should be deleted from the disk,

0:29:12.379,0:29:13.419
and the disk flushed.

0:29:13.419,0:29:16.849
Yes, it's kind of hard, yes.

0:29:16.849,0:29:20.359
Herald: Okay, and unfortunately we are running[br]out of time,

0:29:20.359,0:29:24.169
because we have to clear this room. And you[br]have a short announcement?

0:29:24.169,0:29:30.009
FV: Oh, yeah! Tomorrow, at 15.30, I am giving[br]a quick workshop

0:29:30.009,0:29:34.799
about how to implement a Vaudenay padding[br]oracle attack in Hall 14.

0:29:34.799,0:29:39.359
I think it doesn't take as many people as[br]are here now...

0:29:39.359,0:29:40.799
so maybe I shouldn't have said that.

0:29:40.799,0:29:44.169
Herald: Okay, then! Thanks again, Filippo,[br]for the talk.

0:29:44.169,0:29:48.291
applause

0:29:48.291,0:30:00.000
subtitles created by c3subtitles.de[br]Join, and help us!