0:00:00.000,0:00:04.010
In this segment, I want to give a few[br]examples of stream ciphers that are used in practice.

0:00:04.010,0:00:07.072
I'm gonna start with two old[br]examples that actually are not

0:00:07.072,0:00:11.017
supposed to be used in new systems.[br]But nevertheless, they're still fairly

0:00:11.017,0:00:14.164
widely used, and so I just want to mention[br]the names so that you're familiar with

0:00:14.164,0:00:19.087
these concepts. The first stream cipher I[br]want to talk about is called RC4, designed

0:00:19.087,0:00:23.429
back in 1987. And I'm only gonna give you[br]the high-level description of it, and then

0:00:23.429,0:00:27.818
we'll talk about some weaknesses of RC4[br]and leave it at that. So RC4 takes a

0:00:27.818,0:00:32.702
variable size seed, here I just gave[br]as an example where it would take 128

0:00:32.702,0:00:36.980
bits as the seed size, which would then[br]be used as the key for the stream cipher.

0:00:36.980,0:00:41.738
The first thing it does, is it expands the[br]128-bit secret key into 2,048 bits, which

0:00:41.738,0:00:46.382
are gonna be used as the internal state[br]for the generator. And then, once it's done

0:00:46.382,0:00:51.197
this expansion, it basically executes a[br]very simple loop, where every iteration of

0:00:51.197,0:00:55.898
this loop outputs one byte of output. So,[br]essentially, you can run the generator for

0:00:55.898,0:01:00.653
as long as you want, and generate one byte[br]at a time. Now RC4 is actually, as I said,

0:01:00.653,0:01:05.205
fairly popular. It's used in the HTTPS[br]protocol quite commonly actually.

0:01:05.205,0:01:11.888
These days, for example, Google uses RC4 in its[br]HTTPS. It's also used in WEP as we

0:01:11.888,0:01:15.686
discussed in the last segment, but of[br]course in WEP, it's used incorrectly and

0:01:15.686,0:01:18.861
it's completely insecure the way it's used[br]inside of WEP. So over the years,

0:01:18.861,0:01:23.886
some weaknesses have been found in RC4, and as a[br]result, it's recommended that new projects

0:01:23.886,0:01:28.793
actually not use RC4 but rather use a more[br]modern pseudo-random generator as we'll

0:01:28.793,0:01:34.059
discuss toward the end of the segment. So[br]let me just mention two of the weaknesses.

0:01:34.059,0:01:39.561
So the first one is, it's kind of bizarre[br]basically, if you look at the second byte

0:01:39.561,0:01:44.630
of the output of RC4. It turns out the[br]second byte is slightly biased. If RC4 was

0:01:44.630,0:01:49.780
completely random, the probability that the[br]second byte happens to be equal to zero

0:01:49.780,0:01:54.744
would be exactly one over 256. There are[br]256 possible bytes, the probability that

0:01:54.744,0:01:59.646
it's zero should be one over 256. It so[br]happens that for RC4 the probability is

0:01:59.646,0:02:04.486
actually two over 256, which means that if[br]you use the RC4 output to encrypt a

0:02:04.486,0:02:09.574
message the second byte is likely to not[br]be encrypted at all. In other words it'll

0:02:09.574,0:02:14.575
be XOR-ed with zero with twice the[br]probability that it's supposed to.

0:02:14.575,0:02:19.436
So two over 256, instead of one over 256.[br]And by the way I should say that there's

0:02:19.436,0:02:22.849
nothing special about the second byte. It[br]turns out the first and the third bytes

0:02:22.849,0:02:27.818
are also biased. And in fact it's now[br]recommended that if you're gonna use RC4,

0:02:27.818,0:02:32.800
what you should do is ignore basically the[br]first 256 bytes of the output and just

0:02:32.800,0:02:37.246
start using the output of the generator[br]starting from byte 257. The first couple

