>> Vinod Vaikuntanathan: So we're very happy to have Shweta Agrawal from
UT Austin and Stanford here. She works in lattices, identity based encryption,
attribute based encryption, whole lot of exciting stuff. And she'll talk about
identity based encryption from lattices.
>> Shweta Agrawal: Thanks, Vinod. So the talk will be based on joint work with
Dan Boneh and Xavier Boyen. And I'm going to talk entirely about identity based
encryption, all of it from lattices.
So let's get started. So you're probably familiar with identity based encryption,
but let's just go over it for completeness. So the idea with identity based
encryption is that any arbitrary string should now be your public key.
So remember that in regular public key encryption the key generation algorithm
generates a public key and a private key, right, and you have no control over
what public key you get. But in identity based encryption, you can choose to
have your name or your e-mail ID as your public key.
And the way that this would work is that say we have the [inaudible] Alice, who
wants to send a message to Bob. So she's just going to encrypt the message
with his e-mail ID. And she's just going to send it to him. And Bob has a
one-time setup cost.
So Bob needs to contact a key server. The key server has some master secret.
And once Bob authenticates himself to the key server and requests a public key
corresponding to his e-mail ID, the key server will return that private key to him
using which he can then decrypt the message that Alice sent him.
So I should emphasize that that's just a one-time thing. So this key server, the
exchange with the key server needs to only happen once. And then everybody
can sends messages to Bob just as the usual PKE system.
So formally speaking an IBE consists of these four algorithms. There's the setup
algorithm which will take in your security parameter and output some public
parameters that all the other algorithms use. There's an extract algorithm. And
this algorithm is really the main difference between an IBE and an PKE.
So the setup also outputs a master secret key which is input to the extract
algorithm. And the extract algorithm takes in the arbitrary string that you want for
your public key and it takes this master secret and it generates a secret key
corresponding to that identity or that public key.
And then you have the usual encrypt and decrypt algorithms.
So really the extract is the only thing that's different. The master secret key and
the extract algorithm are what differentiate an IBE from a PKE.
And a few words about the security of such a scheme and how we prove it. So
as in most cryptographic systems, the security is proved as a game that is played
between a challenger and an adversary. And the way that it works is as follows:
So the challenger gets an instance of some hard problem that it's trying to solve.
And it constructs the public parameters or the code parameters from this hard
problem by massaging it somehow and returns that to the adversary.
Now, the adversary will query the challenger on a bunch of IDs. So the
adversary can pick any arbitrary identities of its choice and request secret keys
corresponding to these identities which the challenger has to return. And this
step really reflects the -- a model where scenario where the adversary can be an
insider in the system.
So maybe I have an identity and a corresponding secret key and I have a few
malicious friends with whom I can come together. So in that case, we do indeed
have some arbitrary identities and corresponding secret keys. But we want to
prove security even given that information. So this step is quite important.
So then this continues for a while, right, and then the adversary finally outputs a
challenge identity when we call ID star and some message, M.
Now, what the challenger will do is the challenger will flip a fail coin and if B is
this coin B, if it is zero, it will just pick a random element from the ciphertext
space. If it does one, then it will actually do a valid encryption and it will send this
back to the adversary. And the adversary has to guess whether the random coin
was zero or one, namely what the adversary did and -- what the challenger did,
I'm sorry.
And then the challenger uses that guess to output the answer for the hard
problem that it set out to solve. And there is the usual notion of security, the
attacker breaks the system if it has an advantage greater than a half.
So the key points to remember in this security game are the following. The first
thing is that I'm going to be focusing on the notion of selective security. So this is
a more restrictive version of security in which this step, right, the announcement
of the challenge identify, happens right here. It's the very first -- it's the very first
thing that the adversary sends the challenger.
And you can see how this gives the challenger a lot more power because it only
needs to -- it only needs to not have the answer -- not have the secret key for ID
start. So it can construct its core parameters based on this ID star, whereas in
the -- in the more secure, like in the stronger notion of adaptive security, it has to
construct the code parameters without any knowledge of the challenge.
So the systems I'm going to talk about are secure in the stronger definition of
adaptive security. But for simplicity of presentation I'll just focus on the selective
game.
Then note that the challenger needs to be able to answer private key queries of
adversary, of the adversary. So the adversary will request for private keys
corresponding to certain identities and the challenger needs to answer that.
However, it's important that the challenger should not be able to answer the
query for the challenger identity, right? That's because if the challenger could do
that, then the challenger could not leverage the attacker in any way. In some
sense, then the attacker cannot do anything for the challenger. Right?
So because the challenger needs to solve this hard problem that it's trying to
solve. And if it can itself answer -- if it can itself construct the secret key and
itself decrypt then in some sense the attacker cannot do anything for the
challenger. So this is really crucial.
And also the challenger needs to be -- yes, please?
>>: So understand the challenger can generate private keys for every ID except
ID [inaudible].
>> Shweta Agrawal: Exactly.
>>: Okay.
>> Shweta Agrawal: In the selective game that's exactly what. And, right. So
you need to build in this ID star somehow so that somehow when the question or
when the query is ID star then somehow you cannot do anything.
And also the challenger should be able to generate the challenge ciphertext
without the trapdoor. The challenge ciphertext is what it returns to the adversary
and asks the adversary to break.
And oh, I should mention that when I say master trapdoor, I mean the master
secret key that the extract algorithm uses.
So a brief word about the history of IBE. So identity based encryption was first
introduced by [inaudible] as a challenge to the research community back in 1984.
And the first construction was -- came out fairly like much later, about 30 years
later. And it was by Boneh and Franklin in in 2001. And it used bilinear maps.
And the corresponding lattice based construction would be GPV08. They both
construct the IBE in the random oracle module.
And then there's the Canetti, Halevi, Katz 03 paper that constructs the IBE in the
standard model using bilinear maps. And then that corresponds to the CHKP -the Cash, Hofheinz, Kiltz, Peikert paper as well as a paper that is [inaudible] with
one of my collaborators.
Then there's the bit-by-bit HIBE that also corresponds to the CHKP10 paper.
The BB04 bilinear maps IBE corresponds to one of the results I'll be presenting in
the talk. And as you have similar other analogs like a small ciphertext HIBE that
was constructed by Boneh, Boyen and Goh in '05 using bilinear maps
corresponds to one of our HIBE constructions that I'll be talking about.
>>: [inaudible].
>> Shweta Agrawal: Yes, yes, yes. This is just -- it's like a -- it's just a map of.
And the interesting thing is that even though the techniques used are completely
different in bilinear maps and lattices, there are high level analogs as to how
these things work, so it's interesting to keep this comparison in mind.
So the results I'm going to talk about, we have the first lattice based IBE without
random oracles. This was called covered by CHKP010.
Then we have a more efficient IBE in the standard model and we have a new
basis delegation technique for a hierarchal IBE. Now, I'll describe what a
hierarchal IBE is as we go along.
So let's get started. So we already have these instructions with bilinear maps.
So it's natural to ask why lattices, why bother? So well of course there's the
usual cryptographic answer that you don't want to place all your eggs in the same
basket. What if some problem becomes somehow easy later on. So you want to
have constructions from different problems. There's always that. But lattices
also have other advantages. For one, they have very strong hardness
guarantees. [inaudible] had the break through result in '96 which showed an
equivalence between worst case and average case hardness of lattice problems.
So this makes instructions from lattice problems secure in a much stronger sense
than the -- than the usual notion. Then lattices are also much more efficient.
The operations are efficient. Instead of bilinear computations you now just have
dot products and additions and multiplications. They're also very paralyzable.
So they can take advantage of parallel computing.
And we don't yet know a quantum algorithm to break lattices. So that's another
advantage. Because, as you know, RSA has a quantum algorithm.
So what is a lattice? This is a lattice. Mathematically speaking it's a discrete
subgroup in RN. But intuitively speaking it's just a set of points with a periodic
arrangement. And a lattice is represented by a basis. So V1 and V2 here are
my basis and all integer linear combinations of these two vectors create the
whole lattice for me.
Now, as you might expect, this basis is not unique. So V1 prime and V2 prime
as shown here is another basis that will generate the entire lattice. And the
lattice can have infinitely many basis in general.
Now, depending on which basis you choose, you can chop up the real plane into
blocks parallel to the basis and you get these parallelepipeds. So for this basis,
this is how you would break space up. For the other basis you would break it up
in this way. And it turns out that loosely speaking there is the notion of quality of
a basis.
So like I said, a lattice has infinitely many basis and some are other than others
in ways that I'll make more precise as we go along. But intuitively speaking, so
you can see how here if this -- so I'm claiming that this is a good basis, it's better
than the other basis than I showed you, and the reason is it's shorter and it's
roughly orthogonal compared to the other case. And why does that help? So
because -- now let's say that you have a point T in the -- in space. And you want
to find its closest lattice point. So one natural thing you might try to do is you
might just identify the parallelepiped in which it lies and output the center of that
parallelepiped as the closest point.
Now, in this -- for this basis that does not seem like such a bad idea. But
consider this basis. So then what happens? The center of this parallelepiped is
this point. So you'll output this as the closest point. But this is a closer point.
This is a closer point. Right? So the point I'm trying to make is that a lot of
problems are actually easy if you have a good basis. And they become very
hard if you have a bad basis. And that -- that's exactly what you need for
cryptography, right?
So all these problems SVP, CVP, the closest vector problem, shortest vector
problem, this problem called ISIS, which I'll talk about in the next slide, these are
hard given an arbitrary basis.
But there are some problems that actually become easy when you're given a
good basis. And recovering a good basis from a bad basis naturally is hard.
Right? So many cryptosystems, these are some examples, they exploit this
asymmetry. And here's how they do it.
So at a 40,000 feet view what happens is you can make the bad basis your
public key. You can make the good basis your private key. You can encrypt
using the bad basis and decrypt using the good basis. And like I said, recovering
the good basis from the bad basis is hard.
So of course every construction is a lot more subtle than this. But this is sort of
the take-away. This is what you're really doing.
So the systems that I'm going to talk about, for those systems the private key
comes from the ISIS problem. Now, what is this ISIS problem? It's also -- well, I
should tell you what ISIS stands for. It's inhomogeneous short integer solutions.
But it's also known as syndrome decoding from coding theory. And the problem
is as follows: So you have a matrix A and a vector U over this field ZQ. Now, I
should mention that A has to be a fat matrix. And you'll see why. The question is
to find a short -- by short I mean a low L2 norm integer vector Z such that AZ is
congruent to U mod Q. So you have this matrix A and you have this vector U.
And the question we're asking is find me a short integer vector Z such that AZ is
U mod Q.
So equivalently I can define this function FA of Z as A times Z and what -- what
this problem states is that inverting this function is hard. Right?
>>: [inaudible] short vectors?
>> Shweta Agrawal: Yes, yes.
>>: If the domain is not short vectors ->> Shweta Agrawal: Then it's trivial, yeah.
>>: How short is short and what sort of value is Q to think about?
>> Shweta Agrawal: Okay. Good question. So Q is generally polynomial in the
security parameter. So it really depends on what functionalities you want like for
very expressive things like a hierarchal IBE. You might need a Q -- in fact, you
will need a Q that is exponential in the depth of the tree that you want. And but
for general -- for a basic IBE and for basic encryption a Q that is polynomial in
the security parameter suffices.
>>: So it's 112 bit you're talking 10,000 bits or you're talking a million bits?
>>: [inaudible] is Q is like, you know ->>: Okay. So a hundred? Not two to the hundred.
>>: That's right.
>> Shweta Agrawal: Yeah.
>>: Okay.
>> Shweta Agrawal: So it is -- yeah, it's not terrible. The Q is not bad. And I
should have emphasized what Vinod pointed out, that the function, the domain of
the function is short vectors. Because if -- just choosing an arbitrary vector to
satisfy the situation is easy, but finding a short or a low known vector is actually
hard.
I used to have a slide maybe so if I have time left over I'll come back to a slide
where I show why this is sort of like solving the shortest vector problem. But
anyway, it has been proven in previous work by [inaudible] that this problem is
hard, unless we have a trapdoor. So a trapdoor in general it's used everywhere
in cryptography. It says that -- it's some secret information that you can use to -you can use to solve an otherwise hard problem.
>>: What do you mean by something is hard? It cannot be set upon
conditionally hard [inaudible] otherwise ->> Shweta Agrawal: Okay. So right.
>>: [inaudible].
>> Shweta Agrawal: Yeah. So it is as hard I think as like some approximate
version of shortest vector problem. Right. So this is -- this is just intuitive. But of
course mathematically speaking it's as hard as a different lattice problem
approximating the shortest vector problem in -- where the approximation factor is
polynomial. So that is believed to be hard.
So this notion of trapdoors, right. So in the world of lattices, what does the
trapdoor? So considering the buildup that we saw about good basis and bad
basis, you might guess by now that the trapdoor is going to be a basis of good
quality. So consider this lattice.
So I'm given a matrix A, as we saw in the previous slide. And I consider the
lattice of all vectors E such that AE is congruent to 0 mod Q. And this is a lattice.
It's easy enough to check.
It turns out that you can actually invert this function given a short basis for this
lattice.
So the short basis for a lattice can act as a cryptographic trapdoor. And how do
we get our hands on this trapdoor? So Ajt in '99 showed how you can generate a
random lattice along with a trapdoor. So we know how to pick a random lattice
along with a trapdoor, but given a lattice we don't know how to compute its
trapdoor. So it's this asymmetry that we will exploit as we go along.
So before I move on to the constructions, are there any questions about lattices?
>>: You had your lattice over the integer. Now I see Z of Q, which is a field so ->> Shweta Agrawal: No, a lattice is over integers. It's congruent to something
mod Q.
>>: So it is -- I mean so it's hard to talk about lattices because, you know, they
are really intimate objects, right?
>>: Yes.
>>: So how do you pick ->>: You pick a subset until the numbers ->>: So really what's happening here is that you are considering specially class of
lattices where all that matters is this Q. The rest of it is like semantic like, you
know, same [inaudible].
>>: Sure.
>> Shweta Agrawal: So it's also that the results that you know, this how to
generate the lattice with the trapdoor, these are also all for these Q lattices. So
we restrict our attention to those lattices. Although lattices in general, I mean not
just these lattices, but even other lattices have tons of applications even in other
areas like communications and so forth. But these are -- we only talk about
these special Q lattices.
So let's move on to our results. So we're going to construct identity based
encryption from these lattices in three different ways. So the first way this was
the first lattice IBE in the standard model, and as I mentioned it was
independently discovered by CHKP10. And it's a bit-by-bit IBE. I'll talk about
what that means.
So before I talk about any identity based encryption, let's take a look at the
Regev public key encryption scheme that uses lattices. Because our identity
based encryption schemes are going to build upon this.
So the way that encryption happens here is as follows: So recall that AE equals
U. Mod Q is hard to invert where E is a small -- a short vector. So our secret is
going to be the short vector E. And our public parameters or the public key is
going to be the matrix A and the vector U.
So to encrypt what you do is the following: You set C0 as A transpose S plus
noise where S is some ephemeral random vector that I pick each time I encrypt
and then I just throw it away. So the encrypt algorithm will first this random
vector S. And it will set C0 as A transpose S plus some noise. So never mind
right now what this noise specifically is. The point is that it's small enough. It's
not too big. So it doesn't completely destroy the rest of the information.
And then I have C1 which is U transpose S plus noise, and there's a message
somewhere.
And to decrypt, I'm going to do E transpose C0 minus C1. So what's going to
happen is E transports, A transpose will become U transpose so these two things
will cancel out. Now, note that -- and really this is the crux. So note that E being
[inaudible] is absolutely crucial because when I do E transpose CO this E also
multiplies with this noise that I added.
So it's absolutely crucial that this E be small so that the noise even at the end of
the day is small enough that it doesn't destroy my decryption too much. So I'm
going to be left with message plus some noise and the hope is that the noise is
small enough that I can still guess accurately what the message is.
So I'm going to refer to this matrix A as the encryption matrix. And in all my IBE
systems, remember what I need is I need to encrypt for a particular identity. So
what I'm going to do is I'm going to make this encryption matrix depend on the
identity for all three systems that we'll seek.
But apart from -- apart from constructing an extract algorithm and constructing an
encryption matrix that depends on the identity, my encryption and decryption
mechanism will remain the same. So that's why it's really good to keep in mind
how this works. So let's move on to the IBE construction. So I have some matrix
A0 that's part of my parameters. And the master secret key is going to be a short
basis for this matrix AO.
Now I need to extract a secret key for this identify, see, for 01. I need to
construct a secret key. So the master secret is a basis for A0. And I need to
construct the secret key for this ID 01.
So what I'm going to do is I'm going to define this encryption matrix as A0
concatenated with A10 and A21. So in my parameters, I have one matrix or
rather I have two matrices per bit. So if I have two bit identities then I have an
A10 and then A11. And I also have an A20 and an A21. And for K bits I have
two K such matrices.
And for a given identify I construct the encryption matrix by first putting in the A0.
I'll always put in the A0. And then I'm going to choose the -- I'm going to choose
the matrices corresponding to the bits of the identify.
So at position I I'll choose matrix AI with the super script equal to the Ith bit in the
identity. And this is why it's called bit-by-bit, because I'm going to have one
matrix per bit.
So my encryption matrix grows linearly with the identity.
>>: [inaudible] essentially also ->> Shweta Agrawal: Should contain.
>>: Two times K?
>> Shweta Agrawal: Yes, yes. So, yeah, that's a little bit misleading. So not just
A0, but it also contains this A10, A11, A20, A21 and so forth.
So this is how we construct this. And as I mentioned, notice that this matrix
grows pretty quickly. So for a K bit identify it's K plus 1 times M because M is the
-- is the fatness of a given block. And I have K plus 1 of them that I'm putting
together.
Now, using some reasonably simple linear algebra you can actually compute a
trapdoor for this -- for an extended matrix. Like if you have a trapdoor for a
matrix T2, you can construct a trapdoor for T1 concatenated with T2
concatenated with T3. And this helps you, right? Because you have a trapdoor
for this, for A0. You have a basis for A0. And this mechanism which I won't go
into, will allow you to construct a basis for this extended matrix.
>>: For every identity.
>> Shweta Agrawal: Yes.
>>: [inaudible] choice.
>> Shweta Agrawal: Yes. Exactly. So any -- I mean, as long as I have a basis
for some block in the middle, I can always construct a basis for the extended
matrix.
>>: Trapdoor [inaudible] had the 2 to the K trapdoors for all possible identifies,
right? I mean, that's -- that's the --
>> Shweta Agrawal: Yeah. And then you can -- right. You can think of it that
way. And then, like I said, to encrypt for a given bit and for a given identity you
just use the Regev encryption that we saw in the previous slide, but now instead
of some A that was prepublished you now use this specially matrix that you
constructed.
So this is -- this is how we -- how we construct the first IBE. It's not very efficient,
but we'll make it efficient as we go along. And why is this secure? So how would
the security game work?
Let's look at the selective game. So let's say my challenge identity is 11. So
what I'm going to do -- okay. So first let's recap that we cannot have a secret key
for ID star. So we cannot have the basis for A0 in the security game.
So what are we going to do? We're going to choose A0 without a basis because
we can't have that basis. And we're going to choose the matrices corresponding
to these bits also without the trapdoor. So A11 and A21 are random with no
trapdoor. But they're going to choose the flips with the trapdoor. So A10 and
A20 we'll choose so that it does have a trapdoor. And you can immediately see
why this works because any identity which is not the challenge identity has at
least one green matrix somewhere in there.
And using the mechanism that I referred to, you can extend this basis to the
basis for the full matrix and you're done. But of course for the challenge identity
you have only red matrices and you cannot do anything. So that's why this works
broadly speaking.
Now we saw how we can construct a bit-by-bit IBE but it's obviously it's not very
efficient. And it's natural to ask if you can do better. And it turns out that you
can. So we'll now construct an efficient version of the same problem.
So this is the main result of this paper. So the system that I just showed you can
be captured by this gram. So let's say my identity is a K bit string. So for each
new bit I add one block, right? So for K bits I have my encryption matrix SK plus
1 times N in thickness. And the secret key is a basis of this fat matrix.
Now, I'm rolling the parameters as compressing M in terms of the security
parameter. It turns out that the secret key and the ciphertext are about N
squared bits and K times N bits respectively. So I'm hiding log factors in this
annotation.
But this is -- this is the result from the previous paper. And in this paper what we
managed to do is we make the IDs live in a much large space. So now the ID is
not a bit string, but it's a vector in this big vector space, ZQ to the N. And the
description makes remains fixed at a given dimension. So this -- so what this is
saying is that I can pick a big vector in ZQ to the N and that naturally that
captures -- like that's a big space. And for that given identity I can have an
encryption matrix which is fixed. So for all vectors in that space the size of my
description matrix is fixed at two times M.
>>: [inaudible] you can work with the larger identities. That's what your -- is that
->> Shweta Agrawal: For the same secret key size?
>>: You can work with the larger identities [inaudible] is that what you said?
>> Shweta Agrawal: No, actually I'm saying that even the secret key is much
smaller now.
>>: It's like [inaudible] right? I mean, you're saying the secret key is shorter and
the identity is bigger?
>> Shweta Agrawal: Yes. Yes. So it's actually monotonically better like there's
no tradeoff anyway. So the secret key is now a vector in this 2 M dimensional
lattice. And rolling I get an order N bit secret key and an order N bit ciphertext.
So notice that the K goes away. And the N squared becomes N. So it -- the IDs
are also from a bigger space and everything is just shorter and more efficient.
>>: [inaudible] depend on K?
>> Shweta Agrawal: No. So here I mean really in this system there is no K, right
because ->>: Oh, on the -- in the left. On the secret key apparently does not depend on K.
Let me think about it.
>>: [inaudible] K times N.
>> Shweta Agrawal: Yes, actually maybe there's a typo here. Because it's going
to be.
>>: K [inaudible] right.
>> Shweta Agrawal: It will be -- because the matrix is K times N and it's a basis
of that matrix so it should -- it should dependent on K. So maybe there's a typo
here. In which case the system is even better.
Yeah. So this is an unimportant table. It just shows that all the Ks go away,
every where. And what is the main idea in this paper? The main idea is that this
identity now lives in a much bigger space and it's encoded all at once. So it's not
bit-by-bit any more. So the encryption matrix encodes the identity all at once.
And how does it do it? So the master secret remains the basis for this matrix A0.
You can think of it as the same matrix. The real difference is just how the
encryption matrix is constructed.
So now given an identity, FID is AO concatenated with A1 plus ID times B where
A1 and B, these are two new random matrices that our system has. And I say
eyed here but it's actually hash of ID. It's a deterministic hash which takes the
vector and makes it a matrix. So because, you know, otherwise you will have a
dimension mismatch here.
So it's A1 plus ID times B. And the secret key for a given ID as usual is a vector
in this lattice, a short vector in this lattice. It's, yeah, a secret key always has to
be a short vector.
>>: [inaudible] ID times B, the ID is a matrix?
>> Shweta Agrawal: Yes.
>>: N by N matrix?
>> Shweta Agrawal: N by -- N by -- wait. B is N by N so ID is N by N, yeah.
Yeah. So yeah. And we have a construction in the paper that actually
deterministically constructs this map that takes it from a vector to a matrix.
>>: [inaudible] specially properties, right? I mean it just -- so if two IDs have the
same matrix, then it's kind of ->> Shweta Agrawal: Yeah. But it needs -- it needs IDs to -- it needs them to
have full rank differences. Because you know if you interact subtract ID1 -- like if
you do ID1 minus ID2, then the difference between the maps should be full rank.
Because otherwise you need a full rank matrix here, right? Because otherwise
like -- so we are going to have a trapdoor for B eventually. So if you have a
lower rank, lower rank matrix multiplying it, then, yeah, then that's not good.
>>: It's not any cryptographic property, it's just ->> Shweta Agrawal: No, no, it's a simple -- it's a simple construction. So the FID
is fixed dimension, right, because it's just always this for any identity.
And why cost this work? So recall the FID is this. Now, let's say that our
challenge identity is ID star. Now, of course we don't have a basis for A0,
otherwise we would have the master trapdoor. But let's say we have a basis for
this matrix B here. Now, in the simulation, instead of picking A1 as a random
matrix, I'm going to pick A1 to be the special matrix. A0R minus ID star times B.
So it's a little bit confusing. But so A0 is the same A0 that forms the first block of
FID and A1 in the main system, like I said, in the main system it's just a random
matrix. And B is also a random matrix.
But in the simulation I'm going to pick A1 to be special. It's going to depend on
ID star. So it's going to be A0 times R. Now R is another new matrix that we
bring in. It's a random low norm matrix. And you'll see why it needs to be low
norm. So A1 is A0 R minus ID star times B.
So now when you construct FID using this formula, with this special A1, you get
A0 concatenated with A0R plus ID minus ID star B.
And in this work we develop an algorithm to find a basis for FID given a basis for
B.
>>: For every ID not equal [inaudible].
>> Shweta Agrawal: Exactly, yeah. Because if ID is ID star, then you don't have
any trapdoor at all. Yeah. So to construct any new you trapdoor, you have to
start with some trapdoor. So that's the find of the ID minus ID star is that you
cannot answer the challenge for ID star. The B goes away, the trapdoor goes
away, and you're left with no trapdoors and no power to do anything.
So developing this algorithm was the key insight in making the system work. So
let's compare or rather let's recap the construction we just saw. The public
parameters are A0, A 1, and B, three matrices. In the real system, the master
secret is a trapdoor for A0. In the simulation you can think of the master secret
as being the trapdoor for B.
Now, in the real system A1 is randomly chosen. In the simulation it's chosen in
the special way. Like we just saw. And because R is a random matrix, the
leftover hash lemma tells us that these two matrices in the real system and
simulation are indistinguishable.
The encryption matrix FID is constructed like this in the real system, and
constructed like this in the simulation. Really using the same formula. It's only
the a 1 that changes. The secret key in both systems is a short vector in FID.
And in the real system the master secret implies a key for any arbitrary ID.
Whereas in the simulation the secret implies a key for any ID not equal to ID star.
Just a couple of words about this matrix R. It's just a random low norm matrix.
Each column is randomly and independently chosen from plus minus one to the
M. And A1 and A0 become indistinguishable from A0, AOR by the leftover hash
lemma which roughly states that R has enough entropy to make AOR look like A
1.
The security of the system and even of the previous system and the system to
come, all these systems, are derive their security from the learning with errors
problem which is by now a standard problem used in the lattice world. It was
introduced by Regev in 2005, I believe. And the problem is to distinguish noise
inner products from uniform.
So I'm given two different sample sets. Well, the second is just -- it's just
uniform. So A1 prime up to AM prime are just uniformly picked from ZQ to the N.
And the BI prime are just picked uniformly from ZQ.
>>: [inaudible] vector and ->> Shweta Agrawal: Orange is ->>: A number?
>> Shweta Agrawal: Is a scalar, yeah. This is ZQ to the N, and this is ZQ. And
the first sample said the As are picked exactly the same way and they're just
picked uniformly from ZQ to the N. But now the Bs are not picked uniformly.
They are noisy inner products. So first we'll fix a uniformly chosen S and then
we'll take the dot product of AINS and we'll add some noise to it.
So since you saw the Regev encryption system, you can see why
indistinguishability between these two immediately will imply security for a Regev
encryption -- the Regev encryption scheme as well as the schemes that we have.
So just to illustrate in the system we just saw, the ciphertext looks like this. The
C0 part looks like you transpossess plus some noise X and the message. So
this U and C0 looks like an LWE instance which is indistinguishable from random
and the C1 looks like FID transpossess plus some vector noise now which looks
like M instances of LWE. Takes a little bit of work to show it but you can show it.
Pretty much so in the interest of time, I'm going to skip the details of this security
game.
We really did go over it part by part, but let's move on to the third result.
The third result is a fixed dementia basis delegation for the lattice hierarchal
identity based encryption. So you're probably familiar with the notion have often
HIBE. The basic idea is very intuitive. In any organization or institution things
are usually arranged in a hierarchy, and you expect, you know, people higher up
in the hierarchy on somehow have more powers.
And that's captured in this system by requiring that any node in the tree should
be able to decrypt messages meant not just for itself but for everyone in the
subtree for who it's a root.
So here in this system at every level my -- I'm only adding a bit but more
generally speaking you can -- you can expect that at level 0 you have a K bit
identity, at level one it's 2 K bits, at level 3 it's 3 K bits and so forth.
So mathematically speaking the only thing that you need now is this derive is a
new derive algorithm. It's the top four algorithms remain the same as in a basic
IBE but you have a new derive algorithm that given a secret key can derive a
secret key for a node that lies below it.
So a secret key for ID 1 and a new identity which has ID 1 as a prefix are what is
input to the algorithm and the output is a secret key for this extended identity.
And note that the derive algorithm does not need the master secret. So the
result that we have in this work in spirit it's the same to the previous result that
we saw. So remember in the first result we had an encryption matrix that grew
with every bit in the identity and we manage to squish that down to a fixed
dimension matrix. Well, now what we do is exactly the same thing, but now we
do it across levels of a tree.
So using the -- if you use the basis delegation mechanism that has been
proposed by CHKP, what you did is you add -- you -- like every level of the
hierarchy you add a block to the encryption matrix. In fact, you add a K, K times
M length of block, you add K blocks. So there's K bits per level. Then for each if
you level you add K times M block to the encryption matrix. But what we -- so
what we do is we manage to keep this dimension fixed across the levels of the
hierarchy. So using CHKP10 at level 2, you would have a matrix of dimension 2
times K times M. At level D you would have a matrix of dimension D times K
times M. But what we have is a fixed dimension matrix across all the levels of
the hierarchy. And that's because we have a completely different way of doing
delegation which does not increase the size of the matrix.
So the secret key at this level at any level J is a basis of a J times K times M
dimensional lattice whereas for us it's a basis of this fixed dimensional lattice.
Now, I should mention that in the randomly oracle model this is always better
because the Ms are the same. But the reason I have M prime here is because in
the standard model unfortunately when you unroll the parameters it turns out that
the M is not the same M, it actually needs to be bigger.
>>: So really M prime is actually D times K times M then it's strictly worse, right?
>> Shweta Agrawal: Yes. So this -- so in the standard model this result is only
better in certain cases. It's not always better. And we actually -- so we found
that out one day before submission when we worked out all the parameters and I
was like oh, my God because we thought that -- so with lattices what happens is
you're just working with these -- you know, alphabets M and M and whatnot. And
then they have to satisfy certain dependencies. So at the end of the day when
you unroll, that's when you really get in bits how much -- how much is it.
So you'll see why this ->>: [inaudible] M prime is not just D times K times M but it's somewhat in
between M and ->> Shweta Agrawal: That's one way to think about it. But really it depends on
what D and K are. So M prime is a function of D and K and M.
>>: D times K times M?
>> Shweta Agrawal: Yes. But it also depends on -- so for longer depths the
system always does better because you can imagine that, you know, even
though it starts out big, as you go deeper and deeper, that big sort of is not as big
as the last level. But at the -- at the upper levels, you know, like if you just have
a depth 3, then it's possible that this is actually better because -- so it depends on
what K is and what D is. But more importantly I think it's a brand new way of
doing delegation. So it's an interesting new technique and our attribute based
encryption already uses ideas from here.
>>: I would argue this is an argument against the scheme [inaudible] are very
bad news in general for people [inaudible].
>> Shweta Agrawal: Well, I mean it is what it is. So, you know, it's unfortunate
that it's not always better. I wish it was but it is what it is.
>>: What you're saying it's a new technique and it's useful elsewhere as well ->> Shweta Agrawal: It's useful elsewhere and it's -- so this new way of doing
basis delegation could conceivably be combined with our efficient way of doing
basic IBE in some way and, you know, maybe there are just deficiency gains to
be had from combining them or like I said, it's completely different. So we still
have to explore what are the implications it has.
But it's only like the performance as compared to this depends on the values of K
and B. For some ranges it's better, for some ranges it's not.
>>: [inaudible] only systems are selectively secure, right?
>> Shweta Agrawal: As I am presenting them.
>>: But in reality I guess you know, if I want to attack your -- I'll create identities
while -- I won't [inaudible].
>> Shweta Agrawal: We have adaptively. That's what I'm saying. I'm just
presenting selectively for ease of presentation. But we have adaptive in all of
them. So the delegation mechanism very broadly. All right. So I have a lattice
A, and I have some basis B1 through BM for this lattice. Now, can I create a
lattice for a child along with the basis for this child in the hierarchy? So let's
consider this lattice AR inverse where R is your usual low norm random matrix.
Well, you notice that R times B 1 through R times BM is a basis for this lattice
just cancellation, right?
And it turns out that if you randomize these basis which you need to do, then this
new basis is not much bigger than the parent basis. So what we'll do in the
system is that every child in the hierarchy is associated with one such R matrix.
And the parent delegates his basis B by multiplying by the child's R matrix.
So again, this is a very broad view. So this is -- it's fairly technical to show but
broadly that's what's going on. So the parent has a basis B and maybe I have K
children R1 through RK. Well, each associated with this matrix R 1 through RK.
Then the children have basis R 1 B all the way up to RX times B.
Now, note that though RI is low norm, RI inverse is high norm. So as a child, if I
have a randomized basis RI times B, I can't go back to my parents basis which is
what you want. So the child basis does not leak the parent basis.
So the HIBE construction you can think of it like that. So you have a matrix A at
the root. Now, again here I'm just showing a binary branching for simplicity. But
I have an R matrix at every node. And what -- when I said each child is
associated with an R matrix, so it's not just this R matrix. This child is associated
with the product of all the matrices that lead up to it. So this child will have this
and so on.
So the encryption matrix for this child is going to be A, the parent -- I mean the
root times the product of these matrices inverse.
And here's the another example of the same point. And like we saw in the
previous slide, a basis for AR inverse will imply a basis for ARI inverse RJ
inverse. So that's how we would delegate.
So we develop new tools in this partner. We developed these two new
algorithms called sample R with basis and sample R. And this is what we use in
the simulation. I'm going to wave my hands a lot, but -- so sample R with basis.
It takes a matrix A, and it can sample a low norm Gaussian matrix R such that I
have a basis for AR inverse. And the sample R will just sample a low norm
Gaussian R.
And the main -- the main technical hurdle that we had to overcome in the paper
was to show that the distribution of these -- of the Rs produced by these two
algorithms is indistinguishable.
So what that says is that Gaussian sampling from a random sublattice is
equivalent to Gaussian sampling from a lattice. So either I can sample a
Gaussian from a lattice or I can first choose a sublattice and then I can sample in
that sublattice. And we can show that these two things are indistinguishable.
So the simulation. So let's say the challenge is 001, right? Now, I'm going to get
the A0 matrix from the hard AWE problem. And I'm going to set the route A as
A0 times the product of the three matrices corresponding to the challenge in
inverse order. Right? So R10 is in the end and R31 is in the beginning. So it's
in the reverse order.
And I'm going to construct the tree just as did I in the main system. So just at
that time A is now special. And I don't have trapdoors for these -- for the R
matrices corresponding to the challenge bits. And what do I mean by trapdoors?
I mean the -- like in the previous slide we saw the sample R with basis and we
saw the sample R. So if I do sample R with basis I get an R such that I have a
trapdoor for AR inverse. And that's -- so this is the A. So if I do the green matrix
means I have a trapdoor for AR inverse, but the red matrix means this was just
chosen from sample R. So I don't have a trapdoor for this times this.
So in this tree, I have a bunch of red matrices, and I have some green matrices.
>>: Most of them [inaudible] the only red matrices are the ones corresponding to
this path?
>> Shweta Agrawal: Yes. Yes. So let's look at the encryption matrix for F00.
It's A times the product of these inverse as we saw in the system. Now A is itself
a product of these three guys: So unrolling you get this. So you get some green
matrix. Right? But if you look at something along this path, so notice that the A
already has these three matrix -- matrices embedded inside it. So when you do
the product of these three inverse, you're still left with no trapdoor. There's no
green anywhere.
So just to recap for F000, if I choose any path along which had there's at least
one green matrix I cancel out some red matrices. But there's one green matrix
that I don't cancel. So I have a trapdoor for this matrix. But for anything along
the path I don't have any trapdoor.
So a green matrix implies a trapdoor which implies that I can answer queries.
So in conclusion, this is a very different delegation mechanism from the previous
delegation mechanism which was just appending matrices along every level.
And it's always better in the random oracle model, significantly better. Like the
factor of B goes away from everything. So if you had a D square in the secret
key, it goes away. All the Ds go away.
But in the standard model, unfortunately, it's not always better. It depends on
your values of K and of D. But, well, to me the main contribution of this work was
that there are very different and new lattice tools that we expect to be useful in
future constructions. So that -- that brings us to the conclusion of the three
problems. And I think I'm out of time. So maybe I'll skip the future directions.
>>: [inaudible].
>> Shweta Agrawal: Okay. We can -- I -- well, it's just a cute animation actually.
So I'm not going to talk anything technical, but I like this animation and it will take
a minute.
So I have a Professor Merlin who wants to encrypt a file so that other professors
or admin assistants of the crypto group can open it. What do I do? So does the
professor encrypt a file for each of them? And what if someone quits and some
new person joins? Then again you have to reencrypt everything for each person.
And this is an organizational nightmare.
So what he really wants is he wants a key for this formula, right? So professor or
admin and crypto group. And this is the notion of attribute based encryption, this
very clever elegant technique introduced by Sahai and Waters in '05.
How does it works? So here's the professor and he wants to encrypt this file. So
he sends his formula to this key authority. Now, the key authority, well, these
authenticate him first, but then she will send him a key for this formula. And the
key authority goes away. And the professor now encrypts his data using this
key. Right? Now, using the formula, rather, he encrypts the -- the ciphertext is
encrypted using the formula, and here is this key.
Now, what he can do is he can give this key to legitimate users, but maybe
there's someone else who also wants to get hold of this data, but he does not
have the right key. So when they all try to access the information, as you can
imagine, the authorized people get it and the unauthorized person doesn't.
So it's just saving that, you know, instead of -- like, if I want to encrypt to a group
and this group has certain attributes. So I can encrypt broadly speaking just to
those attributes. And whoever satisfies those attributes will decrypt it. So I don't
-- I don't need to bother with who the actual people are. And I don't need to
encrypt separately for all those people. So I can just encrypt saying, you know,
maybe researchers at MSR can access this but researchers at Google can't or
whatever. [laughter].
>>: [inaudible] says professor gives keys to [inaudible] that's [inaudible].
>> Shweta Agrawal: [inaudible].
>>: Something that you think they will go to the authority ->> Shweta Agrawal: Yeah. So this is -- yeah. The animation is -- it's actually
loose. It's just trying to illustrate this idea. But, yes, the people will actually have
attributes of their own, you know, and their keys sort of -- you can think of their
key as a bunch of their attributes. So my key would be my name, my graduate
institution, maybe my advisors name or the field I work in or whatever, and then
maybe you'll encrypt something that says well, you know, students at UT or
students at Stanford and researchers at MSR can open this so I can open it and
Vinod can also open it but someone at Google can't open it, stuff like that.
So after identity based encryption it's natural to want to think about attribute
based encryption, and that's the new work that we have, that we are doing. So
that concludes the talk. Thanks.
[applause].
>> Shweta Agrawal: Thank you. Any questions?
>>: [inaudible].
>>: I could send you some numbers. How much is [inaudible] let's say it's
Microsoft e-mails are eight characters, right? You want some sensible security.
What sort of numbers are you talking about?
>> Shweta Agrawal: So I don't have a precise answer to your question naturally,
but I mean I haven't implemented these systems yet. But so actually the systems
or the lattices that they use in these systems are general lattices. And like I was
mentioning to you before the talk, we expect the actual implementations to use a
more specially form of lattices called ID lattices.
So it wouldn't even really make sense to implement it, you know, right away in
this. I think the more sensible direction would be to try and convert these
systems to use these other special more efficient lattices and then implement it
and see what numbers you get. But Vinod has been telling me that some people
at MSR, in fact, have actually implemented not our systems but some other
lattice based systems and ->>: [inaudible].
>> Shweta Agrawal: Okay. So just a public key encryption system. And that
works as well or faster even than the bilinear maps. So in lattices one advantage
-- well, the way I look at it is that especially going forward, you know, as
computing power becomes more and more unique, even more and more
security, sort of asymptotically lattices are very, very efficient.
So, you know, as we go into the future and we parallelize things more and we
need even higher levels of security I think these will become even more practical
then. But with ID lattices, these special lattices they're already practical. But like
the ciphertext and the keys are in the order of a couple of kilobytes right now with
our system. But we expect it to improve.
>>: And what are the times ->> Shweta Agrawal: Unfortunately I don't really no. But the lattice -- well, but I
can give you an idea. Because the lattice is about maybe dimension 1,000. So
your -- it's maybe you think of thousand by thousand or thousand by five
thousand actually. Thousand by five thousand. And you're doing dot products.
So it's 50 -- well, it's -- it's for this big matrix you're doing dot products, so ->>: At what point is it [inaudible] for example if you want to decrypt you
exponentiate and ->>: [inaudible].
>>: Yes.
>>: And here it's a dot product so, you know, [inaudible].
>> Shweta Agrawal: That's the ->>: [inaudible] parallel ->> Shweta Agrawal: So that's the reason we hope that these systems will
become practical pretty soon. So right now the lattices are pretty big. And, you
know, you have to do so many -- like you're just doing dot products and you're
just doing additions and multiplications but there are so many of them that it's still
a little bit slow.
But with ID lattices and when we need even higher levels of security and, you
know, the other systems suffer from there we'll suffer less, so to speak. So they
scale really well inefficiency.
>>: Thanks.
>> Shweta Agrawal: Sure.