In this segment, I want to give a few examples of stream ciphers that are used in practice.

I'm gonna start with two old examples that actually are not

supposed to be used in new systems. But nevertheless, they're still fairly

widely used, and so I just want to mention the names so that you're familiar with

these concepts. The first stream cipher I want to talk about is called RC4, designed

back in 1987. And I'm only gonna give you the high-level description of it, and then

we'll talk about some weaknesses of RC4 and leave it at that. So RC4 takes a

variable size seed, here I just gave as an example where it would take 128

bits as the seed size, which would then be used as the key for the stream cipher.

The first thing it does, is it expands the 128-bit secret key into 2,048 bits, which

are gonna be used as the internal state for the generator. And then, once it's done

this expansion, it basically executes a very simple loop, where every iteration of

this loop outputs one byte of output. So, essentially, you can run the generator for

as long as you want, and generate one byte at a time. Now RC4 is actually, as I said,

fairly popular. It's used in the HTTPS protocol quite commonly actually.

These days, for example, Google uses RC4 in its HTTPS. It's also used in WEP as we

discussed in the last segment, but of course in WEP, it's used incorrectly and

it's completely insecure the way it's used inside of WEP. So over the years,

some weaknesses have been found in RC4, and as a result, it's recommended that new projects

actually not use RC4 but rather use a more modern pseudo-random generator as we'll

discuss toward the end of the segment. So let me just mention two of the weaknesses.

So the first one is, it's kind of bizarre basically, if you look at the second byte

of the output of RC4. It turns out the second byte is slightly biased. If RC4 was

completely random, the probability that the second byte happens to be equal to zero

would be exactly one over 256. There are 256 possible bytes, the probability that

it's zero should be one over 256. It so happens that for RC4 the probability is

actually two over 256, which means that if you use the RC4 output to encrypt a

message the second byte is likely to not be encrypted at all. In other words it'll

be XOR-ed with zero with twice the probability that it's supposed to.

So two over 256, instead of one over 256. And by the way I should say that there's

nothing special about the second byte. It turns out the first and the third bytes

are also biased. And in fact it's now recommended that if you're gonna use RC4,

what you should do is ignore basically the first 256 bytes of the output and just

start using the output of the generator starting from byte 257. The first couple

of bytes turned out to be biased, so you just ignore them. The second attack that

was discovered is that in fact if you look at a very long output of RC4 it so happens

that you're more likely to get the sequence 00. In other words, you're more

likely to get sixteen bits, two bytes of zero, zero, than you should. Again, if RC4

was completely random the probability of seeing zero, zero would be exactly 1/256

squared. It turns out RC4 is a little biased and the bias is 1/256 cubed. It

turns out this bias actually starts after several gigabytes of data are produced by

RC4. But nevertheless, this is something that can be used to predict the generator

and definitely it can be used to distinguish the output of the generator

from a truly random sequence. Basically the fact that zero, zero appears more often

than it should is the distinguisher. And then in the last segment we talked about

related-key attacks that were used to attack WEP, that basically say that

if one uses keys that are closely related to one another then it's actually possible

to recover the root key. So these are the weaknesses that are known of RC4 and, as a

result, it's recommended that new systems actually not use RC4 and instead use a

modern pseudo-random generator. Okay, second example I want to give you is a

badly broken stream cipher that's used for encrypting DVD movies. When you buy a DVD

in the store, the actual movie is encrypted using a stream cipher called the

content scrambling system, CSS. CSS turns out to be a badly broken stream cipher,

and we can very easily break it, and I want to show you how the attack algorithm

works. We're doing it so you can see an example of an attack algorithm, but in

fact, there are many systems out there that basically use this attack to decrypt

encrypted DVDs. So the CSS stream cipher is based on something that hardware

designers like. It's designed to be a hardware stream cipher that is supposed to

be easy to implement in hardware, and is based on a mechanism called a linear

feedback shift register. So a linear feedback shift register is basically a register