0:02:37.246,0:02:41.241
of bytes turned out to be biased, so you[br]just ignore them. The second attack that

0:02:41.241,0:02:48.482
was discovered is that in fact if you look[br]at a very long output of RC4 it so happens

0:02:48.482,0:02:53.863
that you're more likely to get the[br]sequence 00. In other words, you're more

0:02:53.863,0:02:58.970
likely to get sixteen bits, two bytes of[br]zero, zero, than you should. Again, if RC4

0:02:58.970,0:03:03.948
was completely random the probability of[br]seeing zero, zero would be exactly 1/256

0:03:03.948,0:03:08.556
squared. It turns out RC4 is a little[br]biased and the bias is 1/256 cubed. It

0:03:08.556,0:03:13.718
turns out this bias actually starts after[br]several gigabytes of data are produced by

0:03:13.718,0:03:18.634
RC4. But nevertheless, this is something[br]that can be used to predict the generator

0:03:18.634,0:03:23.120
and definitely it can be used to[br]distinguish the output of the generator

0:03:23.120,0:03:28.097
from a truly random sequence. Basically the[br]fact that zero, zero appears more often

0:03:28.097,0:03:32.414
than it should is the distinguisher. And[br]then in the last segment we talked about

0:03:32.414,0:03:36.313
related-key attacks that were used to[br]attack WEP, that basically say that

0:03:36.313,0:03:41.078
if one uses keys that are closely related[br]to one another then it's actually possible

0:03:41.078,0:03:45.732
to recover the root key. So these are the[br]weaknesses that are known of RC4 and, as a

0:03:45.732,0:03:50.217
result, it's recommended that new systems[br]actually not use RC4 and instead use a

0:03:50.217,0:03:54.421
modern pseudo-random generator. Okay,[br]second example I want to give you is a

0:03:54.421,0:03:59.131
badly broken stream cipher that's used for[br]encrypting DVD movies. When you buy a DVD

0:03:59.131,0:04:03.504
in the store, the actual movie is[br]encrypted using a stream cipher called the

0:04:03.504,0:04:07.933
content scrambling system, CSS. CSS turns[br]out to be a badly broken stream cipher,

0:04:07.933,0:04:12.523
and we can very easily break it, and I[br]want to show you how the attack algorithm

0:04:12.523,0:04:16.894
works. We're doing it so you can see an[br]example of an attack algorithm, but in

0:04:16.894,0:04:21.435
fact, there are many systems out there[br]that basically use this attack to decrypt

0:04:21.435,0:04:25.749
encrypted DVDs. So the CSS stream cipher[br]is based on something that hardware

0:04:25.749,0:04:30.291
designers like. It's designed to be a[br]hardware stream cipher that is supposed to

0:04:30.291,0:04:34.491
be easy to implement in hardware, and is[br]based on a mechanism called a linear

0:04:34.491,0:04:38.749
feedback shift register. So a linear[br]feedback shift register is basically a register

0:04:38.749,0:04:43.801
that consists of cells where[br]each cell contains one bit. Then basically

0:04:43.801,0:04:49.046
what happens is there are these taps into[br]certain cells, not all the cells, certain

0:04:49.046,0:04:54.134
positions are called taps. And then these[br]taps feed into an XOR and then at

0:04:54.134,0:04:59.053
every clock cycle, the shift register[br]shifts to the left. The last bit falls off

0:04:59.053,0:05:04.345
and then the first bit becomes the result[br]of this XOR. So you can see that

0:05:04.345,0:05:08.703
this is a very simple mechanism to implement, and in hardware takes very few

0:05:08.703,0:05:13.622
transistors. Just the shift right, the[br]last bit falls off and the first bit just

0:05:13.622,0:05:18.541
becomes the XOR of the previous[br]bits. So the seed for this LFSR

0:05:18.541,0:05:23.460
basically, is the initial state of the[br]LFSR.

