21835
>> Senny Kamara: We'd like to, I guess, welcome Vinod Vaikuntanathan who is going to be speaking
about password-based key exchange. So Vinod is a member of the Crypto Group. I guess Vinod
graduated from MIT, did a post-doc at IBM Watson. So I guess I should also mention we're planning on
having these crypto colloquiums weekly. So the regular time will be Thursdays at 1:30. If you're interested,
we hope you'll be able to attend.
>> Vinod Vaikuntanahtan: Thanks, Senny. Okay. So this talk is on password-based key exchange at the
cost of Diffie-Hellman. This is joint work with Jonathan Katz at University of Maryland.
Key exchanges is very basic, very fundamental primitive in cryptography. This was defined by Diffie and
Hellman in the 1970s in a work that really started off modern cryptography.
And what they did was they defined this notion, and they constructed a very beautiful, very simple protocol
that achieves key exchange. What it does is it lets two parties, Alice and Bob in this picture, who have
never met before in life come together, exchange messages on a public communication channel and still
agree on a shared secret key. This is a really magical primitive, and it's a very simple protocol to achieve
this primitive.
So this protocol is fast. It's blazingly fast. Each participant has one message and these messages are sent
simultaneously, in the sense that Alice doesn't have to wait to hear Bob's message before she sends her
own.
The same for Bob. And, yeah, this is really a super fast protocol. The protocol is succinct. By that I mean
that it has small communication complexity. Each party exchanges one group element. That's that.
And we believe that this protocol is actually secure under what we now call the decisional Diffie-Hellman
assumption.
So this seems like -- this seems great. It seems like the perfect world, except for one little problem, which
is that the security of this protocol holds only against passive eavesdropping adversaries, namely
adversaries who can listen in on the communication channel between Alice and Bob and do nothing else.
They can listen and gather a whole bunch of messages and try to analyze the shared key.
Another way of looking at the Diffie-Hellman protocol is a way to start off from an authenticator channel
where Alice and Bob know who they're talking to and bootstrap on top of it a secure private communication
channel.
Okay. So that's great. But what we would really like is to come up with a protocol which shares all these
nice features and on top of that achieve security against active adversaries. By active adversaries, I man
adversaries that can sit in the middle of the communication channel. They can modify, insert, delete
messages, do whatever they want to do.
What we want to do is start off from scratch and construct an authenticated and secure channel on top of it.
This is what we want to do in an ideal world.
This setting, it turns out, is a very challenging setting. So, for example, one thing that the active adversary
can do, it can cut off the communication channel between Alice and Bob. There's nothing you can do to
prevent this kind of attack. Sort of denial of service attack.
But what is more serious is the kind of impersonation attack that the active adversary can mount. Namely
the adversary can sit in the middle. It can talk to Alice pretending that it's Bob. And it can talk to Bob
pretending it's Alice.
Alice has nothing to tell between the adversary, whether she's talking to an adversary or Bob. So she will
happily communicate with the other three agree on a shared key and start encrypting all the data using this
shared key. Essentially what she's doing is giving away all the data to the adversary for free. It's really
extremely serious, exposes all the private information of Alice. Something we'd like to prevent.
So if you look at this attack a little more closely, you can see that the main problem here is that Alice has
no way to distinguish between the adversary on one hand and Bob on the other. In other words, Alice and
Bob don't share any information a priori to let Alice distinguish between these two entities.
Turning this around, if we want to solve the impersonation attack problem, and we really do, we need to let
Alice and Bob share some information. Sort of common a priori setup information.
In fact, there have been -- so, in other words, what we are solving is not the problem that we started off
with, namely how to get secure authenticated channel from scratch. We're really only going to be able to
solve the problem of getting a secure authenticated channel from a minimal sort of setup assumption, from
a less -- you know -- strong setup assumption.
Okay. So people have looked at a bunch of these setup assumptions in the literature. The most common
are sort of assuming that there's a public infrastructure, which means that Alice has a public key for which
she knows the secret key.
The public key is up in the sky. Everyone can see it, including Bob. And so does Bob, right? So this is
one setting that people have looked at. In fact, there's been a whole bunch of work in the setting, including
some very recent work by folks here at Microsoft Research, including Brian Lamankia and Aaron Christian
[phonetic], and what these works focus on, so this setting is in principle very easy to handle, because
there's a public key infrastructure up in the sky I could just run the Diffie-Hellman protocol and sign all the
messages on top of it.
So that should in principle solve the problem of impersonation attack. But what people were focusing on in
this line of work was, number one, to optimize the efficiency of the resulting protocol. So I want to sort
minimize the extra information that I had on top of Diffie-Hellman and still get authentication on top of it.
And, number two, how to handle stronger classes of attacks. For example, forward security is something
that Christian worked on quite a lot.
And this is one setting that people have considered. This is not a setting that we'll work with today.
A second setting is one where Alice and Bob share high entropy shared keys. This is not uniformly random
key; if it were, it would already be useful, you could already use it as a shared key.
It is a long string which has some entropy. I just don't know where the entropy is. I can't use it directly in a
cryptographic protocol. What I want to do is refine this high entropy key to a uniformly random key which I
can then use in cryptographic protocol. So this is the goal of this setting.
Again, this is not what we will talk about today. What we will talk about today is the setting of
password-based authenticated key exchange where the two parties, Alice and Bob, share a password or a
low entropy shared strength. So think of a password as an ATM PIN, four digits, or a computer log-on
password. Right?
Now, again, their goal is the same. They share a short password and they want to bootstrap it to a
cryptographically strong key. The challenging thing about the setting is that the password is so short, so
little entropy, you can't use it directly in a cryptographic protocol. Instead you have to do something
nontrivial on top of it to get high entropy string. It's in contrast to both settings where you can think of the
shared information as having already high entropy.
So, in principle, the setting is more challenging than both the other settings that people have considered.
And, in fact, people even in practice people use passwords all the time. And a common attack against
these systems is a dictionary attack, namely one that enumerates these passwords. It does something a
little more clever, essentially a dictionary attack. What we would like to do is we would like to add
cryptographic protection on top of password-based systems to make them harder, to make it harder to
mount dictionary attacks.
This you will see in just a little bit. Okay. So this is the setting that we will talk about. And let's look at the
setting a little bit more closely.
So, again, Alice and Bob share a password, chosen from a small dictionary. And one thing that you can
already observe in the setting is that you cannot prevent online password guessing attacks.
What I mean by this is that the adversary can start a whole bunch of sessions, key exchange sessions,
between Alice and Bob.
In each session, the adversary sits in the middle. It guesses two passwords. One for the introduction with
Alice and one for the introduction with Bob.
And it does it for all the Q sessions. So what is the chance that one of these guesses is correct? It is two
times the number of sessions, two times Q, divided by the dictionary size.
And what this means is that with this probability, the adversary can actually successfully impersonate Alice
and Bob one of the two guys and agree on a shared key with one of the two parties.
So you ->>: They share the same password. How can they get by with having two different passwords on both
sides of the talk? And be undetectable?
>> Vinod Vaikuntanahtan: No. What the adversary does apriori doesn't know what the password is.
Doesn't know the information. Let me enumerate, let me enumerate one, two, three. One I'm going to sort
of use in the first session with Alice. I succeed or I don't succeed.
If I don't succeed, tough luck, I close that session. If I do, then that's great for me.
>>: Not a man in the middle, a session with either Alice or Bob?
>> Vinod Vaikuntanahtan: It is a man in the middle. I sit in the middle and I talk to Alice and I talked to
Bob. So it is sort of an impersonation. It's an impersonation attack.
>>: The two. Same problem as Alice and Bob?
>> Vinod Vaikuntanahtan: The better thing to do is to use two different passwords. That way you get two
password guesses in each session, right?
So this is something that the adversary can do; there is no way you can prevent this attack. But what
makes this problem interesting and nontrivial is that online attacks are usually hard to carry out. And they
usually are easy to detect.
So there could be a system outside this setting to detect or prevent or minimize the damage of one-line
attacks. What we would like to do in this problem is we would like to offer optimal protection against off-line
attacks.
If the adversary is frustrated doing offline attacks, there's absolutely nothing he can do. Plus we would like
to offer the best possible protection that we can against online attacks. Best possible protection I mean
that the only thing that the adversary can do is do this password guessing business. He can succeed at
probability two times the number of sessions divided by the dictionary size. That's that. That's the best he
can do.
So we already saw that this kind of attack cannot be prevented. So this really gives you a very tight
guarantee.
Questions? Okay.
Okay. So let me be a little bit more formal. This is not very important. But what the security definition says
is that the adversary can start many different sessions, let's say Q sessions. In each session it can guess
the password with either of the two entities. And eventually it starts a test session between Alice and Bob
and it shouldn't be able to guess what the in the test session is, except probability with this number which is
inevitable anyway.
So this really captures what we needed, which is that we offer the best possible protection against online
attacks. Alice?
>>: Can you tell if the adversary is using the new password [phonetic]?
>> Vinod Vaikuntanahtan: Yes. So I'm not going to talk about -- so this sort of stronger definition is called
mutual authentication, which means that if a session fails, if the adversary guessed the wrong password,
Alice and Bob can both tell. You can achieve -- in all the protocols I presented you can achieve mutual
authentication at the cost of one extra message.
That's actually necessary. You can't avoid it -- what I'm talking about you can't get, if you need mutual
authentication, you can't get one round with mutual authentication. But I'm not going to talk about that any
further.
So this is the definition that we would like to achieve. And in fact there has been a lot of work on
password-based key exchange. The early work in this problem was in the ideal cipher random Markov
model where we can actually construct very efficient solutions.
In particular, you can solution a one round protocol, same as with Diffie-Hellman, with very low
communication complexity.
The point is that random Markov models don't exist. Cannot assume the model. And, thus, people started
looking at sort of the problem of getting rid of random Markovs. In particular, the work, what's called the
common random string model, which says that there's sort of a random string up in the sky that everyone
can see, including the parties and the adversary, and that's that.
Assuming the setup assumption can get the key exchange. And this model, the best known solutions need
at least three rounds of back and forth communication.
People have looked at removing even this setup assumption, even removing the common random string in
the sky, what's called the plain model which is a very challenging setting.
And the solutions in this model tend to be very inefficient, particularly it's far, far away from what you can
get by Diffie-Hellman. We will also look at the problem of guaranteeing a very strong notion of security
called universal composability. It's called UC security, which guarantees you don't need to know what
universal composability is. But the only thing you need to know is that it guarantees, automatically
guarantees concurrent composition of protocols.
So if the adversary can manage to run many of these key exchange sessions in an interleaved way it's still
up for security.
If you prove that the protocol is universally composable you can tolerate arbitrarily correlated password
distributions. You don't need to assume that the password distribution is random or any sort of fixed
distribution. It automatically tolerates any password distribution. And so on and so forth. Lots of goodies
you can get by proving universal composability. And, in fact, that's what we'll do.
This setting is even more challenging than all the other settings that I talked about. In fact, the known
solutions, even assuming the random Markov model, need at least five or six rounds of communication
depending on which setting you're talking about.
So the question we asked in this work is can I achieve password-based key exchange at really the cost of
Diffie-Hellman. In other words, I want a protocol that is fast. I want a protocol that communicates as few
group elements as possible.
And I want it to be secure against active attacks. So this problem is theoretically well motivated simply
because key exchange is a very fundamental primitive in cryptography and the question of what are the
minimal resources you need to achieve key exchange is a very basic question.
It's also practically motivated because you may not care about sort of a 40 round solution versus a 39
round solution. But if you can achieve really sort of one round Diffie-Hellman-like solution, it's actually very
useful in the setting of highly constrained devices, for example, sensor networks.
Example, consider a sensor network where the sensors have limited state. So they can't store long strings.
All they can store is short passwords. Short password-like strings. In the sense, it's asleep almost all of
the time. It wakes up briefly, listens to broadcast message from a server, which might include one of the
messages in the key exchange protocol.
It does some processing, comes up with the shared key, encrypts all its data using the shared key and
sends it off the server, goes to sleep immediately.
So it doesn't have the ability to store absolutely any state. And this is a setting in which a one-round
solution is really critical.
Okay. So, again, the question that we ask is can I achieve password-based key exchange at really the
cost of Diffie-Hellman. That's exactly what we show, such a protocol which is universally composable. And
the protocol is around optimal, in the sense the parties send one message each and the messages can be
sent simultaneously. You don't have to wait to hear the other party's message.
The protocol is succinct, which means that each party communicates a constant number of group
elements. And the protocol is secure under what's called the decisional linear assumption which is really
the same as the decisional Diffie-Hellman assumption in bilinear groups.
So it's -- morally it's the same as the decisional Diffie-Hellman assumption. Okay. A couple of comments
about remarks about this result. First of all, we do need to achieve this strong notion of security, namely
composability. You do need some kind of trusted setup. In particular, random string is a fairly benign form
of trusted setup.
All it says is that there's a random string in the sky which everyone can access. That's that.
So to achieve the strong notion of security, previous work needed at least five or six rounds of
communication, whereas we do it in sort of one round. And, as I said before, achieving the universal
composability, the strong notion of security, gives you a whole bunch of goodies for free, namely, the
protocol is secure against concurrent executions. It's secure even if the password distribution is arbitrary,
so on and so forth.
And for those of you who might be wondering, what this -- what this constant means, it's really 42.
In fact, 42 is not optimal by any means. After I gave this talk in China last week, we have been able to
improve this even further. Hate to give concrete numbers, but something like in the 20s.
>>: 20s.
>>: So about half, twice as good or half as big.
>> Vinod Vaikuntanahtan: 20 times as big. 20 times as big. Diffie-Hellman is one group element each
way. I'm saying about 20 issue group elements each way. So we don't solve the problem that we started
with, unfortunately, but what we do solve is we construct a password-based key exchange protocol at
essentially morally the same cost as Diffie-Hellman.
Good. So let me sort of describe how a protocol works. I'm going to do -- I'm going to describe this in a
very high level without sort of going into sort of the details of the specific details. But if you have any
questions, do ask.
Questions? Good. Okay. So the starting point for protocol is a special kind of unauthenticated key
exchange protocol. Namely, one that is secure against passive eavesdropping adversaries. And the
primitives that we use here are public encryption, regular public encryption, together with what I will call
smooth projective hash functions.
I'll define this in just a bit. This is a primitive that was invented by Cramer and . What it does is the
following.
It is a family of functions. It's a bunch of hash functions, right? You can choose function at random from
this family and so on and so forth.
It comes bundled with what's called a projection function, which takes a key and projects it down to a
smaller sub space, if you will.
It projects it down to a smaller key in some sense. What are the properties that I need from this family of
functions? First, this hash function takes two things, this input. A message and a cipher text. It takes a
cipher text pair as input and you consider two cases.
One, the cipher text C is actually an encryption of the message. It's honest to God good encryption of the
message. In that case this function can be computed in two distinct ways.
The first is when it's given all the inputs. Namely the key K, the hash key K, and the input, which is the
message and the cipher text. If it's given all these things it can compute the hash function, obviously.
But the more interesting thing is it can compute the hash function even if it's not given all of these things.
Namely, if it's given only the projected key, not the actual key, and also the randomness that it used to
generate the cipher text.
Okay. So this is sort of a balancing game. Either I'm given the key in which I can compute the hash
function, or I'm not given the key but I'm given some random information about the cipher text. That lets
me compute the hash function.
Okay. This is really the interesting part. This is sort of a correctness property. It tells you when you can
compute the hash function. The security property, namely something that tells you when you cannot
compute the hash function, is that if the cipher text happens to not be a valid encryption of the message,
sees not a valid encryption of them, then the value of the hash -- the hash value is statistically hidden given
the projection of the key.
Okay.
>>: Under bullet two you also get C and M or you don't get C and M?
>> Vinod Vaikuntanahtan: You do get C and M. Good question. You get C and M but you don't get the
key. If you did get the key you could compute it yourself but I'm only going to give you the projected key.
Then you cannot compute the hash value. Actually, hash value looks random to you.
It's a very nice primitive. It looks mysterious at first but let me give you an example to hopefully demystify it
a bit.
Okay. So this is an example for the case when the public encryption is the algorithm encryption, to
decompute I compute H to the R and H to the R times the message.
The key for the corresponding smooth projective hash function is a pair of elements from ZP. P is the order
of the group. And the projection is G to the X times H to the Y. Okay. So the important thing to note is that
the projection function takes two elements from the group ZP, X and Y, and it sort of compresses it down to
one group element. Namely G to the X times H to the Y. It's sort of a many to one function and it loses
information inherently. In other words, given the projected key, it is impossible to compute the actual key
back.
So how does the hash function work? It takes cipher text in a message and it simply computes. So it
simply computes the first element of the cipher text to the power X times the second element divided by M.
So that removes the M here and leaves you with H to the R to the power of Y. In other words, this is
exactly what happens if you compute the hash function on a valid cipher text.
So the all important exciting property here is commutativity which means that you can write this quantity by
sort of flipping the two exponents with each other. You can write it as G to the X to the power R times H to
the Y to the power R. In other words, it's the projected key to the power that randomness you use to
generate the cipher text.
So you can compute the hash value in two different ways. Either you're given the cipher text by itself so
you know this guy and this guy but you're given the key. Or you're not given the key. You're only given the
projected key but you know the randomness used to compute the cipher text.
And the other hand it's simple linear algebra but let's not get into the details. If you're given neither the
randomness only given the random cyferness text message not given the key only the projected key then
the hash output looks uniformly random to you.
Okay.
>>: What is the [inaudible].
>> Vinod Vaikuntanahtan: Okay. Good. So C is the cipher text. It is a pair of elements. And I write it as
upper case G and upper case H. Upper case G is supposed to be little g to the R in the real world and
upper case H is supposed to be H to the R. Melissa?
>>: So I'm confused. So you're not given in the second bullet with these statistically -- you can see you're
not actually given the sort of randomness?
>> Vinod Vaikuntanahtan: No, you are given -- you are given the cipher text and the message.
>>: And the real message.
>> Vinod Vaikuntanahtan: And the real message.
>>: So then find statistical guarantees ->> Vinod Vaikuntanahtan: So it gets ->>: So to the ->> Vinod Vaikuntanahtan: Say that again.
>>: You're talking statistical guarantees. Assuming no Res?
>> Vinod Vaikuntanahtan: No.
>>: Because R is determined by the cipher text. The cipher text is the R.
>> Vinod Vaikuntanahtan: Yes, you're right. So what I'm saying is if the cipher text is not an encryption of
M, then you know this little G will look like G to the little R. And the H over M will look like little H to the
power S for some different S. Right? So the difference between sort of valid ->>: You're given this R I guess but not ->> Vinod Vaikuntanahtan: Even if you're given the R and S. So what I'm claiming is that even if you're
given the R and S, you can't tell if the -- you know, you can't distinguish the hash value from random. So
this is kind of a statistical guarantee and it's sort of the important that technically it's really important that it
has the statistical guarantee.
Okay. So this is just sort of to give you an example of how one goes about constructing projective hash
function. But what we will use in our protocol is something -- we won't use LGMR we'll use something more
sophisticated but morally the same thing.
For that encryption you can construct smooth projective hash function the same way as here. Okay. So
how does the protocol work given a smooth projective hash function?
Remember that Alice and Bob share a password and there is a common random string, which is the public
key for the encryption scheme.
So there's a random string. No one needs to know the secret key corresponding to the random string it's
not a PKI setting it's just a random string setting.
So how does the protocol work? Alice encrypts her password. Sends it off to Bob. Bob chooses a random
Part B key K, computes the projected key alpha K sends it off to Alice.
Now, both the parties compute the hash value applied to the cipher text and the password, their own
password. And they can do this because Alice, who knows only the projected key, knows the randomness
she used to generate the cipher text. That's the extra information that pushes her off the edge, and she
can compute the hash value.
On the other hand, Bob actually knows the key. He doesn't know just the projected key. He knows the
actual hash key and he can compute the key too. So this is really -- one can think of this as a
generalization of the Diffie-Hellman protocol.
Okay. So I just told you why the parties can compute the keys. I didn't tell you why the protocol is secure.
So this protocol by itself is only going to be secure against passive adversaries like I promised. And
security really follows from the semantic security or NCPA security of the encryption scheme, which says
that the cipher text, when the adversary looks on and sees both these values, the cipher text looks like a
random string to it. So in other words it can't distinguish the cipher text from an encryption of junk or
random password.
So from the adversary's point of view this looks like an encryption of a random password and a projected
key. And then the smoothness, the security property of the hash-proof system says that if the encryption of
the random password, then the hash value will look statistically random to the adversary.
So combined, these two properties say that the adversary has computationally no information about the
shared key. Okay? So really if you think about it a little more deeply, what you can see that this is really
the Diffie-Hellman key exchange protocol except that it has statistical security guarantee. The proof of
security goes through kind of a statistical argument here.
So this is the basic sort of starting point. But unfortunately it's only secure against passive eavesdropping
adversaries.
>>: CRS is a public key, usually there's a private key if there's a public key.
>> Vinod Vaikuntanahtan: Yes, but no one needs to know it. So this is -- the private key corresponding to
the CRS will only be used in the security proof. In the real world no one has to know it. This is like the
magic of cryptography.
>>: Does it have to exist?
>> Vinod Vaikuntanahtan: It has to exist, yes.
>>: So have you to create something random that does have a private key.
>> Vinod Vaikuntanahtan: But usually you can. Think of the al ga mon public encryption scheme public
key X which is a public element which has a secret key.
( [CHK SPELLING ] listen to all this.
So what we'd like to do is we want to sort of add things on top of this sort of nice basic protocol and make it
secure against active attacks and hopefully not too many things on top of it.
So there are two issues with this protocol. The reasons why it's not secure against active adversaries. The
first is that the encryption scheme might be malleable. So you might be able to take the cipher text, which
is the encryption of a password, and transform it into an encryption for related password, which you could
then forward to a different session and you could do funny things with it.
Right? And the way we know of very standard way to solve this problem which is to use nonmalleable
encryption scheme. Instead of using a standard CPA secure encryption scheme, use a CCA endescription
scheme in fact they can be efficiently constructed so we don't pay too much in terms of cost.
So what this does, what this modification does is it makes it hard for the adversary to modify Alice's
message. So it cannot impersonate Alice to Bob anymore. That's what this modification does. But what it
can do is it can still impersonate Bob to Alice. So look at Bob's message. What he sends is he chooses
random hash key. He projects it and sends it over to Bob.
What he sends has nothing to do with this password. So what the adversary can do is it can sit in the
middle. It can talk to Alice. What it can do is choose its own random hash key, project it and send it to
Bob -- send it to Alice. That should work just as fine because this message does not depend on the
password at all.
How do you solve it? Well, we have a protocol with a one-sided security guarantee, namely you cannot
imnern 98 Alice but you can impersonate Bob. So what you do? You reuse it. You run two instances of
this protocol. One where Alice sends the cipher text and Bob sends the hash key and another where the
roles are reversed. Alice sends the hash key projected key and Bob sends the cipher text well now you
have two different instances of the protocol, and you get two different keys. How do you combine the two
keys? Multiply them together or exhort them together and then that gives you -- so you get two keys, one
from each instance of this protocol. You simply multiply them together. That's that.
>>: Prove that stuff is -- sort of ->> Vinod Vaikuntanahtan: Yes.
>>: Can you repeat the question?
>>: I'm just a little bit concerned. There are lots of protocols that -- you have two separate keys your XOR.
>> Vinod Vaikuntanahtan: Bad things happen. But not here.
>>: Just hash them?
>> Vinod Vaikuntanahtan: Say that again.
>>: Or just hash them again.
>> Vinod Vaikuntanahtan: No, you don't even need to hash them down. You can use just the product of
the two keys, and that's that. It's a very valid concern. But not that case. I will try to sort of -- as we go
through the talk I'll try to sort of address your question bit by bit.
>>: Just want to make sure.
>> Vinod Vaikuntanahtan: Good. So what's our protocol at the end? Alice sends one message which
contains a cipher text and a projected key and Bob also sends one message which contains really the
same thing. It's a symmetric protocol. And they compute two keys, multiply them together. Done. So you
might wonder if this is really a new idea, right? Did we come up with it all of our own? It turns out that
morally this idea was already present in some of the previous work and in particular the basic idea behind
this protocol is already present in a work of carts object strof ski and young my co-author and others and
gold Rick, Generale and Lindell. They did this work back in 2000 and 2003 where they came up with a
protocol which morally has the same idea.
But then why are we doing our work? Doesn't their work already solve this problem? The answer is that
their protocol is really the same thing. Modulo two problems. And what these two problems do is they
force the number of rounds to go from one, this really nice protocol, to three. Or 5, depending on which
setting you're talking about.
And what we will do in this work is we will solve these two problems and go back up to this nice little
protocol. So let me tell you what these two problems are, how we solve them, and that should do the trick.
Okay. So the first problem it's really a very sort of technical problem, which has to do with the way they
instantiate this protocol using specific primitives.
In particular, both these works use the Cramer and Shoup CC encryption scheme as the CC encryption
scheme. And when they do that, something bad happens.
What happens is that the associated smooth projective hash function they construct has a projection
function that depends both on the hash key and the cipher text. So remember that ideally the way we
defined it the projection function is supposed to take a key. It's supposed to output a projected key. And
this projected key is supposed to work for all possible cipher text assuming that you know the randomness.
But here what happens is that the projection function depends on the cipher text and the projected key will
only work for this particular cipher text. It won't work for any other cipher text.
Okay. So what happens is that what does this do to the protocol? Right? What it does to the protocol is
Bob has to wait to receive Alice's cipher text to compute a projected key, because the projection depends
on the cipher text.
So then it's not one round anymore. It's kind of two rounds. And Alice has to do the same thing. She has
to wait to receive Bob's cipher text before she computes the projection. That makes the whole protocol
already three rounds.
All right. So that's the first problem that we will try to solve. It's really, really it's a technical problem, right?
There's nothing bad about the protocol that we constructed in the last slide. It's just the way they
instantiated which gives you the three round.
>>: Can't see it two rounds?
>> Vinod Vaikuntanahtan: You could. You could. So -- yes, you could. But it's two simultaneous rounds.
And this. So that's four messages. It depends on how you count. In any case, the point is that it doesn't
satisfy our final goal, which is Diffie-Hellman. One simultaneous round.
Good. So this is the first problem. The second problem has to do with the security of the resulting
protocol. And the problem is what if the man in the middle, the adversary, takes one of these messages,
namely, the cipher text that Alice sends, for example, and forwards this to different password sessions? So
it can start a whole bunch of different sessions with Bob and it can sort of take one message of Alice and
forward it to different sessions.
The requirement, our security requirement says that the key that Bob computes in all these sessions is
independent. Independent and uniformly random. And that is something that we need to be concerned
about.
We need to actually go ahead and prove it. Right? So ideally what we would like to do is to come up with
a mechanism that prevents the adversary from forwarding a message to many different sessions. And
that's what these two works do. They do it by appealing to digital signature schemes. So what they do is
they ask Alice to come up with verification key and secret key for signature scheme.
They bind the cipher text, Alice's cipher text to a particular verification key, one she chooses.
So Alice now encrypts the password together with the verification key for signature scheme, sends it over.
Bob does really the same thing.
And at the end Alice sends whatever she's supposed to send before together with the signature of the
entire transcript of the protocol.
Okay. This is what they do. Why does this work?
I claim that this modification really prevents the adversary from taking the first message, forwarding it to
many different sessions. Why? He takes the first message. He has two options. One, he changes the
verification key. Then he is supposed to come up -- he's supposed to take this, the cipher text, and come
up with an encryption of the password together with the new verification key. That is a related cipher text.
It's a cipher text whose contents are related to the original cipher text. Therefore, he actually succeeded in
modeling the cipher text to related value.
We used a nonmalleable encryption scheme, so he can't do that. He cannot change the verification key
and still hope to succeed. So he has to keep the verification key the same. What happens if he keeps the
verification key the same? He starts a different session, which has a different transcript. And eventually
he's forced to sign a different transcript, a different message for the signature scheme using the same
verification key. That can't happen because we use the secure signature scheme. And therefore, bottom
line, he cannot reuse the first message that Alice sends. Done. Okay.
What is the problem? Even if you solve the first problem, which is this instance-dependent projection, this
solution needs three rounds. It needs one round where Alice sends a verification key. It needs a different
round where she knows the entire transcript and she's able to sign it. That's really bad for us. So we will
solve both of these problems and here's how.
The first solution solves the first problem which is that we will construct an encryption scheme, chosen
cipher text encryption scheme, with a smooth projective hash projection which is not instance-dependent.
You can project a key and hope that you can use it for all cipher text.
The idea -- I'm not going to get into the technical details, but the idea is to use the El-Gamal encryption
scheme. We like the encryption scheme. It's very simple, why not let's use it. We'll compile it with the
Naor-Yung paradigm to construct chosen cipher text construct encryption schemes. So without getting into
details, what happens is that you take two instances of, when you want to encrypt a message using the CC
encryption scheme, you encrypt the message twice using El-Gamal. One El-Gamal encryption, another
El-Gamal encryption, and you prove in zero knowledge that you encrypted the same message in both
cases.
So, again, without getting into details what this does, what this turns out to do, is that you're essentially
giving a proof of knowledge of the message when you're sort of constructing the cipher text. So essentially
the idea is if I give you a cipher text which is a proof of knowledge of the message, you can't model it into a
different proof of knowledge of the same message. That's how the -- that's why the encryption scheme
works in very high level.
Details. Many details. But it's really the same as El-Gamal. So what you see here is an El-Gamal
encryption. What you see here is another El-Gamal encryption, and you bind them together using an
noninteractive zero knowledge proof, which I'm not going to get into the details.
And this is the encryption scheme. You can construct an associated hash proof system in really the same
way that we did before. It's the same principle that we used. So trust me, this solves the first problem.
The important thing to note is the projection key is something that does not depend on a particular cipher
text. It just takes a hash key and just computes the projection. That's that.
Now, there are technical problems because we are eventually going to work in a bilinear group where
El-Gamal is not secure anymore. But then we have to move to a slightly more complicated encryption
scheme. But, again, this is something we can do.
Okay. So what this solution did was something amazing. We had a three-round protocol which, because
of this instance dependent projection problem, and we now have one round protocol, what we wanted.
Except that we still have to solve the problem with security, which is that the adversary can take a cipher
text and forward it to many different sessions.
>>: What's SPH?
>> Vinod Vaikuntanahtan: Smooth projective hash. In the spirit of expanding ->>: No, you're okay.
>> Vinod Vaikuntanahtan: Okay. So how are we going to solve this problem of reusing messages? The K
Jeal paradigm [phonetic] the previous work, what it did was it modified the protocol and added a verification
key, asked you to encrypt the verification key together with the password, so on and so forth, to solve this
problem. We're not going to do that. We're going to keep the same protocol. We like the protocol. It's one
round. And we're going to show that this protocol already has the requisite properties, security properties.
In particular, we will show the following lemma, which is that you have -- let's say you have N hash keys. A
whole bunch of hash keys. K1 up to K sub N and you have the projections and you have many cipher
texts, C1 up to C sub M. And you have a matrix of hash evaluations. Namely, you take every possible key,
you take every possible cipher text, put them together. So that gives you a whole bunch of hash
evaluations.
And we want to show that this is, this whole thing looks like uniformly random to me. The key thing to note
is that in the key nontrivial thing here is that each cipher text is reused many different times. I'm going to
use each cipher text with all possible hash keys. And I'm going to use each hash key with all possible
cipher text. This is really the maximal reuse that you can expect.
And what this lemma says is that that's okay. You know? The resulting hash values will look totally
independent and random. So let me sort of skip the details. Let me just leave you with a statement of this
claim.
What it does, it shows even if the adversary can forward, take a cipher text, forward it to many different
sessions, the resulting key will look random. All the sort of the different keys will look uniformly random and
independent. So what is the effect? The effect is that -- so the nice protocol that we started off with
actually does work. And this gives you sort of the final -- this is the final protocol that we have.
So you need to add sort of the identities of the parties just for sort of just to prevent kind of free play
attacks. But those are details.
So one thing that you might want is we constructed the encryption scheme. We took El-Gamal, which is
really efficient, and compiled it with noninteractive zero knowledge proof system which is extremely,
extremely inefficient. So what's going on here, right?
The answer is that for the particular encryption scheme that we used, you really have very efficient zero
knowledge proof systems, and this is from a work of Grow and Sahai [phonetic] based on an earlier work of
Grow Strophsky [phonetic] and Sahai. You hear noninteractive zero knowledge, you think this is really
inefficient; but that's not really the case because we use a particular instantiation here.
Okay. So that's the basic protocol. This doesn't satisfy composable security. Namely, if you run many sort
of different instances in all kinds of weird combinations, it's not guaranteed to be secure. But we can
actually sort of get even the stronger notion of security by adding just sort of one message. So this is
actually a simultaneous message, because I can send all these three things in one round. So it doesn't
sort of increase the round complexity.
Okay. So that's that. I think I'm almost out of time. So what we showed is the password-based key
exchange protocol at essentially asymptotically the same cost of Diffie-Hellman. There's still the question
of optimizing all these building blocks and coming up with a small enough constant. I think this is really sort
of an important problem in practice.
A number of other important open questions efficient, such in the plain model without assuming the
common random string, which is really a theoretical question. Security against adapted corruptions, so on
and so forth. So the second question is we started off by saying Alice and Bob to solve the authenticated
key exchange problem, Alice and Bob need to have some shared information. What if they don't?
Somehow Alice and Bob have never met before and they still want to do some meaningful notion of key
exchange. Of course, you know, in this setting you can always carry out the impersonation attack, the
adversary can sit in the middle, pretend to Alice as if he's Bob, and pretend to Bob as if he's Alice. But can
you see anything meaningful, can you achieve any meaningful security guarantee in this setting?
>>: Shared information, [inaudible].
>> Vinod Vaikuntanahtan: They need to have like a PKI. Like a PKI. I'm asking, really, you don't have a
PKI. You don't have shared keys. You don't have nothing. You're an alien, right?
>>: So no shared public information?
>> Vinod Vaikuntanahtan: No, not at all. No validated shared public information. You know, clearly you
cannot achieve authentication key exchange. But can you say something nontrivial. In fact, there's recent
work of Charlie Rockov [phonetic] and students who show something in the setting. It's hard to understand
what the something is. But it's an interesting sort of fundamental question to ask.
>>: Almost -- how do we know you're not Joe or Vinod?
>> Vinod Vaikuntanahtan: You don't.
>>: Right. I think I'm talking to -- I'm talking to Joe or Vinod?
>> Vinod Vaikuntanahtan: Yes, that is the impersonation.
>>: That came from that.
>> Vinod Vaikuntanahtan: That's the impersonation attack. There's no escape from that.
>>: What established your identity? I haven't checked your certification ->> Vinod Vaikuntanahtan: I completely agree. But is all hope lost in this setting? Can you say something
nontrivial? That's my question. Okay.
The final question is, well, we've been studying key exchange in the context of computational assumptions.
Can you minimize the computational assumptions needed to achieve key exchange. But can we make
physical assumptions? Are there physical settings in which you can actually do key exchange,
authenticated key exchange in an easier way? For example, Wiener had a model of whiteout channels
back in the '50s or '60s, something like that, and that turns out in that model you can actually do key
exchange in a very simple way. Even in an information theoretically secure way. What adapt channel says
is roughly the adversary can't perfectly eavesdrop on the communication channel, it can only get each bit
with a certain probability.
>>: I thought it was a perfect eavesdropper with Diffie-Hellman.
>> Vinod Vaikuntanahtan: It's not information theoretically -- if you solve the discrete log problem, of
course you can break the Diffie-Hellman protocol. But with this articular assumption you can get an
information theoretically secured protocol. What about other settings? It's a wide open question. That's
that. [applause]
>> Vinod Vaikuntanahtan: I assume there are no more questions. But so you can take it off line.
>> Senny Kamara: That's fine.