that consists of cells where each cell contains one bit. Then basically

what happens is there are these taps into certain cells, not all the cells, certain

positions are called taps. And then these taps feed into an XOR and then at

every clock cycle, the shift register shifts to the left. The last bit falls off

and then the first bit becomes the result of this XOR. So you can see that

this is a very simple mechanism to implement, and in hardware takes very few

transistors. Just the shift right, the last bit falls off and the first bit just

becomes the XOR of the previous bits. So the seed for this LFSR

basically, is the initial state of the LFSR.

And it is the basis of a number of stream ciphers. So here are some examples. So, as

I said, DVD encryption uses two LFSRs. I'll show you how that works in just a

second. GSM encryption, these are algorithms called A51 and A52. And that

uses three LFSRs. Bluetooth encryption is an algorithm called, E zero. These are all

stream ciphers, and that uses four LFSRs. Turns out all of these are badly broken,

and actually really should not be trusted for encrypting traffic, but they're all

implemented in hardware, so it's a little difficult now to change what the hardware

does. But the simplest of these, CSS, actually has a cute attack on it, so let

me show you how the attack works. So, let's describe how CSS actually works. So,

the key for CSS is five bytes, namely 40 bits, five times eight is 40 bits. The

reason they had to limit themselves to only 40 bits is that DVD encryption was

designed at a time where U.S. Export regulations only allowed for export of

crpyto algorithms where the key was only 40 bits. So the designers of CSS were

already limited to very, very short keys. Just 40 bit keys. So, their design works

as follows. Basically, CSS uses two LFSR's. One is a 17-bit LFSR. In other words,

the register contains 17 bits. And the other one is a 25-bit LFSR,

it's a little bit longer, 25-bit LFSR. And the way these LFSRs are seeded

is as follows. So the key for the encryption, basically looks as follows.

You start off with a one, and you concatenate to it the first two bytes of

the key. And that's the initial state of the LFSR.

And then the second LFSR basically is intitialized the same way.

One concatenated the last three bytes of the key. And that's

loaded into the initial state of the LFSR. You can see that the first two bytes are

sixteen bits, plus leading one, that's seventeen bits overall, whereas the second

LFSR is 24 bits plus one which is 25 bits. And you notice we used all five bits of

the key. So then these LFSRs are basically run for eight cycles, so they generate

eight bits of output. And then they go through this adder that does basically

addition modulo 256. Yeah so this is an addition box, modulo 256. There's one more

technical thing that happens. In fact let's actually—also added is the carry from the

previous block. But that is not so important. That's a detail that's not so

relevant. OK, so every block, you notice we're doing addition modulo 256 and

we're ignoring the carry, but the carry is basically added as a zero or a one to the

addition of the next block. Okay? And then basically this output one byte per round.

Okay, and then this byte is then of course used, XOR-ed with the appropriate

byte of the movie that's being encrypted. Okay, so it's a very simple stream

cipher, it takes very little hardware to implement. It will run fast, even on very

cheap hardware and it will encrypt movies. So it turns out this is easy to break

in time roughly two to the seventeen. Now let me show you how.

So suppose you intercept the movies, so here we have an

encrypted movie that you want to decrypt. So let's say that this is all encrypted so

you have no idea what's inside of here. However, it so happens that just because

DVD encryption is using MPEG files, it so happens if you know of a prefix of the

plaintext, let's just say maybe this is twenty bytes. Well, we know if you

XOR these two things together, so in other words, you do the XOR here,

what you'll get is the initial segment of the PRG. So, you'll get the

first twenty bytes of the output of CSS, the output of this PRG. Okay, so now

here's what we're going to do. So we have the first twenty bytes of the output. Now

we do the following. We try all two to the seventeen possible values of the first

LFSR. Okay? So two to the seventeen possible values. So for each value, so for

each of these two to the seventeen initial values of the LFSR, we're gonna run the

LFSR for twenty bytes, okay? So we'll generate twenty bytes of outputs from this