0:05:23.650,0:05:28.538
And it is the basis of a number of stream[br]ciphers. So here are some examples. So, as

0:05:28.538,0:05:33.362
I said, DVD encryption uses two LFSRs.[br]I'll show you how that works in just a

0:05:33.362,0:05:38.060
second. GSM encryption, these are[br]algorithms called A51 and A52. And that

0:05:38.060,0:05:43.456
uses three LFSRs. Bluetooth encryption is[br]an algorithm called, E zero. These are all

0:05:43.456,0:05:48.534
stream ciphers, and that uses four LFSRs.[br]Turns out all of these are badly broken,

0:05:48.534,0:05:53.245
and actually really should not be trusted[br]for encrypting traffic, but they're all

0:05:53.245,0:05:56.705
implemented in hardware, so it's a little[br]difficult now to change what the hardware

0:05:56.705,0:06:01.047
does. But the simplest of these, CSS,[br]actually has a cute attack on it, so let

0:06:01.047,0:06:05.459
me show you how the attack works. So,[br]let's describe how CSS actually works. So,

0:06:05.459,0:06:11.073
the key for CSS is five bytes, namely 40[br]bits, five times eight is 40 bits. The

0:06:11.073,0:06:15.587
reason they had to limit themselves to[br]only 40 bits is that DVD encryption was

0:06:15.587,0:06:19.941
designed at a time where U.S. Export[br]regulations only allowed for export of

0:06:19.941,0:06:25.086
crpyto algorithms where the key was[br]only 40 bits. So the designers of CSS were

0:06:25.086,0:06:30.206
already limited to very, very short keys.[br]Just 40 bit keys. So, their design works

0:06:30.206,0:06:35.398
as follows. Basically, CSS uses two[br]LFSR's. One is a 17-bit LFSR. In other words,

0:06:35.398,0:06:40.806
the register contains[br]17 bits. And the other one is a 25-bit LFSR,

0:06:40.806,0:06:46.647
it's a little bit longer, 25-bit[br]LFSR. And the way these LFSRs are seeded

0:06:46.647,0:06:51.870
is as follows. So the key for the[br]encryption, basically looks as follows.

0:06:51.870,0:06:57.669
You start off with a one, and you concatenate to it the first two bytes of

0:06:57.669,0:07:02.947
the key. And that's the initial state of the LFSR.

0:07:02.947,0:07:08.256
And then the second LFSR basically is intitialized the same way.

0:07:08.256,0:07:14.012
One concatenated the last three bytes of[br]the key. And that's

0:07:14.012,0:07:19.889
loaded into the initial state of the LFSR.[br]You can see that the first two bytes are

0:07:19.889,0:07:25.411
sixteen bits, plus leading one, that's[br]seventeen bits overall, whereas the second

0:07:25.411,0:07:31.217
LFSR is 24 bits plus one which is 25 bits.[br]And you notice we used all five bits of

0:07:31.217,0:07:36.881
the key. So then these LFSRs are basically[br]run for eight cycles, so they generate

0:07:36.881,0:07:42.333
eight bits of output. And then they go[br]through this adder that does basically

0:07:42.333,0:07:48.197
addition modulo 256. Yeah so this is an[br]addition box, modulo 256. There's one more

0:07:48.197,0:07:54.325
technical thing that happens. In fact let's[br]actually—also added is the carry from the

0:07:54.325,0:07:59.723
previous block. But that is not so[br]important. That's a detail that's not so

0:07:59.723,0:08:04.761
relevant. OK, so every block, you notice[br]we're doing addition modulo 256 and

0:08:04.761,0:08:09.982
we're ignoring the carry, but the carry is[br]basically added as a zero or a one to the

0:08:09.982,0:08:15.147
addition of the next block. Okay? And then[br]basically this output one byte per round.

0:08:15.147,0:08:20.411
Okay, and then this byte is then of course[br]used, XOR-ed with the appropriate

