>>: Okay. Thank you, everybody. I've got to say, I
was here just a few minutes early, at a little bit
before 1:30, and I was worried that the room was so
empty, but I'm really glad to see so many people here
live. Please keep it up. I think it helps kind of
get these programs and classes and talks continuing
and having people attend in person a well as watch
online just motivates us to do this again.
There is a sign-up form in the back for those of you
who are gunning for the, especially gunning for the
attending all six sessions for a free door prize,
I'm -- I assure you it will be worth it enough to
schlep over here as opposed to viewing it online,
although that link will be available every time.
>>:
Roadster.
>>: Yeah, it's not quite the roadster. It's not a
new car or anything. We do have a limited budget.
So ->>:
Tesla.
>>: And as we reorg, I'm really, I'm kind of
shielding that budget from going away, but there will
be something at the end of the six sessions. I'm
looking forward to them in some ways being done so we
can spend the money and not having it taken away from
us.
So with that, Josh Benaloh is, I think, those of you
who have seen this presentation before, well
qualified to be doing this session. I'm really happy
that he's volunteered to do this. Senior
cryptographer, Microsoft Research. Every time I see
him, I want to give him a round of applause because
of how viable I think his talks are. So if we could
give him a round of applause as we welcome him for a
third time.
[applause]
>> Josh Benaloh: Thank you, Justin. Now you're
starting to embarrass me. Okay. So just before we
get into the new asymmetric side today, I want to
just clear up a few things that came up last time.
So a few leftovers. One is, I was asked about some
details about the SHA-2 functions, and I said last
time that I thought all of the SHA-2 functions ran
for 64 rounds and I checked and it turns out that,
although you might remember -- probably wouldn't
remember -- the shah one runs for 80 rounds. SHA-256
runs for 64 rounds, but I hadn't realized, SHA-2 -SHA-512, which is almost exactly the same as SHA-256
except that it's on 64-bit words instead of 32-bit
words, actually runs for 80 rounds. And in fact,
there are some trimmed down versions of all these
functions that are specified. So there's a SHA-224,
for instance, which is just SHA-256 truncated.
There's a SHA-378, which is just -- sorry -SHA-384 -- my bad. SHA-384 is SHA-512 truncated.
There is actually a SHA-512/256 standardized, which
is run SHA-512 for the full 80 rounds and then
truncated down to 256 bits. So apologize for that.
Another thing, I guess it was Morgan, you asked about
weaknesses in GCM, the Galois counter cipher mode,
and I didn't know of substantial ones and when I
checked, I didn't find substantial ones. The only
things that I found are theoretical breaks, and maybe
it's worth taking a minute to explain theoretical
breaks any other terms, but it is exists there.
So, for instance, AES, the cipher we talked a lot
about last time, the block cipher that almost
everybody uses, in theory is broken. And what that
means is an attack has been discovered. It was
actually discovered here by one of our post-docs a
few years ago that said it's supposed to take -- to
find the key is supposed to not be possible with
anything less time than an exhaustive search. Just
go through all possible keys till you find the right
one.
So if you have a 256-bit key, it should take, on
average, two to the 255 steps to find the key. It's
been discovered that with a little bit of work you
can shave a bit or two off of it. So you could find
a 256-bit AES key in about between 250 -- two to the
250th, three in to the 254 steps.
Now, does that matter in practice when the NSA can
search through about two to the 80 keys maybe? Not
in the slightest, but technically it's broken. GCM
mode is technically broken in the same way. There
are some theoretical attacks, but I haven't found any
practical attacks of any importance, any
significance.
And just other thing I wanted to mention, just sort
of as an aside. Jonathan, a few days after my last
lecture, sent me mail about Heartbleed. So I've got
to do a mea culpa, because what I told him was, oh,
this will blow over by the next class. There are
hundreds of things just like it or almost as bad.
Okay. It hasn't blown over. It's still there. I
don't know exactly why this one's got such legs. I
will say it's not a crypto issue at all, right? This
is an issue of memory bounds being miscoded so that
an attacker could get into the memory which might
have a key sitting around, and the key is extracted
just in that way.
Remember where we talked about the very first session
of Kirchhoff's laws. All we're doing with
cryptography is reducing the problem -- well, not all
we're doing, but a lot of what we're doing is
reducing the problem of protecting a big pile of data
to the problem of protecting a key, and then if you
don't protect the key, well, hey, that's your
problem.
Now, that said, I'm going to at the very end today
show a little bit about cryptographic problems in
protecting a key and things that can come. So it's
not just your problem. Other people's problems,
but ->>: Those other people with HSMs for their SSL keys
are super happy now.
>> Josh Benaloh: For instance, yes. There is -there are things that protect things better, but
there are crypto issues. And when I get to talking a
little bit about the digital signature algorithm DSA,
you'll see some of the cases where it can go bad.
But anyway, here are things we talked about last
time. If there are any questions, catch me later
because I want to move into new stuff. Today I want
to talk asymmetric stuff. So the symmetric stuff is
all you're using the same key to encrypt and decrypt
and similar types of functions.
With asymmetric crypto, you have a public key, which
is used for encryption. It's different from the
private key used for decryption. Or in the case of
signing, you have a private key used for signing
something and a public key, a different public key
used to validate a signature. Okay?
So this is a very different thing and you can see how
much more powerful it can be if you can do this. So
how do we did it? Well, here you might remember from
the first session this fundamental equation that we
talked about that so much of asymmetric cryptography
is based on. We talked about the case where Z is
unknown, that you can do a calculation like this even
with very large numbers by this trick of square and
multiply.
Basically you just compute Y, Y squared, Y to the
fourth as far as you need to go and you multiply
whichever ones you need to get together to get Y to
the X. The way it's actually done in practice isn't
you do all the squaring and then the multiplying.
There's a square and multiply as needed as you go
trick. But it's basically that. It allows you to do
the computation efficiently.
I also mentioned last time, this case where X is the
unknown and talked about it as discrete logarithm
problem and said that it's generally believed to be
hard to solve and said nothing more about it at the
time.
Well, now I'm going to spend some more time talking
about it. So just to remind you, the key here, the
thing that makes this hard is the mod N, right? Just
need to make absolutely sure everybody here knows
what mod N is. It's take the remainder when divided
by N. And the thing that makers this -- causes this
to make things hard is if we just -- if we eliminated
the mod N, if it's just solves equals Y to the X,
that is just finding an ordinary logarithm. That's
something you can do with binary search or a
successive approximation. You get closer and closer,
you've almost got it. You do some interpolation, you
get a very accurate result.
You can't do that with mod N because taking the
remainder is just looking at the low order bits of a
computation. The high order bits might not change if
you make a small change in something, but the low
order bits are chaotic. They vary widely. So if
you're very close on the low order bits, that doesn't
mean you're anywhere close to solving the problem.
And that's really what's going on here, that chaos of
the low order is what we're banking on.
How do you solve some sort of an equation to get the
low order bits to have some value? It can be very
hard. Okay. So the history of modern cryptography
goes back to the New Directions paper. 1976 with
Diffie, Marty Hellman published this paper called New
Directions in Cryptography. Very, very influential.
It introduced the idea of a one-way function and a
one-way function is just a function where if you
start with X, you can compute Y equals F of X easily.
Easily is not very well specified here. It doesn't
have to be. But if you have the output Y, finding
the X, or maybe there are multiple ones, finding any
X such that F of X equal Y, that is hard in some
sense, okay?
And they introduced this idea. They found a one-way
function and used it to develop the very first public
key exchange protocol. I'll mention a little bit
more later.
They also described the concept of a one-way trap
door function, they called it. A one-way trap door
function is one in which you could do this inversion
if you had some secret information. If you had
information, then given Y you could find X and said
this would be a really great thing to have, but we
can't find one. And we'll talk about that a little
bit after we talk about Diffie-Hellman.
Okay. So the Diffie-Hellman key exchange. It's
actually pretty simple. What happens is you have two
parties, Alice and Bob. Alice and Bob didn't exist
at the time of Diffie-Hellman. Existed -- RSA
introduced Alice and Bob in fact. But
retrospectively we can put Alice and Bob into the
picture. And Alice and Bob have somehow publicly
agreed upon integers P and G, okay? In practice,
almost always P is a prime. In practice, usually G
is a generator mod that prime. You don't have to
worry about that, but it doesn't matter. The same
thing actually works reasonably well in just about
any case of P and G here.
So Alice and Bob want to create a key that they can
use to talk to each other, but they're not in the
same room. They're separated and they have to talk
over a public channel. So the instructions here are
Alice picks a random value in the range of one to P
and Bob picks a random value in the range of one to P
and Alice does that computation, this is that one-way
function that we saw earlier, G to the A, and Bob
does this.
And these can be done asynchronously. They don't
have to be in some order. Both Alice and Bob are
doing this computation, and Alice sends over her
public key and Bob sends over his public key. And
then Alice computes this value and Bob computes this
value, and this K and this K are the same because
this is B to the A, which is G to the B to the A,
which is G to the BA, which is the same as G to the
AB, which is computed in very similar way.
You're just using the fact that for two integers,
these components, B times A equals B times A. That's
the only thing that's being done. Essentially this
Diffie-Hellman protocol works with almost any kind of
operations. It works with exponentiation IP. It
works with exponentiation not mod P, and it works
with multiplication, it works with addition. It
works with just about any function. So this is this
really nice property that you can get a common key.
So since it works almost everywhere, why is it that
we do it only in this funny case of mod P stuff?
Well, let's look at the security side of things.
What an observer sees in this protocol is the G is
public, the G to the A is the value that Alice sent
across here. The G to the B is the value that Bob
sent across here. The common key that they've
derived is G to the AB.
Well, with some functions, this common key could be
derived just from the public values. If this were
just multiplication or addition or in many cases you
could find this common value, this common key. But
in the case of G to the A mod P, G to the B mod P, if
these numbers are large enough, still not too big to
compute on, a thousand bits-ish or so, then there is
no known way in practice to given these three things,
figure out this. It's only Alice and Bob that can do
this because Alice knows the secret A and Bob knows
the secret B and each of them are able to put the
public stuff together with their secret information
and derive this value, okay? Does it make sense?
So this is it. This was state of the art in 1976.
This is the Diffie-Hellman key exchange protocol.
You do this, they have a common key. Everything is
great. And it's a little surprising now.
Diffie-Hellman is coming back into favor for reasons
I'll explain in a little while. It wasn't -although theoretically it was first, it was not the
most commonly used thing. It's picking up some favor
now and it's getting used more and more, and we'll
talk about that in a little bit.
But before we do, let's go on to the other. So we
had this case, the discrete logarithm we just did.
We did talk about in the first session the case of Y
being unknown, the discrete root finding problem.
And this is something, this is also a one-way
function. You plug in Y and you get Y to the X mod
N. It seems to be one way, except if you happen to
know the factorization of N, it's invertible. That's
the trap door. This is the one-way trap door
function.
Diffie and Hellman danced all around this. I heard
Marty Hellman give a talk a few years ago and he said
he even found some old notes that he had that said
that I wonder what happens if the modulus we're
working with isn't prime, because they were working
pretty much with prime. Hmm. That's interesting.
And then he went back and never check which can
looked at it again. So they danced around this but
they never quite found it.
The people who did find it were RS&A. Ron Rivest
out, Adi Shamir, Len Adleman, and they gave their
paper a very evocative title, really scintillating:
A Method for Obtaining Digital Signatures in Public
Key Crypto Systems." Now, the reason for this was
there already existed Diffie-Hellman. You could
already build a public key crypt system because you
could already do key exchange, but the new thing was
digital signatures. That's the big thing that RSA
came up out of. And this was just you a year later.
Now, the joke here is that Len Adleman's role in this
paper is that he could not break it. He could not
break the system. And that sounds like, well,
thanks, but actually, it was very significant because
Ron and Adi spent a lot of time trying out various
schemes, and every time they found something that
looked reasonably good, they'd give it to Len and
he'd break it.
And there was one thing that they found that was very
complicated but looked very good and was very hard,
and Len did a lot of work and finally came up with
nope, nope, that's not going to work. Broke it. So
Len does deserve a lot of credit because if he hadn't
broken that last one, probably RSA would be this
kludgy thing that nobody uses and somebody else would
have stumbled across the nice clean thing, because it
is, you know, in retrospect it seems so simple. And
there are claims that it was actually known in the
secret literature of three-letter agencies a year or
two before that.
I don't want to put much value in those claims
because even if that's true, if you discover
something and don't accomplish it, I don't think you
deserve scientific credit for it. So I don't really
think it needs to be addressed and people don't need
to be digging whether or not those claims are true.
Okay. It says a year later. Actually, this was
first described in a public place in sort of not the
scientific literature so much, but Scientific
American. The first academic publication came in the
communications of the ACM a year later. But that's
where I first saw that.
In 1977, the fall of '77 I read this article in my
optometrist's office. I was an MIT freshman at the
time and I went back, well, this is fun and I took a
freshman seminar the following semester on this, and
then I took a bunch of classes with Ron and Adi, and
I never took any classes with Len, but Len was more
on the heavy mathematic side.
So this really was something that caught on very
quickly. They talk about having to stuff envelopes
for days with tech reports. I mean, people just -because Scientific American article said there's a
tech report and people just kept mailing. Not
emailing. Mailing. Please give me a copy of this
tech report, and they were mailing out the tech
report to thousands of people. It got a lot of
interest for good reason.
Okay. So we talked about RSA last time -- not last
time -- two times ago. I'll just review it quickly.
The idea is basically select two big primes, publish
the product. The primes themselves are kept secret.
You can use any exponent or almost any exponent.
Actually, it does need to be odd. Typically we like
to use 65537. It's two to the 16th plus one. Has
some nice characteristics. A lot of zeros in it.
But it has to be odd, so it has to have a one at the
end. Has to have a one at the beginning. It's good
if it's prime.
There are actually very few integers that are two to
the K plus one and are prime. They're called Fermat
primes and the next larger one is too large to
imagine, right? The exponent has to be a power of
two and two to the 32 plus one I think is not a
Fermat prime. I've forgotten. I don't know. Do you
happen to know? I don't remember. But anyway, this
turns out to be a really nice exponent. Pretty much
everybody uses it. And you just encrypt a message by
using this one way function. Here is the message Y,
raise it to the X power, mod N. The decryption is
taking the X root, mod N which you can do if you have
the factors, okay? Because if you take the X root
and take the X power, you get back to where you
started.
Also, we have signatures. You can do this in the
other order. Take the X root, take the X power, the
X root is the signature. The X power is the
verification of the signature.
Okay. So that's how RSA works at a higher level.
I'm going to dig in a little bit deeper. How do you
actually compute this X root? So if you permit me,
we're going to have about ten minutes of a little bit
of math. If you don't like math, now's a good time
for email, okay? It's okay. I won't be offended.
But this is -- it's easy math. This is high school
math, okay? And basically there are three things I
have to convince you are true, and they're not that
hard. They're each a slide-ish.
The first thing I have to do is create some notation.
So first of all, mathematicians like to use this ZZ
for the integers, just the whole numbers positive and
negative, zero, the integers. We like to use Z sub
N, Z mod N for the integers up -- from zero up
through N minus one. This is something
mathematicians really like. Computer scientists do
not like this because this thing is infinite. This
is what computer scientists like, right? This is
finite. This is something you can do.
Cryptographers, too. We like finite things to work
with. There's our finite, okay?
These are also the things you get when you take
something mod N, these are the possible values. So
this is what we're going to work with, and in a
little bit of notation that just helps me make things
fit on a slide is X is equivalent mod N, sometimes
congruent mod N to Y means that they're the same when
you take them both mod N. Okay?
And equivalently it also is the same as saying that N
divides their difference. So basically if N is 100,
then 317 and 817 are equivalent mod N. And if you
take their difference, their difference is 500 -yes, it's a multiple of 100. That's what it means.
They're both 17 more than a multiple of a hundred.
Take their difference, you get rid of that? Okay.
All right. So first useful fact.
Three things we have to do. Here is number one. If
you have a prime and two integers, then this equation
holds. This is what high school student in the world
studying math wishes were true all the time, right?
And many still think is true. Certainly if you want
to sort of do a histogram of where points have been
lost on algebra tests, probably, you know, trying to
apply this might be really high.
It turns out, though, that
doing the computations mod
this exponent P and put it
okay? And I will convince
lines.
if P is a prime and we're
P, you actually can take
inside those parentheses,
you of this in a couple of
So first, let's just take a look at what X plus Y to
the P actually equals. We can expand this out using
the binomial theorem. Okay? Yes. It looks
horrible, but it's really not so bad. It's just -you're counting. Suppose we have P terms that look
exactly like that. Well, if we want to take the X
from all those terms, there's only one way. We take
the X from all of them. There's 1X of the P.
Then if we want just 1Y, then we have P different
terms which could give a Y and all the rest Xs.
That's the binomial coefficient that counts that.
And here is the binomial coefficient that counts
this. This is the binomial theorem. Okay?
These values here just careful counting you can
compute P factorial divided by I factorial P minus I
factorial. You might remember this. You might not.
You could re-derive it yourself. I'm not going to do
it here.
The thing that's valuable here is this. Let's take a
look here. This has certainly got a P in the
numerator. It's P factorial. P times other things.
P is a prime. This doesn't have that prime in the
denominator because everything here are factorials of
things less than P. I is less than P. P minus I is
less than P because I is at least one.
So there's no P in the denominator. P is a prime.
It's an enumerator. It's not a denominator. If I
take things mod P, basically this is a multiply of P,
right? It's an integer. It's a multiply of P. If I
take it mod P, it becomes zero. All of the these
binomial coefficients in here become zero. So that
term goes away, that term goes away, that term goes
away. You're just left with X to the P plus Y to the
P when you take things mod P. Okay? Useful fact
number one.
That useful fact allows me to prove to you Fermat's
little theorem. Fermat's little theorem says if you
have a prime P and you have something in the range
zero to P minus one, then if you take that thing to
the Pth power mod P you get X back.
Now, this is the sort of thing that interests
cryptographers because encryption and decryption is
starting with something, doing some computations and
getting back to what you started with. Right? So
here is, hmm, ah, interesting little mathematical
fact, we can do this and get back to where we
started. Okay?
So let's see why this works. The first thing I'm
going to do is generalize this a little bit. It's
easier to prove this. Not just for the things here,
but for all X, at least it's easier for me here to
prove it that way. For all integers X I'm just going
to prove this. So certainly this is a way of saying
everything we need here and more, because certainly
if X is in here, then X mod P is just X. So this is
just an easier way of saying that.
Okay. So we're going to prove this and we're going
to prove it. Now, I don't know how many groans I'm
going to hear. Induction, high school mathematics,
induction. Okay. I couldn't get away with this in a
lot of places, but here I'm hoping I can. But just
the quick reminder of what induction is. The analogy
is knocking over dominoes, right? I want to convince
you that all the dominoes in a room or someplace have
been knocked over, and I have to do two things to
convince you that they've all been knocked over. I
have to convince you that they're lined up such that
if one falls, the next one will fall, and I have to
convince you also that somebody pushed the first one
over or the first one fell. If you know those two
things, then you'll be convinced that they all fell,
or at least I hope you will be, okay?
So basically I have to convince you that this is true
when X equals zero, and if it's true at some point,
then it's true at the next opinion. If it's true for
domino number A, then it's true for domino A plus
one.
So for X equals zero, well, this is certainly true
when X is zero. That's not hard. It's true when X
equals one. That's not hard. We don't need to do
it. But those are the easy case.
Okay. So for the second part, if it's true for
domino A, this is what it means to be true for domino
A, then it's true for domino A plus one, okay? Here
is domino A plus one. We raise that to the Pth power
and see what we get. Well, let's apply the useful
fact of putting the P inside the parentheses. We get
this. A to the P by our little assumption here is
just A. One to the P is just one. So we've got this
thing proved. Actually, technically I should show
you that it's true for negative X as well, but you
could just, you know, plug in negative values of X
and that's just trivial stuff.
So we now have this theorem, okay? Here it is. The
theorem we wanted, but this idea of doing something
and coming back to where we started, we want to be
able to stop somewhere in the middle if we're doing
cryptographer. That's the encryption. And then come
back to decrypt beginning. But this worked for P
prime. Raising it to a prime power, there's not
really a very good part way thing to do there. We'd
like it to be able to break it up in some other way,
so I'm going to generalize this. And the way I'll
generalize it is say it's true not just for X to the
P but X to the P, X to the K times P minus one plus
one. Any power that looks like this, okay?
So when K equals one, this is just X to the P. So
let's think of what this looks like in we get this.
Suppose P is 11. Then what we're saying here is X to
the first power is X, X to the 11th power is X, X to
the 21st power is X, X to the 31st power is X. Okay?
That's all we're getting. And some of them will be
more useful than others.
So we're going to prove that also by induction, this
time induction on the value K in here. Okay? K
equals zero. This is obvious, right? K equals zero,
then this thing -- oops. Sorry. Well, okay. This
thing just goes away. K is zero means X to the one
is all we get. We're done.
When K is one, we've got Fermat's little theorem, the
thing we just proved before, just to bring it in
context, but let's do the inductive step. Let's do
this. I'm not going to bother changing variables
here. Let's just assume it's true at K and show it's
true for K plus one.
So X to the K plus one times P minus one plus one,
okay. This is a heavy in the algebra as we get, I
promise. Multiple this out and to save a little bit
of space, I did a couple steps together here. It's K
times P minus one plus one times P minus one plus
one. One times P minus one is P minus one plus 1P.
So it's X to the K times P minus one plus P and I
separated it out that plus P part. Here are the PXs
over here and the K times P minus 1X is over there.
And now this is -- we get to apply Fermat's little
theorem to. That's just X. By what we just proved.
Now we put that back in. That's X to the X times P
minus one plus one instead of X to the K times P
minus one plus P, and this is exactly what we
assumed, so this is just X.
So hooray hooray. Now we've been able to show that,
for instance, X to the 21st power mod 11 equals X and
that's where things start to get interesting because
21 we can break up as three times seven, so X cubed
could be an encryption of X and then you raise it to
the seventh power, you get back to where you started.
That's the decryption. Raising X to the seventh
power mod 11 is the same as taking a cube root.
That's what we were able to do with this.
Okay. So just finishing off RSA, this was done with
primes, single primes. Let's say we have two
distinct primes and we have now this equation mod P
and the same is true mod Q. Any multiple of P minus
one works here. Any multiple of Q minus one works
here. So in particular, I'm going to take a multiple
of P minus one. I'm going to take K1 to be a
multiple of -- give us a multiple of P minus one
which is also a multiple of Q minus one. And I'm
going to take a multiple of Q minus one, which is
also a multiple of P minus one here. So when I plug
those in, I get the same power here, X to this power
gets back to X mod P, X to this power. Same power
gets back to X mod Q.
So finally, I can say well, remember this is saying
basically P is a factor of the difference between
these two things. Q is a factor of the difference
between these two things. These are different
primes, P and Q. They're both factors of the
difference. So P times Q is also a factor of the
difference. So X to this power is X mod P times Q.
Mod the product N.
Okay. So we've got this thing primes. We have this.
All we need now to finish things off is basically
what this three times seven thing I described before
was. We need to find an encryption exponent and a
decryption exponent such that if I multiply them
together, I get something of this form and then I can
encrypt by raising to the Eth power and decrypt by
raising to the Dth power and this turns out to be
something that's very easy, right? Once I have that,
I have this.
This is basic modular arithmetic which I'm not going
to bother to go through, but suppose we fix E to
65537 as we like to do, then it's just finding a D
that has this property with E. And there's a very
good way to do it. Even if you didn't have this very
good way to do it, you could exhaustively search and
just look for a K that makes this divisible by 63557
and that will give you your D.
And I can guarantee that you won't have to search, if
you do it sequentially, for more than 65537, Ks to
find it. So that's an easy to do it. There is an
easier way, but I'm not going to bother to tell you.
Okay. RSA quick. Any questions about this? Now you
can say you really understand RSA more than you ever
wanted to probably.
Okay. So is this now the end all and be all of
everything? We have a one-way trap door function we
can do everything with, right? It's perfect. It's
wonderful. We're done. Well, there are some
shortcomings. First of all, RSA, any asymmetric
function is way less efficient. We have our one-way
trap door function.
Yay.
But we really still want to do symmetric cryptography
for all of the sort of bulk needs. So we're really
still going to use this for signing and transmitting
keys. We're not going to use it for bulk data
encryption. But there are some other issues with
RSA, even though we've got a one-way trap door
function, you might say, hey, we're done, but there
are some shortcomings. First of all, this only works
on integers. Remember I said Diffie-Hellman, it
could work on any kind of mathematical group,
addition, multiplication. It could be addition and
multiplication of matrices. It could be elliptic
curves, which we'll talk about next session. It
could be lots of things.
RSA integers. That's it. I don't know of any way
making anything like RSA work anywhere else. Maybe
somebody will find something. Maybe something could
tell us something.
But there's another thing which is this thing that
making Diffie-Hellman more and more popular, and
that's that RSA doesn't provide what's called forward
secrecy. Uh-huh.
>>: Why is it a shortcoming? Why does -- most -- if
you're doing this proper thing, most things can be,
if you look at messengers and memory and data
[indiscernible] integers and make it look like
integers.
>> Josh Benaloh: We'll get into this a lot more next
time, but elliptic curve cryptography is becoming
popular because you can -- evidently it seems that
you can get away with shorter keys, shorter values,
and this has a lot of benefits on small devices
especially.
So we find that we want to use elliptic curve or
alternate systems other than the integers in places
where we need to get away with smaller values. We
can do that with Diffie-Hellman. We can't do that
with RSA. Okay? But we'll -- next session we'll
talk about that a lot. That's going to be the
primary focus.
But the secondary issue about RSA besides the integer
case is it doesn't give us forward secrecy, and I
have to explain what that means. So forward secrecy
is this terribly named thing. Actually, it's often
called perfect forward secrecy, and what it really
kind of means is backward secrecy. So forward
secrecy means that even if I compromise you today, I
own you today, what you did yesterday should remain
secure. That's a very desirable property, especially
today, the age of, you know, maybe three letter
agency attacks and whatnot.
With RSA, imagine I'm transmitting data and I've been
doing it for years using my RSA key, and I've been
receiving stuff and every time somebody sends me a
session key with my RSA key, you know, we're doing
stuff happily.
And somebody has been capturing all of this traffic,
unable to decrypt any of it but they've captured it
all. Suddenly I do something stupid. Maybe I run
open SSL or something. Who knows. Whatever. And my
RSA key gets exposed. Now whoever has captured all
of my traffic for the past five years can start going
through and decrypting everything, okay? Not very
good.
So the issue is that RSA keys are persistent. The
way we describe Diffie-Hellman earlier is the keys
can be completely ephemeral. Remember Diffie-Hellman
started out with I pick a key, you pick a key. Alice
and Bob each pick a key and they're done and when
they're done with the conversation, those keys
flitter away into the ether. Nobody ever sees them
again. I don't keep them. They're gone. Okay?
So that's good except that when you have this sort of
I pick a key, you pick a key with nothing to tie to
it, you don't have any authentication. You don't
really know who you're talking to. Maybe if I can
see you and, you know, we're in the room, we can do
this, but if we're talking over the Internet, I want
to be sure that if I'm Alice, it's Bob on the other
end and not Carol or Eve or whoever.
So we can have an authenticated Diffie-Hellman, and
the only difference between what I showed you before
and this is that we can certify these public keys.
So these keys don't have to be ephemeral. These keys
could be long-term. I selected them. Alice selected
them, you know, maybe years ago and here is Alice's
public key and here is Bob's public key and they went
off to a certifying authority and a certifying
authority signed, yay, verily, this public key does
belong to Alice and that public key does belong to
Bob, and Alice sends over her public key with a
certificate, and Bob sends it over with a certificate
and they generate their joint public key -- not
public key -- their joint key, okay, in exactly the
same way. And this is always now the same joint key
for Alice and Bob.
Well, we could do that, we get authentication, but
now we are subject to the same problems we had before
with RSA of no forward secrecy. If I ever get one of
the private keys of one of the two and I have all the
past traffic, I can decrypt it. But with
Diffie-Hellman, you can easily put the two together.
So you can do an authenticated Diffie-Hellman that
also has forward secrecy.
So Alice has a persistent key. Bob has a persistent
key. They've got them certified. But at the start
of a round of a protocol, one day they want to talk.
They each generate ephemeral keys also and now it
looks pretty the same. Alice sends both keys. Here
is my long-term public key and my certificate of my
long-term public key and my little ephemeral public
key.
Generating Diffie-Hellman keys is easy. It's a quick
and easy thing to do. You just raise something to a
power. RSA it's a little work to generate a public
key. You have to generate a couple primes. That's
harder. You multiply them together. It takes more
effort. It's easier to generate an ephemeral key
here, if you do that, and now you just sort of put it
all together in one big blob. And there are a lot of
ways of doing this. This is about as good as any,
but there are a few.
Basically, this is, okay, I take the two things -Alice takes the two things that she got from Bob and
raises the B and Y, raises B to her secret power X
and Y to her secret power A. So they just sort of
crossed them here, but there are lots of ways of
putting them together. And you get a joint key that
looks like this, basically G to the AY plus BX.
Basically the same protocol, but now you have forward
secrecy. This is something really nice to have. A
lot of people are starting to do this, wanting to do
Diffie-Hellman. Google is actually getting a lot of
traction with, hey, we have got forward secrecy
implemented in Chrome. We're better. Yay, yay.
We're having trouble matching that because even
though we have Diffie-Hellman implemented and
valuable in browsers, we don't really have -- we
haven't, posed very well this integer version of
Diffie-Hellman. The only Diffie-Hellman version that
we have easily exposed right now is the elliptic
curve version, and there are issues with people
trusting elliptic curves because most of the elliptic
curves that are standardized are standardized by
government agencies and people have concerns. So
we're doing some work to try to make this version
readily exposed so that we can say, yes, IE, perfect
forward secrecy too. Everybody wants to do it, can,
but it's become just a little challenging getting it
all there.
Okay. So I have just about the right amount of time
to discuss the digital signature algorithm. Crypto
systems encryption, public key encryption, there are
lots of ways of doing that, lots of ways have been
proposed. Diffie-Hellman works. RSA works. There
are lots of alternatives. Good choices.
Signature algorithms are much rarer. It's harder to
find reasonable signature algorithms, and since RSA
and RSA signatures don't work in places like elliptic
curves, it's really nice to find some alternatives
that might work in elliptic curves. So just over 20
years ago in 1991, I think it was, the NSA -- yes,
the NSA came out with digital signature algorithm.
This is like the ugliest thing imaginable. Really.
It's awful. But it has its place because it fills a
niche that pretty much nothing else does.
So I'm going to go through this kind of quickly.
Believe me, you're not going to want to spend a lot
time. I can never remember the details. I always
have to look them up, always.
So some public parameters. The digital signature
algorithm to define it, you have to define a hash
function that's part of it. SHA-256 is fine. You
take a prime that's about the size of the output of
the hash function, so let's say a 256-bit prime, and
another prime. So there's the medium-sized prime and
there's the big prime, and the big prime has to be
one mod the little prime. One more than a multiple
of the little prime. Okay?
And you also have a G, which is not one. It's not
one mod. The big prime. But such that when we raise
it to the Qth power, we get one mod P. Turns out
that it's very easy thing to do. Essentially if you
take pretty much any random value and raise it to the
power of P minus one divided by Q, you'll get a good
G here. Okay? But don't bother.
Okay. Set up for an individual user. All the things
before could be general parameters that are shared by
everybody in the world, for instance. If I want to
use this, I want to set up a signing key, I pick a
random X and I do pretty much the Diffie-Hellman kind
of thing. I raise it to the Xth power. I raise G to
the X power, and Y is now my public signature
verification key. Okay?
This Y could be certified by a certifying authority,
saying, yes, this is Josh's signature verification
key. Everybody can check. And it could even be
certified using this digital signature algorithm or
it could be certified using RSA, which is what most
people do. Okay.
How does this work? Here is where things start
getting really ugly. Sign a message, you pick a
random value K, okay? You then compute this thing
that makes mathematicians want to cry. You take G to
the K. You take that mod P and then you take that
mod Q. Now, P and Q don't really have a good type
relation. F. if P were a multiple of Q, then, okay,
this makes some sense, but this is just like random
nonsense. Taking it mod P and then taking that
result mod Q, if you did it in another order, if you
did it in mod Q first, you get something completely
different. It's ugly. Mathematicians hate this. It
removes any kind of reasonable structure around this
thing.
You then do another step which I'm going to come back
and talk about a lot. You take your secret key X,
you take the message, you take this R, you put them
together. You divide it by your random value, mod Q
and you get this S, okay? Hack hack hack hack.
R together with S constitutes a signature on the
message M. And a verifier verifies this by going
through and pretty much doing exactly the same
computation again.
You take G to this power, which is basically, if you
look at this, this is just G to the everything that's
in S divided by S. The only thing that's not here is
the one over K, so if you do all this, you should get
G to the K and you get the same thing if you do G to
the K mod P mod Q, you get the same R back. That's
the verification. Okay. It seems to work. At least
in this little niche of non-RSA signature algorithms,
signature algorithms that can be applied in the
elliptic curve case or non-integer cases.
But this has some deficiencies. It works. It's
used, but concern. Notice, here is this equation
sitting out kind of in the open, which uses your very
super secret signing key X, okay? Here it is. All
I've done is taken some things which are easily
calculable, they're all known, they're all public,
and divided it by a random K.
Okay. Well, it's random, so I guess I've randomized
it. I guess it's buried. I've got, you know,
basically if somebody wants to solve for X, there's
an equation for it, but there are two unknowns, X and
K, okay? So X is protected as long as K really is
random. If K is known, then, okay, I know K, I know
this, I can find X immediately. I've got your
signature key.
>>:
[inaudible].
>> Josh Benaloh: Q is known. So I haven't spent a
lot of time on calculations, mod P and Q. Doing
division actually turns out, and it's all required
here, I haven't shown you how to do division mod Q,
but you can do division. You can do basic arithmetic
mod Q in a similar way. Essentially X divided by Y
mod Q is some value Z such that if I multiply Z by Y
I get X back and it turns out there are ways of doing
computations. It's the same thing when we did -found the RSA exponent, E times D has a certain
value. You're dividing by E. So modular division
turns out to be doable, okay? So we've got this
equation. If you know K and you've done a little bit
of studying of modular arithmetic, you can quickly
find X. So K had better be kept secret, okay?
If K is not secret, then you could just solve that
equation. Your permanent signing key is gone once
you slip up and you use an X that's known, your
permanent signing key is gone. It's out there. Not
just that, but if you just leak a little bit of K
each time, then you allow an adversary to build up
information about K. Okay. Here is an equation I've
got. The first few bits of K are this and the last
few bits of K are that and here is a little bit more
information and over time I can pick up all this
information and get X.
Another really bad case is if you repeat K, because
now you've of got another equation in X and Y -- x
and K, two equations now, the same K both times, K1
equals K2. So now it's two equations, two unknowns.
X is revealed.
Some of you might remember when this happened a few
years ago to Sony and its Playstation and they were
being a little careless and they were using the same
key because they had a bad entropy source. I think
it wasn't bad entropy. I think it was just bad
coding. They just used the same key, right? And,
well, you used the same K. Not the same key. The
same K. They used the same K. They just revealed
their signature key.
Now anybody can sign as Sony. Not so good. This
caused them some problems. So DSA is pretty fragile.
When this sort of thing happens with stream ciphers,
we found, as a company, even though there's nothing
inherently wrong with the well used stream cipher, it
just caused so many problems, stop using them. We
loved to do the same thing here, stop using DSA.
It's fragile. The problem is stream ciphers have -yep, it's 2:30, or close enough to it.
Stream ciphers have a good alternative of block
ciphers for most applications. Here there aren't a
lot of games other than DSA in at least that part of
town. So DSA kind of, we have to accept and just
sort of look at it carefully, but be really careful.
Try to avoid using it.
What the recommendation is in general is that for
very few applications do you really have to use DSA
for signing. Even if you're in a small hardware
environment, an embedded environment, something like
that, you can usually get away with using RSA for
signing. There are some advantages to doing that
other than this fragility.
Okay. So that's pretty much where we are and it's
pretty much 2:30. So next time we're going to get
into the elliptic curve stuff. We'll talk about what
an elliptic curve is, what elliptic groups are, what
this environment is where you can't use RSA but you
can use smaller key sizes, smaller amounts of
computation, get more efficiency, has some benefits.
We'll talk about that. We'll talk about elliptic
curve Diffie-Hellman and elliptic curve DSA, and
we'll also talk about some non-integer systems that
are not elliptic curve. I probably won't spend a lot
of time on it, but I'll mention some lattice-based
systems, for instance, give some alternatives.
And then we've got just two sessions left after that.
I work -- I moved things around a little bit because
I think there's interest in spending some more time
doing sort of vulnerability kind of stuff, so we'll
try to spend, yeah, more time on that, and then the
last session is applications.
Now, this is all just what I'm putting out there. If
people want to talk about something different, let me
know. It's flexible. But this is where it is now,
so let me know if you want to do anything other than
that.
Okay?
Otherwise, that's where we're headed.
Any questions? Yep.
>>: So Diffie-Hellman and RSA came around about the
same time?
>> Josh Benaloh: Yeah.
>>: RSA takes on so much more ->> Josh Benaloh: Because RSA is a one-way trap door
function, and basically it came about as I want to
send you a message. Here it is. You've got an RSA
key. I send you a message. I'm done. I send you a
key and I send you some data encrypted with that key
and I'm done. We don't have to do a two-way
exchange. So ->>:
[inaudible] public key.
>> Josh Benaloh: If you have a public key, then you
can do that and what came about was then something
called ElGamal, although ElGamal was mostly another
signature algorithm which is I've got your public key
and, yes, you can do it one way.
The other side of it is RSA does signatures. I've
got an RSA implementation, do signatures, and
encryption at the same time. But you're right. To
some extent, it's mostly a matter of mind share and
not so much a matter of what's available and what
isn't.
Diffie-Hellman was used for a while, but at the
beginning there wasn't -- this was mostly on paper,
not a lot of this was used at all. So by the time
people started implementing this, RSA was available,
RSA looked like a more general, better way to do
things to most people, and ->>:
Was there any [inaudible] testing?
>> Josh Benaloh: No, no. They were both available
under essentially the same terms, and there is some
politics around this. So I guess it's worth getting
into this a little bit.
So there was some kind of ugly stuff that was done.
Diffie-Hellman was done at Stanford. Stanford had
patents on Diffie-Hellman. RSA was done at MIT. MIT
had patents on this. Something was formed to put
these things together called public key partners
which was basically had the full rights to use these
patents and licensed them because these were thought
to be worth a lot of money to these universities.
And public key partners granted the exclusive use to
the RSA company that had formed and the RSA company,
of course, was somewhat more interested in RSA itself
than Diffie-Hellman. So that was part of it. Now,
the RSA company did something kind of ugly, because
they got the rights to relicense the patents to
anybody, and royalties -- most of the royalties would
go back to Stanford and MIT. Or they could give
people code. They could just sell systems and then
there were no royalties to go back.
>>:
Source code?
>> Josh Benaloh: Source code even. Yep. And you
see, but source code. And they never sold or almost
never sold patent rights. They sold code with a
license to modify the code as you wished. So
basically they got the money. Stanford and MIT
didn't get the money.
But the licenses were here is your RSA code, go
ahead, go to town on it. And since it was the RSA
company and RSA source code and that's how we did it.
That's how everybody did it at the time. The old be
safe libraries, if you've ever heard of them were
these terrible libraries of this was the RSA
implementation. The RSA company implementation of
the RSA algorithm. What everybody did, they licensed
the code. They gutted the code because it was awful
and they wrote their own.
>>:
Did you have to license the code?
>> Josh Benaloh: You had to either license the code
or license the patent, and the only people authorized
to license the patent, to issue licenses on patents
were the RSA company. Which said, don't bother with
that. We'll just sell you the code or license the
code.
>>:
[inaudible].
>> Josh Benaloh: So, yeah. It was -- people have
learned a good deal since then. And the patents have
long since expired, so you know, that's no longer the
case, but it was for a long time. That's the way
anybody did any of this. They bought a code license
to take this code that they didn't want. They
completed gutted it. They took the first line of the
copyright attribution. They changed everything else
and they did their own implementation of RSA, whether
it was us, whether it was some hardware vendor, you
know, that's the way everybody did it. Okay?
Other questions? Yep.
>>: [inaudible]. So I'm still not clear in like
what's the use case for DSA as opposed to RSA for
signing.
>> Josh Benaloh: We will see that next time, next
session, but the use case is basically if you are in
an environment where you're constrained -- well, not
so much -- well, it can be code, but mostly data
size, communication size, whatever, if you do things
not over the integers but with elliptic curves, and
I'll explain what all that is next time -- then you
can get away with smaller keys and smaller key sizes
and more efficient computation, smaller
communications. A lot of things that are of benefits
in certain environments.
So you've got this constrained environment, and many
people like to use elliptic curves even in a
nonconstrained environment, but especially for a
constrained environment, you want to use -- you need
to use elliptic curves. RSA doesn't work there. DSA
does. And I'll show you how next time.
>>: What do you mean by "small environments"? I
mean, I think of something that a smart card chip,
you know, slow, low memory, low speed. But that can
do RSA.
>> Josh Benaloh: That can do RSA, especially RSA
signature verification, but it can be a little slow
to do it, but even smaller things, you know, RFIDS,
NFC chips. Especially the cheap ones. You know, ES
you can get a $10 RFID chip that will do RSA easily.
If you're using a 50-cent one, then you're more
constrained and you can't really do RSA. That's -sorry.
>>:
They can do DSA?
>> Josh Benaloh: They usually don't, aren't signing
things. They're usually, if they're doing anything
encryption and authentication, so they're doing ECDH
elliptic curve Diffie-Hellman usually, they can do
ECDSA. I don't want them to, but they can usually.
And it depends on exactly the specs. But if you're
tightly constrained, yeah, really tightly constrained
especially. And a few years ago even moderately
tightly constrained. A few years ago elliptic curves
became very popular embedded devices especially. And
other. We will talk about that. I'm sure there are
other people here who might want to express opinions
on the tradeoffs between elliptic curves and integer
algorithms next time and that will be a primary focus
in two weeks. Okay? Anything else? If you haven't
signed the sheet, please do so to make sure you get
your ->>:
[inaudible]
>> Josh Benaloh:
-- it's not a trinket. It's
actually something good, gift at the end, and we'll
see you in two weeks.
[applause]