first LFSR, assuming—for each one of the two to the seventeen possible settings.

Now, remember we have the full output of the CSS system. So what we can do is we

can take this output that we have. And subtract it from the twenty bites that we

got from the first LFSR, and if in fact our guess for the initial state of the first

LFSR is correct, what we should get is the first twenty-byte output of the

second LFSR. Right? Because that's by definition what the output of the CSS

system is. Now, it turns out that looking at a 20-byte sequence, it's very easy

to tell whether this 20-byte sequence came from a 25-bit LFSR or not. If it

didn't, then we know that our guess for the 17-bit LFSR was

incorrect and then we move on to the next guess for the 17-bit LFSR and

the next guess and so on and so forth. Until eventually we hit the right initial

state for the 17-bit LFSR, and then we'll actually get, we'll see that

the 20 bytes that we get as the candidate output for the 25-bit LFSR is

in fact a possible output for a 25-bit LFSR. And then, not only will we have

learned the correct initial state for the 17-bit LFSR, we will have also

learned the correct initial state of the 25-bit LFSR. And then we can predict the

remaining outputs of CSS, and of course, using that, we can then decrypt the rest of

the movie. We can actually recover the remaining plaintext. Okay. This is

things that we talked about before. So, I said this a little quick, but hopefully,

it was clear. We're also going to be doing a homework exercise on this type of stream

ciphers and you'll kind of get the point of how these attack algorithms

work. And I should mention that there are many open-source systems now that actually

use this method to decrypt CSS-encrypted data. Okay, so now that we've seen two

weak examples, let's move on to better examples, and in particular the better

pseudo-random generators come from what's called the eStream Project. This is a

project that concluded in 2008, and they qualify basically five different stream

ciphers, but here I want to present just one. So first of all the parameters for

these stream ciphers are a little different than what we're used to. So these

stream ciphers as normal they have a seed. But in addition they also have, what's

called a nonce and we'll see what a nonce is used for in just a minute. So

they take two inputs a seed and a nonce. We'll see what the nonce is used for in

just a second. And the of course they produce a very large output, so n here is

much, much, much bigger than s. Now, when I say nonce, what I mean is a value that's

never going to repeat as long as the key is fixed. And I'll explain that in more

detail in just a second. But for now, just think of it as a unique value that never

repeats as long as the key is the same. And so of course once you have this PRG,

you would encrypt, you get a stream cipher just as before, except now as you see, the

PRG takes as input both the key and the nonce. And the property of the nonce is

that the pair, k comma r, so the key comma the nonce, is never—never repeats. It's

never used more than once. So the bottom line is that you can reuse the key, reuse

the key, because the nonce makes the pair unique, because k and r are only

used once. I'll say they're unique. Okay so this nonce is kind of a cute trick that

saves us the trouble of moving to a new key every time. Okay, so the particular

example from the eStream that I want to show you is called Salsa twenty. It's a

stream cipher that's designed for both software implementations and hardware

implementations. It's kind of interesting. You realize that some stream ciphers are

designed for software, like RC4. Everything it does is designed to make

software implementation run fast, whereas other stream ciphers are designed for

hardware, like CSS, using an LFSR that's particularly designed to make hardware

implementations very cheap. It's also, the nice thing about that is that it's

designed so that it's both easy to implement it in hardware and its software

implementation is also very fast. So let me explain how Salsa works. Well, Salsa

takes either 128 or 256-bit keys. I'll only explain the 128-bit version of Salsa.

So this is the seed. And then it also takes a nonce, just as before, which

happens to be 64 bits. And then it'll generate a large output. Now, how does it

actually work? Well, the function itself is defined as follows. Basically, given

the key and the nonce, it will generate a very long, well, a long pseudorandom

sequence, as long as necessary. And it'll do it by using this function that I'll denote by

H. This function H takes three inputs. Basically the key. Well, the seed k,

the nonce r, and then a counter that increments from step to step. So it goes