0:08:20.411,0:08:25.167
byte of the movie that's being encrypted.[br]Okay, so it's a very simple stream

0:08:25.167,0:08:29.986
cipher, it takes very little hardware to[br]implement. It will run fast, even on very

0:08:29.986,0:08:35.830
cheap hardware and it will encrypt movies.[br]So it turns out this is easy to break

0:08:35.830,0:08:41.222
in time roughly two to the seventeen. Now let me show you how.

0:08:41.222,0:08:45.734
So suppose you[br]intercept the movies, so here we have an

0:08:45.734,0:08:50.647
encrypted movie that you want to decrypt.[br]So let's say that this is all encrypted so

0:08:50.647,0:08:55.279
you have no idea what's inside of here.[br]However, it so happens that just because

0:08:55.279,0:08:59.970
DVD encryption is using MPEG files, it so[br]happens if you know of a prefix of the

0:08:59.970,0:09:04.250
plaintext, let's just say maybe this is[br]twenty bytes. Well, we know if you

0:09:04.250,0:09:08.589
XOR these two things together, so in other words, you do the XOR here,

0:09:08.589,0:09:13.523
what you'll get is the initial segment of the PRG. So, you'll get the

0:09:13.523,0:09:18.472
first twenty bytes of the output of CSS,[br]the output of this PRG. Okay, so now

0:09:18.472,0:09:23.986
here's what we're going to do. So we have[br]the first twenty bytes of the output. Now

0:09:23.986,0:09:31.405
we do the following. We try all two to the[br]seventeen possible values of the first

0:09:31.405,0:09:37.088
LFSR. Okay? So two to the seventeen[br]possible values. So for each value, so for

0:09:37.088,0:09:42.622
each of these two to the seventeen initial[br]values of the LFSR, we're gonna run the

0:09:42.622,0:09:47.953
LFSR for twenty bytes, okay? So we'll[br]generate twenty bytes of outputs from this

0:09:47.953,0:09:53.284
first LFSR, assuming—for each one of the[br]two to the seventeen possible settings.

0:09:53.284,0:09:58.615
Now, remember we have the full output of[br]the CSS system. So what we can do is we

0:09:58.615,0:10:03.814
can take this output that we have. And[br]subtract it from the twenty bites that we

0:10:03.814,0:10:08.928
got from the first LFSR, and if in fact our[br]guess for the initial state of the first

0:10:08.928,0:10:14.042
LFSR is correct, what we should get[br]is the first twenty-byte output of the

0:10:14.042,0:10:19.222
second LFSR. Right? Because that's by[br]definition what the output of the CSS

0:10:19.222,0:10:24.501
system is. Now, it turns out that looking[br]at a 20-byte sequence, it's very easy

0:10:24.501,0:10:29.763
to tell whether this 20-byte sequence[br]came from a 25-bit LFSR or not. If it

0:10:29.763,0:10:33.561
didn't, then we know that our guess[br]for the 17-bit LFSR was

0:10:33.561,0:10:37.416
incorrect and then we move on to the next[br]guess for the 17-bit LFSR and

0:10:37.416,0:10:41.904
the next guess and so on and so forth.[br]Until eventually we hit the right initial

0:10:41.904,0:10:46.937
state for the 17-bit LFSR, and[br]then we'll actually get, we'll see that

0:10:46.937,0:10:51.969
the 20 bytes that we get as the[br]candidate output for the 25-bit LFSR is

0:10:51.969,0:10:56.936
in fact a possible output for a 25-bit LFSR. And then, not only will we have

0:10:56.936,0:11:02.164
learned the correct initial state for the[br]17-bit LFSR, we will have also

0:11:02.164,0:11:07.523
learned the correct initial state of the[br]25-bit LFSR. And then we can predict the

0:11:07.523,0:11:12.796
remaining outputs of CSS, and of course,[br]using that, we can then decrypt the rest of

0:11:12.796,0:11:17.565
the movie. We can actually recover the[br]remaining plaintext. Okay. This is

0:11:17.565,0:11:22.335
things that we talked about before. So, I[br]said this a little quick, but hopefully,

0:11:22.335,0:11:27.331
it was clear. We're also going to be doing[br]a homework exercise on this type of stream

0:11:27.331,0:11:31.444
ciphers and you'll kind of get the point[br]of how these attack algorithms

0:11:31.444,0:11:36.018
work. And I should mention that there are[br]many open-source systems now that actually

0:11:36.018,0:11:41.453
use this method to decrypt CSS-encrypted[br]data. Okay, so now that we've seen two

0:11:41.453,0:11:45.888
weak examples, let's move on to better[br]examples, and in particular the better

0:11:45.888,0:11:49.370
pseudo-random generators come from what's[br]called the eStream Project. This is a

0:11:49.370,0:11:55.556
project that concluded in 2008, and they[br]qualify basically five different stream

0:11:55.556,0:12:00.207
ciphers, but here I want to present just[br]one. So first of all the parameters for

0:12:00.207,0:12:04.029
these stream ciphers are a little[br]different than what we're used to. So these

0:12:04.029,0:12:08.340
stream ciphers as normal they have a seed.[br]But in addition they also have, what's

0:12:08.340,0:12:12.821
called a nonce and we'll see what a[br]nonce is used for in just a minute. So

0:12:12.821,0:12:17.487
they take two inputs a seed and a nonce.[br]We'll see what the nonce is used for in

0:12:17.487,0:12:21.274
just a second. And the of course they[br]produce a very large output, so n here is

0:12:21.274,0:12:26.603
much, much, much bigger than s. Now, when[br]I say nonce, what I mean is a value that's

0:12:26.603,0:12:31.218
never going to repeat as long as the key[br]is fixed. And I'll explain that in more

0:12:31.218,0:12:35.400
detail in just a second. But for now, just[br]think of it as a unique value that never

0:12:35.400,0:12:40.527
repeats as long as the key is the same.[br]And so of course once you have this PRG,

0:12:40.527,0:12:45.357
you would encrypt, you get a stream cipher[br]just as before, except now as you see, the

0:12:45.357,0:12:49.955
PRG takes as input both the key and the[br]nonce. And the property of the nonce is

0:12:49.955,0:12:56.350
that the pair, k comma r, so the key comma[br]the nonce, is never—never repeats. It's

0:12:56.350,0:13:03.096
never used more than once. So the bottom[br]line is that you can reuse the key, reuse

0:13:03.096,0:13:09.710
the key, because the nonce makes the[br]pair unique, because k and r are only

0:13:09.710,0:13:16.135
used once. I'll say they're unique. Okay[br]so this nonce is kind of a cute trick that

0:13:16.135,0:13:21.541
saves us the trouble of moving to a new[br]key every time. Okay, so the particular

0:13:21.541,0:13:26.000
example from the eStream that I want to[br]show you is called Salsa twenty. It's a

0:13:26.000,0:13:30.292
stream cipher that's designed for both[br]software implementations and hardware

0:13:30.292,0:13:33.385
implementations. It's kind of interesting.[br]You realize that some stream ciphers are

0:13:33.385,0:13:38.763
designed for software, like RC4.[br]Everything it does is designed to make

0:13:38.763,0:13:42.689
software implementation run fast, whereas[br]other stream ciphers are designed for

0:13:42.689,0:13:48.143
hardware, like CSS, using an LFSR that's[br]particularly designed to make hardware

0:13:48.143,0:13:50.963
implementations very cheap. It's also, the[br]nice thing about that is that it's

0:13:50.963,0:13:55.008
designed so that it's both easy to[br]implement it in hardware and its software

0:13:55.008,0:13:59.747
implementation is also very fast. So let[br]me explain how Salsa works. Well, Salsa