from zero to one, two, three, four as long as we need it to be. Okay? So basically,

by evaluating this H on this k r, but using this incrementing counter, we can get a

sequence that's as long as we want. So all I have to do is describe how this function

H works. Now, let me do that here for you. The way it works is as follows. Well, we

start off by expanding the states into something quite large which is 64 bytes

long, and we do that as follows. Basically we stick a constant at the beginning, so

there's tao zero, these are four bytes, it's a four byte constant, so the spec for

Salsa basically gives you the value for tao zero. Then we put k in which is

sixteen bytes. Then we put another constant. Again, this is four bytes. And

as I said, the spec basically specifies what this fixed constant is. Then we put

the nonce, which is eight bytes. Then we put the index. This is the counter zero,

one, two, three, four, which is another eight bytes. Then we put another constant

tau two, which is another four bytes. Then we put the key again, this is another

sixteen bytes. And then finally we put the third constant, tau three, which is

another four bytes. Okay so as I said, if you sum these up, you see that you get 64

bytes. So basically we've expanded the key and the nonce and the counter into 64

bytes. Basically the key is repeated twice I guess. And then what we do is we apply a

function, I'll call this functional little h. Okay, so we apply this function, little h.

And this is a function that's one to one so it maps 64 bytes to 64 bytes. It's a

completely invertible function, okay? So this function h is, as I say, it's an

invertable function. So given the input you can get the output and given the

output you can go back to the input. And it's designed specifically so it's a- easy

to implement in hardware and b- on an x86, it's extremely easy to implement because

x86 has this SSE2 instruction set which supports all the operations you need to do

for this function. It's very, very fast. As a result, Salsa has a very fast stream

cipher. And then it does this basically again and again. So it applies this

function h again and it gets another 64 bytes. And so on and so forth, basically

it does this ten times. Okay so the whole thing here, say repeats ten times, so

basically apply h ten times. And then by itself, this is actually not quite random.

It's not gonna look random because like we said, H is completely invertable. So given

this final output, it's very easy to just invert h and then go back to the original

inputs and then test that the input has the right structure. So you do one more

thing, which is to basically XOR the inputs and the final outputs. Actually,

sorry. It's not an XOR. It's actually an addition. So you do an addition word by

word. So if there are 64 bytes, you do a word-by-word addition four bytes at a

time, and finally you get the 64-byte output, and that's it. That's the whole

pseudo-random generator. So that, that's the whole function, little h. And as I

explained, this whole construction here is the function big H. And then you evaluate

big H by incrementing the counter I from zero, one, two, three onwards. And that

will give you a pseudo-random sequence that's as long as you need it to be. And

basically, there are no signifigant attacks on this. This has security that's

very close to two to the 128. We'll see what that means more precisely later on.

It's a very fast stream cipher, both in hardware and in software. And, as far as

we can tell, it seems to be unpredictable as required for a stream cipher. So I

should say that the eStream project actually has five stream ciphers like

this. I only chose Salsa 'cause I think it's the most elegant. But I can give you

some performance numbers here. So you can see, these are performance numbers on a

2.2 gigahertz, you know, x86 type machine. And you can see that RC4 actually is the

slowest. Because essentially, well it doesn't really take advantage of the

hardware. It only does byte operations. And so there's a lot of wasted cycles that

aren't being used. But the E-Stream candidates, both Salsa and other

candidate called Sosemanuk. I should say these are eStream finalists. These are

actually stream ciphers that are approved by the eStream project. You can see that

they have achieved a significant rate. This is 643 megabytes per second on this

architecture, more than enough for a movie and these are actually quite impressive

rates. And so now you've seen examples of two old stream ciphers that shouldn't be

used, including attacks on those stream ciphers. You've seen what the modern stream ciphers

look like with this nonce. And you see the performance numbers for these

modern stream ciphers so if you happen to need a stream cipher you could use one of

the eStream finalists. In particular you could use something like Salsa.