0:13:59.747,0:14:05.130
takes either 128 or 256-bit keys. I'll[br]only explain the 128-bit version of Salsa.

0:14:05.130,0:14:11.244
So this is the seed. And then it also[br]takes a nonce, just as before, which

0:14:11.244,0:14:15.425
happens to be 64 bits. And then it'll[br]generate a large output. Now, how does it

0:14:15.425,0:14:21.060
actually work? Well, the function itself[br]is defined as follows. Basically, given

0:14:21.060,0:14:26.378
the key and the nonce, it will generate a[br]very long, well, a long pseudorandom

0:14:26.378,0:14:31.222
sequence, as long as necessary. And it'll do[br]it by using this function that I'll denote by

0:14:31.222,0:14:35.653
H. This function H takes three inputs.[br]Basically the key. Well, the seed k,

0:14:35.653,0:14:40.498
the nonce r, and then a counter that[br]increments from step to step. So it goes

0:14:40.498,0:14:45.263
from zero to one, two, three, four as long as[br]we need it to be. Okay? So basically,

0:14:45.263,0:14:49.956
by evaluating this H on this k r, but using[br]this incrementing counter, we can get a

0:14:49.956,0:14:54.882
sequence that's as long as we want. So all[br]I have to do is describe how this function

0:14:54.882,0:14:59.460
H works. Now, let me do that here for you.[br]The way it works is as follows. Well, we

0:14:59.460,0:15:04.693
start off by expanding the states into[br]something quite large which is 64 bytes

0:15:04.693,0:15:10.156
long, and we do that as follows. Basically[br]we stick a constant at the beginning, so

0:15:10.156,0:15:15.552
there's tao zero, these are four bytes,[br]it's a four byte constant, so the spec for

0:15:15.552,0:15:20.611
Salsa basically gives you the value for[br]tao zero. Then we put k in which is

0:15:20.611,0:15:25.467
sixteen bytes. Then we put another[br]constant. Again, this is four bytes. And

0:15:25.467,0:15:30.795
as I said, the spec basically specifies[br]what this fixed constant is. Then we put

0:15:30.795,0:15:37.435
the nonce, which is eight bytes. Then we[br]put the index. This is the counter zero,

0:15:37.435,0:15:43.063
one, two, three, four, which is another[br]eight bytes. Then we put another constant

0:15:43.063,0:15:49.056
tau two, which is another four bytes.[br]Then we put the key again, this is another

0:15:49.056,0:15:54.714
sixteen bytes. And then finally we put the[br]third constant, tau three, which is

0:15:54.714,0:15:59.948
another four bytes. Okay so as I said, if you[br]sum these up, you see that you get 64

0:15:59.948,0:16:05.249
bytes. So basically we've expanded the key[br]and the nonce and the counter into 64

0:16:05.249,0:16:10.886
bytes. Basically the key is repeated twice[br]I guess. And then what we do is we apply a

0:16:10.886,0:16:16.321
function, I'll call this functional little h.[br]Okay, so we apply this function, little h.

0:16:16.321,0:16:21.659
And this is a function that's one to one[br]so it maps 64 bytes to 64 bytes. It's a

0:16:21.659,0:16:26.005
completely invertible function, okay? So[br]this function h is, as I say, it's an

0:16:26.005,0:16:30.260
invertable function. So given the input[br]you can get the output and given the

0:16:30.260,0:16:34.906
output you can go back to the input. And[br]it's designed specifically so it's a- easy

0:16:34.906,0:16:39.553
to implement in hardware and b- on an x86,[br]it's extremely easy to implement because

0:16:39.553,0:16:44.199
x86 has this SSE2 instruction set which[br]supports all the operations you need to do

0:16:44.199,0:16:48.622
for this function. It's very, very fast.[br]As a result, Salsa has a very fast stream

0:16:48.622,0:16:52.764
cipher. And then it does this basically[br]again and again. So it applies this

0:16:52.764,0:16:57.744
function h again and it gets another 64[br]bytes. And so on and so forth, basically

0:16:57.744,0:17:05.318
it does this ten times. Okay so the whole[br]thing here, say repeats ten times, so

0:17:05.318,0:17:17.961
basically apply h ten times. And then by[br]itself, this is actually not quite random.

0:17:17.961,0:17:22.144
It's not gonna look random because like we[br]said, H is completely invertable. So given

0:17:22.144,0:17:25.521
this final output, it's very easy to[br]just invert h and then go back to the original

0:17:25.521,0:17:31.831
inputs and then test that the input has[br]the right structure. So you do one more

0:17:31.831,0:17:36.979
thing, which is to basically XOR the[br]inputs and the final outputs. Actually,

0:17:36.979,0:17:42.405
sorry. It's not an XOR. It's actually an[br]addition. So you do an addition word by

0:17:42.405,0:17:47.762
word. So if there are 64 bytes, you do a[br]word-by-word addition four bytes at a

0:17:47.762,0:17:52.980
time, and finally you get the 64-byte[br]output, and that's it. That's the whole

0:17:52.980,0:17:57.175
pseudo-random generator. So that, that's[br]the whole function, little h. And as I

0:17:57.175,0:18:01.758
explained, this whole construction here is[br]the function big H. And then you evaluate

0:18:01.758,0:18:06.009
big H by incrementing the counter I from[br]zero, one, two, three onwards. And that

0:18:06.009,0:18:10.408
will give you a pseudo-random sequence[br]that's as long as you need it to be. And

0:18:10.408,0:18:15.325
basically, there are no signifigant[br]attacks on this. This has security that's

0:18:15.325,0:18:20.371
very close to two to the 128. We'll see[br]what that means more precisely later on.

0:18:20.371,0:18:25.417
It's a very fast stream cipher, both in[br]hardware and in software. And, as far as

0:18:25.417,0:18:30.431
we can tell, it seems to be unpredictable[br]as required for a stream cipher. So I

0:18:30.431,0:18:34.797
should say that the eStream project[br]actually has five stream ciphers like

0:18:34.797,0:18:39.395
this. I only chose Salsa 'cause I think[br]it's the most elegant. But I can give you

0:18:39.395,0:18:44.053
some performance numbers here. So you can[br]see, these are performance numbers on a

0:18:44.053,0:18:48.768
2.2 gigahertz, you know, x86 type machine.[br]And you can see that RC4 actually is the

0:18:48.768,0:18:53.017
slowest. Because essentially, well it[br]doesn't really take advantage of the

0:18:53.017,0:18:57.475
hardware. It only does byte operations.[br]And so there's a lot of wasted cycles that

0:18:57.475,0:19:01.182
aren't being used. But the E-Stream[br]candidates, both Salsa and other

0:19:01.182,0:19:05.202
candidate called Sosemanuk. I should say these[br]are eStream finalists. These are

0:19:05.202,0:19:09.588
actually stream ciphers that are approved[br]by the eStream project. You can see that

0:19:09.588,0:19:13.712
they have achieved a significant rate.[br]This is 643 megabytes per second on this

0:19:13.712,0:19:18.150
architecture, more than enough for a movie[br]and these are actually quite impressive

0:19:18.150,0:19:22.432
rates. And so now you've seen examples of[br]two old stream ciphers that shouldn't be

0:19:22.432,0:19:26.661
used, including attacks on those stream ciphers.[br]You've seen what the modern stream ciphers

0:19:26.661,0:19:30.480
look like with this nonce. And you[br]see the performance numbers for these

0:19:30.480,0:19:34.546
modern stream ciphers so if you happen to[br]need a stream cipher you could use one of

0:19:34.546,0:19:37.991
the eStream finalists. In particular you[br]could use something like Salsa.