>> Kristin Lauter: Okay. Thank you very much for coming. Today we are very pleased
to have Brent Waters speaking to us on unbounded HIBE and ABE and Brent will be
receiving a faculty fellowship today, so congratulations, Brent.
>> Brent Waters: Thank you.
>> Kristin Lauter: And we are very pleased to have you here.
>> Brent Waters: Okay. Great, thanks Kris. I see a lot of people--I guess this is a point
of convergence over the summer. I see a lot of people I know from different places. So
today I am going to give what is going to be a little bit more on the technical side of this
functional encryption domain. I am going to talk about unbounded hierarchal identitybased encryption and attribute-based encryption, and I will discuss what I mean by
unbounded soon.
This is joint work with my student Allison. Just a couple of big picture slides before you
start to type out the technical details, to put this in context, one grand notion in
cryptography has been the advent of public-key cryptography where if Bob wants to send
a message to let's say Sarah over here, he doesn’t need to have a operational shared secret
key with Sarah and instead what he can do is he can use her public-key to encrypt a
message for her, and then send it on over to her and she can use her secret key to decrypt.
I am sure here everybody is pretty familiar with this notion. However along with this
great advent though have been too ingrained notions in our head. First one is that when I
am encrypting to someone I am usually targeting a particular receiver, that is, I am
sending to you or so I have someone particular in my mind to which I'm sending. And
the second one is that decryption is an all or nothing process as I either decrypt the
message and learn everything about it, or I don't learn anything at all. And maybe instead
we want to learn some type of function or partial view of the message depending on what
our credentials are.
The problems with this are, let's imagine Bob is in a different scenario where he doesn't
say okay, I just want to encrypt to this user Sarah anymore, what he wants to do is he is
thinking about sharing information let's say in the LAPD with everyone who is in internal
affairs or who is an undercover officer in the Central division. Now when he is thinking
of sharing information this way, he runs into a few problems. First of all, how does he
figure out everyone who matches this? He has to have some process for enumerating
one. Also is he even allowed to know everyone that matches this? Maybe it's not a good
idea to be able to enumerate all undercover officers, you know, it might defeat the
attribute.
Second, what if someone joins the system later? I want to encrypt everyone who, you
know, has and will match this profile, but I don't know what the future holds, like I don't
know who is going to be here next summer at Microsoft. Instead we want to have a
process view of the data. So instead of like in the past where what we had to usually do
was we had to transform, somehow engineer our way between how we think of data and
this mechanism for public encryption, which could be a messy thing and there might not
be solutions in all these cases. And so with the vision of functional encryption does is
instead of trying to just bridge this gap with engineering, I want to be able to when I think
of sharing information in a certain way, I want to be able to express this or embed this in
the encryption system itself. So this is like I decide to throw these couple of borrowed
vowels inside to throwing these things to try to give maybe the big picture of what we are
looking at that will hopefully motivate some of the things we are working on. So today
what I am going to do is I'm going to talk about two specific primitives within this-- so
this functional encryption idea is this big umbrella and I can cover a lot of different
things, and here what I am really going to do is talk about two particular problems, to
specific things, attribute-based encryption and HIBE.
Let's take a look at hierarchal identity-based encryption and just to get a sense, how many
people are familiar with this? Most people in the room? Okay. The idea and most
people are familiar with identity-based encryption? Okay. Identity-based encryption is
where when I want to encrypt the message, I don't need to look up, I can just described it,
I can just describe it with your name or your identity. Hierarchal identity-based
encryption can be thought of somewhat as a generalization of this where the name is
more like a vector of names. For example, you might think of a hierarchy on the internet,
EDU.U Texas, I guess it is the opposite direction, the way that internet puts it. EDU:U
Texas:CS: B Waters. And the idea of hierarchal IB is say some user, there could be some
master authority who generates these keys way up there who is not even in the picture
and let's say there is some user like Allison here who has the.edu one, and what she can
do is well, she can use it to decrypt things in the EDU but she can also create keys further
on down the line, maybe Stanford is over here, and you Texas is ID2 prime, and then we
can go on down to say yes, and delegate on down further. Hopefully the benefit being
that it's easier for let's say this guy to know which departments the University of Texas
has as opposed to someone way up higher on the chain. So it's good that this has become
a brief introduction here, so Alice can have her key and autonomously create these
private keys. She doesn't need to go back up to authority.
So let me just briefly go through HIBE and anybody should stop me if they are--I am
going to go through this a little bit quickly, because I am assuming there is some
familiarity with it, but please stop me if there is a point of confusion. So there is going to
be a set up algorithm where this authority will generate the public parameters and also
generate a master secret key pair. Then there is going to be an encryption algorithm
where I'm going to want to encrypt the message M, use these public parameters, and
describe how I am encrypting it by this vector of identities. So let's say I am encrypting,
and I would just keep on using the same example, I am encrypting again to like EDU.U
TEXAS:CS:B Waters. And then there is a key generation process which the master
authority designates a private key for perhaps a different identity vector, I so again one of
these hierarchal ones and like create the secret key for this and then finally there is, so
that is to get it from the master authority, but also if I am somewhere on this chain like in
Kristen's group, she might want to delegate on down, and she will execute this algorithm
which she can take her secret key and create one sort of lower on the hierarchy below
that.
And finally there's going to be a decryption rhythm, where if I have a private key, so let's
say if a ciphertext was encrypted for an identity vector, let's call it X and I have a private
key for identity vector Y, if Y is a prefix of X, I can decrypt. Uh-huh?
>>: So [inaudible] and delegation generate the same type of key or the same [inaudible]
key to a given identifier?
>> Brent Waters: Let's assume that they do for now. You could have systems where you
could differentiate between them, but let's just assume that we require that they have the
same distribution. Fair enough? Okay. But you can actually gain some efficiency in
practice by relaxing this a little bit. But yeah, let's assume that that is the case. And one
of the goals with hierarchal identity-based encryption is that you get this flexibility. First
of all new users can enter at any level, and you can sort of get your key from the
immediate supervisor. Let's say if Kristin hires someone which apparently she has done
for the summer, she doesn't need to like call up Bill Gates or Steve Ballmer and, not that
that would literally happen, but it she can autonomously make decisions. She has this
local view within her group and it is probably the case that like the people way up at
Microsoft, I am sure they do care about you, but they probably don't, right? They
probably--they care about you but they probably are not knowledgeable about you. And
it is much better if she can make these local decisions. And we can encrypt any ID string.
And it is even less likely that someone@the.com domain knows about your summer
employment.
So in HIBE systems what we have is we can have an ex-potential size identity sort of
horizontally. And what I mean by this is that at each level the string can be of any length.
I mean, just using collision resistant hash functions, we can make the string of any length.
But one question I am going to ask here is using Kristin's system, what about vertical
growth? How many levels do I want to be able to go down? So what we have had in
previous systems is that we always had to when we set up the system we had to set up the
depth of the hierarchy. When we publish the public parameters we have to say that this is
going to go to depth seven. This is going to go to depth three. We had to kind of pick
something ahead of time and the reason that we don't just pick depth 10 billion or
something is that the size of the parameters tends to scale linearly with the depth. So we
kind of end up in this funny situation where you have to take this guess ahead of time and
if you are overly conservative, you might pay a lot in terms of performance. However, if
you really want to keep things small, keep things compact, it might turn out that someone
needs to go down to a certain depth and you cut them off earlier, and that could be a
problem.
We will see towards the end of the talk that in HIBE somebody could say well, maybe 20
is good enough for all applications, but an attribute based encryption this sort of a
pedagogical, we will spend most of the technical time on HIBE, but in attribute based
encryption I think that this scenario becomes more motivating where instead of bounding
a depth, you are bounding the number of attributes that you can use. That is probably-even though I am going to talk about HIBE, I will kind of remark that perhaps a stronger
motivation comes from the attribute based encryption. So we will kind of learn, but the
main technical things we can learn in the HIBE world; it is a little simpler, so I am going
to focus on that, but just keep in mind that this is where we eventually go to.
So before in previous systems we always had to have this bound of the depth for two
different reasons. The first one which we used to have was security degradation where
we used to have these partitioning improves for security, and for adaptive security we just
had an ex-potential loss in the depth of the hierarchy. I don't mean to make this into a
quiz or anything, but how many people have heard of this problem for maybe… So if I
want to go to depth D, I usually have if there were two queries--you said I get to use the
whiteboard, right? So later on I am going to want to just move it. Is that a doable thing?
So if we had two queries and then we had a depth of D, the security loss on all of these
reductions, you lost this Q to the D factor. So if you went to depth six, so this is expotential in the depth D, so this was not such a good thing. But actually it did turn out
that there were techniques first by Craig Gentry and then [inaudible] Levy using one
thing and then myself using something called dual system encryption that I actually got
around this problem, so we just ended up with 1 over Q. We did not need to worry about
this depth of D factor.
But even with this…
>>: What was the [inaudible] for?
>> Brent Waters: Private key queries. So an attacker can make queries to KeyGen and
to Delegate so this was for adaptive security by the way. If we made this false
assumption, it actually tells you which thing he is taking ahead of time. It is tight, but
take for a false reason.
>>: Solution [inaudible].
>> Brent Waters: Both. This is the first one. But then Allison and I had some other ones
along these lines. There are different systems, technically, although they clearly have
inspiration from more than likely just wipe the board clean. But yeah, we needed to
change the system too. Yeah, I can talk about that off-line. It's almost like the same
system. You can prove it secure in two different ways but it is not quite the same. Okay.
But even if we believe the selected model and now that we do have these proofs, we have
another problem, which is that the parameter size, like I was saying earlier, does dictate
how far we can go down and we are kind of--if you think you are trying to export an AP-let's pretend we are cryptographers but we are trying to export this API to some systems
person. They have to make this arbitrary, they have to make this guess about how big
your system is going to be, how deep it is going to be, or in the case of AB how many
attributes you are going to use. It would be better not to force them to make this guess.
Because they have this trade-off and if they want to help performance, they're going to
have to go one way and however, if they go too far the system won't work. So pretty
much in all previous constructions, I should say in the standard model random oracles
you can play a few tricks. It had these limitations and also there is this lattice stuff and so
a lot of the stuff had unique innovations, but it really follows kind of the high-level, and
control stuff like you have all this fancy lattice stuff going around but at the commentary
level it is really the same as the old pairing-based constructions, and so it has the same
limitations.
So I want to do something a little experimental. It is okay. I am under control.
[laughter]. How do we raise the board? There is considerably a button. Uh oh, did I
just, is it so revolutionary that we don't know how to…
>>: I think it is right back here.
>> Brent Waters: Oh boy. Okay. So I might ask you to lower it again Josh. We are
going to try something a little bit experimental here. And we can see if it was a good idea
at the end of the day. I get my award whether it works or not [laughter]. Okay so, what I
am going to do is I am going to write down the Boneh-Boyen system and we are going to
just kind of work out some things on the whiteboard. So I am going to start off with the
Boneh-Boyen based encryption system, and I am going to show you some possible
improvement I have for it and then we can kind of see how it works. It is good to prepare
for these things, which I sort of did. So we are doing IBE right now. That is okay? So
not HIBE for a second. How many people [inaudible] how many people have seen the
Boneh-Boyen system? Okay. So there is going to be a set up. I will be a little loose with
notation. We will pick these elements in the bilinear group, U, GU and H. I am going to
assume no in bilinear maps and there is going to be E of GG to the alpha, where this is
the public parameters and the master secret key will be alpha. Good thing it was G, alpha
[inaudible]. And also the master secret key has the public parameters too.
So what is the next algorithm we want? We want an encryption algorithm, right? We
want to be able to encrypt M given the public parameters and ID. I am also going to
define this one function, F of ID is equal to H of ID, so remember this, what is the
Boneh-Boyen hash function?
>>: G1 to the ID of H?
>> Brent Waters: Yeah, so actually I am going to use U in this case. So to encrypt I am
going to choose a random S and choose exponent S and I am have M times E of G, G to
the alpha S. this is going to be my ciphertext. Let's call it H of ID, any questions here? I
just choose a random exponent S, I take UGG to the alpha, raise it to the S to get this
blinding factor so I blind my message by this. Take G, I can raise it to the S and I can
compute this function H of ID and I can raise that to the S, so we agree that it is
computable? Now what I want, is I want a KeyGen function of, ask it secret key and ID.
here I am going to choose, so G is of order primordial P, okay? Please stop me if there is
any confusion on this and let's see here, marker, okay so we have G to the alpha times H
of let’s call this ID till or something, right? Maybe it is different, to the S, no, no to the
R, yeah, and that should work.
So this is how we encrypt. This is how we generate a private key. And now for
decryption pretty much we just pair this part, so really for decryption, we talked about
getting the message M but once you get this, you divide it out and you get the message
M. So we are really trying to recover this, so we pair this with this, and that with that and
we end up getting this part over here. I am just drawing decryption now which is E of H
of ID comma G the RS. So here when we pair this, we actually get what we want. We
get E of G to the alpha S from this thing over here. We get what we want but we also get
this extra junk over here so we get hash of identity to the RS. However, if this I is equal
to, wait a second. Yeah, I lost a term, so I get E of hash of I… Okay and if I is equal, if
this ID from the ciphertext is equal to this ID from the private key, we can just divide this
out of here and get what we need.
Any questions on this? This is the Boneh-Boyen system. I made this identity function
here a little abstract but if we plug-in their—let’s just plug it in to make it a little bit more
concrete. So this will be U to the IDH for the S And then we will do the similar thing
over here. So now what I want to do is I think we may be shaved down the parameters
just a little bit in the Boneh-Boyen and system so I want to propose an improvement and
then see how that goes. Yeah?
>>: I need a reminder here. So it is okay if my ID is like one more than your ID and the
hash is actually U [inaudible]?
>> Brent Waters: In this hash function? Yes.
>>: So there is no [inaudible].
>> Brent Waters: No [inaudible]. But let's take a look at my improvement.
>>: We will see how it goes.
>> Brent Waters: So suppose, so what I want to do now is I want to shave off a little bit
since this looks a little extraneous. So here is my new hash function. So maybe this is
the starting point to the talk that I am going to have here. And of course you will just
make the same change to the hash function down there. So what do people think about
this?
>>: It is insecure.
>> Brent Waters: It is insecure why?
>>: Just [inaudible].
>> Brent Waters: Okay. What I am saying is that suppose I have an encryption for ID
and I want to change it into one for ID prime under the same message. So maybe I have
the private key for ID prime, but I don't have it for ID. How can I do this? What do I do?
>>: [inaudible].
>> Brent Waters: I raise this whole thing over here to ID prime over ID. So I have the
one over ID part here which cancels this out and then we raise it. So this malleability
attack. I get this so I shouldn't be able to take ciphertext for message M for a certain ID
and just change it to ciphertext for another ID is what I am saying. And this maybe
relates to your question a little bit. It's bad to be able to do that. And apparently with my
new improvement--okay, this may be the way to look at it in the system but I think there
is kind of like a different view like we can take sort of a linear algebra view of what
happened in this attack. The earlier system we believed was secure or at least, you know,
assuming that there is not a break in the paper that is been out there for seven years. And
if we think about what is going on in the ciphertext, what is really happening over here,
so back when we had the H in there, we can kind of right what is happening in the
exponent as a vector. It is like the scaler S, which is hidden times ID, so this is the U
component. I am writing the U component here and the H component was 1. If I wanted
to change it to, and I get one sample of this, from the ciphertext, I get one sample of this.
So if I want to do an attack I pretty much have to change this to ID prime. So what I
have here is I give one vector from a dimensional 2 space. This is a dimensional 2 space.
And there is no scaler symbolically that I can multiply this vector by to get this vector.
Ignore the S even. There is no scale I can multiply assuming ID is not equal to ID prime.
So this is kind of a simple thing.
When I did this so-called improvement over here I kind of--here is my improvement.
What I did is I got rid of this dimension and now we had a one-dimensional vector space,
which I gave you one vector from and I am not very good at linear algebra but it means
you can spam the whole space. Mathematicians can confirm this. So you see the
problem was here that I wanted to give out N things and that meant I had to have N +1 at
least N +1 dimensions sub space. Any questions on this? So we can kind of see this
problem in just the ID context if I want to shave things down a little bit further. Is this
okay for me to do this little white board? I wanted to do something a little different.
So now let's look at HIBE. So the HIBE system… Yeah?
>>: [inaudible].
>> Brent Waters: In the selective security model it was under decisional BDH.
Although right now I am just looking at how to break things. Yes, it is bilineal diffie
home intersumption. If we want to do hierarchal IB but say to depth two, really the
Boneh-Boyen system was actually a hierarchal IBE scheme so instead of having one hash
function, first of all we have one hash function, for the second level we add a different
one and so we might get something like hash of, yeah, a little messy here. How does that
go? So I might get hash of, let's call this R1, hash of ID 1 to the S and this is hash of ID
1:ID 2 to the S. and then if I want to delegate on, oh shoot. Let me get this out of the
way. I will make it simpler here. Let's say I had ID 1 over here and want to delegate on
down to ID2, I just pick a new R2, so, sorry. Hash 1, hash 2 so hash 2 of ID 1: ID 2,
some kind of, I'm doing delegation dynamically on the board. Okay, so I just pick a new
R2 myself so this is Kristin delegating to a group. She picks a new R2 and then has G to
the R2 over here. And to decrypt, we can just kind of do these pairings. Like we just get
this UGG to the FS and then we have two things we need to cancel out here, so the
cancellations will come from these two parts. I won't draw this. I want to ask you a
question, since my first improvement didn't go too well I am going to… Do you have a
question? I was asking a question. [laughter] okay, what is your question?
>>: Is it possible to have [inaudible] that allows encryption or can only be used for
[inaudible]? Of course you can [inaudible] but not every [inaudible] can be used for
[inaudible].
>> Brent Waters: Yeah, I think you could do this in a generic way. So you're saying
what if Kristin is the manager of the group and I don't want her to be able to delegate on
down anymore? Yeah, I don't mean to bring you into every example. Yeah, because I
could just go to her level and then like have this null, null, null null, like kind of give her
nulls all the way down.
>>: [inaudible] ID. The left ID cannot be expanded by semantic…
>> Brent Waters: Yeah, yeah, yeah. So you could do kind of a, you could do it in a
generic fashion I think is the short answer. I kind of do delegate when I give her the key
I delegate. I assume there is a bottom. I guess it doesn't happen on Boneh-Boyen case
but assuming there is a bottom I could just bring her all the way down. Why don't I punt
a little bit on that one for now since it is kind of it is a little tangential. Now I want to
have another improvement which I thought of. So I'm going to try to still do this with
two parameters and here is going to be my hash functions. So let's see how these work. I
am going to replace these with something concrete. So before two parameters worked for
HIBE sorry IB, just one level is IB. And now I am trying to do it with two parameters for
level II and two parameters. We will save that until it actually works.
H to the 1 over ID, okay this would be raised to the S. So this is for level I, this is my,
and then this would be U to the ID squared times H base to the S. Now the question is…
What? So this is ID 1 and this is ID 2 [inaudible] whatever it is. So I am going to take U
to the ID 1, cube it, and H to the 1 over ID
>>: Over the whole combination of IDs or…
>> Brent Waters: And then the concatenation happens over here.
>>: So 1 over ID, is that ID 1 or ID2?
>> Brent Waters: This is ID 1 2.
>>: So that is from the [inaudible] ID 1s?
>> Brent Waters: Yeah, it only has ID 1.
>>: And the other one has…
>> Brent Waters: I am just kind of right now BS, so ID1, concatenates with ID2 squared.
So could this possibly work? Pretty complicated. I have some pretty complicated
looking stuff up here, right? But let's kind of look at the two things. Let's look at the
linear algebra thing. So here I have the vector S, so I raised U to the ID cubed and then I
have this as 1 over ID here, ID 1, okay Leo is going to make me be precise. And then I
have another vector which is S to ID 1 concatenate with ID 2 squared, 1.
>>: [inaudible]
>> Brent Waters: Okay. Don't study this too hard is one hint. What is the dimension of
this space here? Two. How many vectors did I give you? Two. So what can I do? I can
span the whole space again. Name me any AB, I can take some linear combinations of
these and give you this for A and B. This whole cubing and 1 over, I just made this whole
thing up. I did not actually think about this. We raise to the fifth or something, I don't
know. That's what I am saying. Don't, let's not worry. The point here is that we have,
we give away sort of two vectors and our subspace is dimension 2 and then we can spam
it. So I can mull it to anything I want. So compute it for a different ID. Compute any
two-level ID of your choice with--compute the hash functions. Compute what they are
supposed to be, compute the A part. Compute the B part. And you can use what is
already there to calculate it. That's the point. I just made up this cubing and raising to
the fifth thing or whatever. So don't study it too hard.
So this is the problem. The problem is in general like with these previous systems, so the
whole point of this exercise with these previous systems, if I wanted to have N instances,
if I wanted to have N levels, I needed to have N +1 size parameters. And some analog of
this would be true and actually be based in the encryption world. And this is not a good
thing. Part of the reason for this is because this global, like I am getting all these vectors
but they are raised to the same Fs. They are not like individually randomized each time.
But there is a reason for this. The reason I raise the same S is so that the encryption
works. Because I need, I paired this with S over here and I need everything. I can't just,
I need encryption to work. Having a nonfunctioning system is not a good option, so I
can't just make up random, you just make up stuff from over here.
So maybe this gives you some intuition as to why this problem, and this isn't just for
Boneh-Boyen; this is for other systems that have appeared so far basically fall into this
category. So Josh, we have a big task for you.
>> Josh: [inaudible]
>> Brent Waters: Oh, sorry. You have the experience. Any questions before it goes
down? Too late. And this is kind of what these two slides said. So that was my little
experimentation with giving a talk partially on the whiteboard. So these two slides
basically said what I said here. So our approach is to use some type of secret sharing plus
fresh randomness for each level.
>>: Before you go there, is this going to trade large public parameters for ciphertext?
>> Brent Waters: No.
>>: [inaudible]
>> Brent Waters: There are other bad things that it does not do. The ciphertext will get a
little bit larger but not, maybe like a factor of two larger, although there is a better way to
make it a factor of 1.5. But it won't like blowing up to N cubed or something bad like
that. Our goal is going to be able to do an unbounded system. I want to have a constant
number of public parameters, hopefully small content like three or four or five or
something like that, of group elements and be able to go anywhere I want with this HIBE
scheme. This will be kind of a high-level picture and then maybe looking at the actual
construction will help a little bit more. So there will be this kind of master secret which
is G to the alpha, for this alpha back here. And for each level or component we are going
to split this up into many different pieces that should go well together. But then we are
going to randomize each piece of your key. Let's not worry about the delegation for a
second. They need to be unrandomized in order to tie them back together. Then what we
are going to do is for the ciphertext we will be for vector ID prime and for each level-this wasn't the best notation Ice of I, each level what we are going to do is pair them
together and if these things match up right it will sort of paint this brush over it and then
after the pairing of the decryption we will be able to put them back together.
Let's just look at the system and hopefully I will clear things up a little bit. So public
parameters in the system, the actual description in the paper is going to be in some
composite order group mainly for the reason of the proof. But I am just going to give it
to you in the prime order version in order to make it a little simpler so we don't have all
these things flying around. So we are going to have five group elements, four in the
bilinear group and one in the target group. So this is a small constant. We can agree.
And the master secret key will be some exponent alpha. Let's look at how decryption
works. Let's say we are encrypting to a vector of length J like I am going J levels deep in
my, so I should be able to go to any depth I want. There is no bound. This is the point of
it being unbounded. So I picked this S which is the global S, analogous to what we saw
earlier, but also this ren is for each different level which we didn't see earlier. And now,
unfortunately this is a simpler version of the scheme. I wish I had time, this is the version
from the paper. So we take our message M blended by UGG alpha S. We kind of saw
that before. The G to the S part, but now what we do is for each different level, for level
1, 2, all the way to J, we have this W to the F term which is this global thing but the main
point to get across here is that we have this individual randomness on each level, and at
some level it prevents us notice this T cif I is present everywhere. This attack which we
had before of just doing linear combinations of things on each level won't happen, or we
hope it won't happen.
So there is something else going on here. So this T cif I is intuitively stopping us from
doing these linear combinations or at least we hope so, but we have to also hope that
decryption works, that it is correct, easy to make a broken system. So here is our mass of
authority doing our KeyGen, has this alpha which is the master set to the key and splits it
up into J, and so assuming the levels are the same, it splits them into lambda one through
lambda J such that the sum of all of them is equal to alpha. This is the secret splitting and
also chooses two random, two variables randomly for each level. And again, I am going
to try to focus on the part--okay, and then we have for each level, so kind of each level
will have a piece of alpha. And if we have all of these pieces, we can literally combine to
get alpha. And then there is something dependent upon identity of each level. Interesting
thing here even though we say well the Boneh-Boyen thing doesn't work for this, this
kind of remnants, it is almost like we kind of do the scheme locally, we almost kind of
push it back a little bit further like this does look like the Boneh-Boyen HIBE scheme.
At each different level we almost, you can imagine almost instead of having T of I so far
we had this global variable S and now were almost doing this HIBE thing locally at each
level. This is just what I talked about before, but let's look at how things might work for
decryption.
If we have M UGG to the alpha S, so we want to get UGG to the alpha S, so one way to
get UGG to the alpha S is if we just recover UGG to the lambda I times S for each I,
because then when we multiply all of these together, all of the lambdas together which
sums to alpha, so this is going to be our sub task over here. So one way towards getting
to it, so I am just showing you a piece of it, I am not showing you all of the ciphertext in
key is if we pair this together and then pair this together and then divide them out, so this
component paired with this component will cancel out here, so this will give you E of
GW to the S times YI and so what we are left with is something that gives us what we
want over here and something else that we need to cancel. So we get what we want over
here and then we need to cancel, but in order to recover it, we need to cancel out this part.
So this is some local thing. And now this part over here is actually canceled out in the
similar Boneh-like Boyen way or [inaudible] way with this local thing.
So here's like a little more detailed, pretty much what we are going to see is that the
theme of this is that we will get something that we want but it is going to be multiplied by
something that we don't want and we want to get rid of, and then we are going to want to
get that thing and get rid of it. But then when we go for that we are going to get it and
then get another thing, and it is going to be kind of a long chain of things. But it will
terminate which is good. So our first goal is to recover UGG to the alpha S because we
want this to get the message. And then we can do this, we can get a new sub goal of
recovering each of these UGG to the lambda I times S. please ask me a question if there
is any point here. Okay. So we can do this by pairing these two things together so we get
the S and the lambda I part here but then we get this extra junk. So we get the part we
want; then we get this extra junk, so now I have a new goal. I want to get this thing over
here, okay and then, okay but then we can get it by pairing this with this, but again so we
kind of get this thing that we need over here, but now we got that thing, sorry this chain is
a little long here. But then finally at the end we can actually get this apart with all these
cancellations. I should mention that there is a slightly simpler version so I wish I was
able to write out it. It is a slightly simpler version of this scheme which has one less
thing in the chain. It is a little bit easier to understand. I can show some people on paper
afterwards if you are interested.
The proof for this one worked out a little bit better. I just want to mention that key
delegation is, we want to be able to do delegation. That is pretty easy. Before we had it
at J levels, now we want to go to J +1 level, so you just pick this Omega 1 through
Omega J +1, that sum to zero and you re-randomize the key, so you tag on this extra part
to the key and then you re-randomize it. So this is not too much diff, I mean it
accommodates for the system. It is not too much novel compared to what was done
before. And then you have to also we randomize--so who asked this question earlier if
the keys were distributed--that was you Brian? So in this system we do distribute the
keys the same in both ways. You can probably improve the efficiency a little bit of
delegation by not doing it that way. But then your proof becomes harder.
So how are we doing on time Kristin?
>> Kristin Lauter: We definitely have the room until 12 so…
>> Brent Waters: I don't want to torture people that long.
>> Kristin Lauter: A typical talk is an hour.
>> Brent Waters: Okay. So I will wrap it up.
>> Kristin Lauter: So that's about another 15 minutes.
>> Brent Waters: Okay. That will be fine.
>>: The proof is only for the scheme [inaudible] or [inaudible].
>> Brent Waters: It is for a composite order. But I presented you the prime order thing.
You could do prime order in the generic group model or some not so awesome thing. I
think someone else, not me, is actually, so most of these composite sort of group things,
the point is to get the subspace, and you can translate it to prime order groups. But
maybe I will take--this is the system so. So before I go on to just discuss like at a high
level of proof, any questions on the system? So kind of the challenges that you want this,
you want this global variable in the ciphertext to tie everything together, you know, it has
to decrypt it. But we saw the spanning problem with the vectors so the technical
challenge was how do we randomize each level but still let things, we don't want things
to combine in the bad way is how a lot of this crypto--we don't want things to combine in
the way we don't want where we are changing all these vectors, but we do want things,
but we do want things to decrypt at the end. So kind of the trick was to get this kind of
randomize each level locally but still in a way that allows you to combine at the end.
Matt?
>> Matt: So there is some key policy ABs including yours where you got all these
essentially we share the secret to make policies that are more restrictive, and that seems
very similar to this so the fundamental difference is?
>> Brent Waters: This is, HIBE is a subset of ABE with delegation.
>> Matt: That means heightened security techniques aside from security techniques very
similar to that, do they [inaudible] that or are they…
>> Brent Waters: There are other techniques. I will briefly discuss the ABE thing, yeah
the techniques are similar. In some ways HIBE is just pedagogically easier to do, to talk
about right now. Yeah, I think ABE with delegation is more powerful.
>>: [inaudible] assumption?
>> Brent Waters: So the hardest assumption for this is some of these composite order
group assumptions, but I will mention that people have been able to take all of these
systems, built in the assumptions, people have in the past found analogues in the linear
assumption. It is not me, but someone else has already done this. So this is with some of
the subgroup like maybe through these subgroup type assumptions, but I don't know, I
kind of know this privately, so I don't know how much I can share, but someone else has
done this in the linear assumption.
>>: So is there a difference between composite and primordial [inaudible]. I mean you
threw a lot of terms there so it looked like maybe it would be some q less DA thing…
>> Brent Waters: There is no q.
>>: It is just, if your proof was in the primordial group it would be D [inaudible]?
>> Brent Waters: Yeah, in the primordial group, it is not that exact system that I showed
you. There's kind of a version of it someone else has it under Delin and in my paper it is
not q anything is couple, it is like three assumptions in composite order groups, but they
are static assumptions. They don't depend on q.
>>: [inaudible].
>> Brent Waters: I stopped giving them names. They fall within some class, different
subgroup type assumptions. I can show you off-line a little bit if you are interested, but
there is probably no efficient way to communicate them right now. But kind of the point
is I think, okay, now that I am on this, in some sense I see this stuff happening in, there
are kind of two different ways to do these things. If you do them with composite order
groups, you can usually get them without a q type assumption, but then the actual
assumption looks a little messy and some people go, oh my gosh, it is kind of confusing.
It is messy. But then there is the second phase which is translate, well, why do I do a
composite order group, well because I needed these subspaces and it is cleaner and easier
to do with subgroups. And then you can kind of, so this is where you can kind of develop
the main concepts. This is my own view of things. And then there is this kind of
mechanical part where you can take these concepts and then translate them to primordial
groups and get it under this like a decisional linear assumption which is a better
assumption then all of the ones we worked with. And actually I send my student Allison
has been looking at, you know, automating this. If it is best not to have to do it. You like
a quick way to do it. But in the past, all of these things have been translated over. So if
you name me any composite order scheme, I can tell you it has been translated over or I
think I can tell you it has been translated over or has been translated over.
>>: [inaudible] assumption [inaudible]?
>> Brent Waters: So if it is static, we are going a little, let me get back to that, we're
getting a little on a tangent here. Maybe that is best off-line. Okay so, I just want to give
you a little overview of how the proof goes. So the challenges here are that if you want
to do what is called a partitioning type proof, these things they always relied on you if I
had like the [inaudible] vector of length 10, I had to program in these 10 levels of identity
into the public parameters, well, or 15, or whatever. And now my public parameters are
only a size 5 for some small constant. So these partitioning don't look like they will all
work here. So that is a problem. But even with dual system proofs, it is kind of low
entry, they kind of depend on what I will call entropy to avoid some paradox and they
kind of always depend upon the parameters as been pretty big, so it wasn't even obvious
how to do it with these groups. But it turned out we were able to do this with dual system
encryption. And let's see, I am almost, but see, so I will give it a quick overview of dual
system encryption and, but maybe end the talk there and people can ask me questions offline.
Okay. Actually I will just skip a couple of the slides here because I probably won't have,
sorry, this whiteboard thing, I didn't know how long it would take. So if you are
interested in dual system encryption, you can talk to me off-line. So let me just conclude
by saying okay, so we did have this original motivation for a hierarchal ABE, but okay,
we could maybe argue this point little bit. You might be able to say well, what if you just
made them of depth 30. Maybe people won't go below depth 30. I am not sure if that is
actually true or not. Where I think it gets much more motivating is in attribute-based
encryption where, for example, the ciphertext is pegged with some metadata attributes
and uses key which is, you know, describing which ciphertext it is allowed to decrypt.
So in the past what I have had to do is the public parameters would give a bound of how
many attributes would describe something. And there it is a little hard to say well, what
should this bound be. You can have some time variables. You might come up with,
there could be some very short site, there could be some very short ones. And then
maybe every once in a while there are a few that go to a few hundred, and well now
everyone needs to pay the price for this. Moreover, until I compute these hash functions,
actually if you make your public parameters size N it is actually N squared and you need
N exponentiations for computing this hash function each time. So actually the
performance really hurts you much more than even the HIBE case.
So this is kind of the more motivating thing to me. And I will just say we were able to
extend this to attribute-based encryption. A lot of the--it follows reasonably easily. So
before this HIBE, you know, we split up this alpha into the secret lambda 1, plus lambda
2, plus lambda 3, plus lambda J is equal to alpha, here we just mainly, we grab a Boolean
formula, you know, like a secret sharing scheme associated with the policy, we just
reflect that secret sharing over there. Okay, and it turns out kind of weird thing is even
though we use dual system encryption proofs which is supposed to be good for adaptive
security, we were only able to get selective in this case for reason I can, so in the HIBE
we were able to get adaptive security. We had to sort of go back to selective security for
the attribute-based encryption world, which was a little funny in some ways, but for a
technical reason. Anyway this is where I think the motivation really helps out, because I
just have pretty much the same size, very small parameters and, you know, when I
publish my system, I don't have to commit myself to how many attributes I need.
>>: Are those technical reason something that are worth talking about is something
that…
>> Brent Waters: We would need to go deeper into the proof in order to explain the
technical, so I am happy to talk about it off-line at probably the amount of time we can't
do it. So any questions?
>>: [inaudible]
>> Brent Waters: You didn't get what I meant. So this ciphertext is pegged with two
attributes, right? So what is the maximum number of attributes you can tag to a
ciphertext?
>>: [inaudible]
>> Brent Waters: So reference the [inaudible] the so-called Pandi paper, so if you want
to, if you have public parameters as size 4 or something can you tag in 20 attributes in
your work?
>>: [inaudible] divisible [inaudible].
>> Brent Waters: Is the same spanning problem, remember we had this kind of weird
hash function and there was a very…
>>: [inaudible]
>> Brent Waters: Yeah. But even the small universal public parameters are exactly
equal to the number of attributes. So it is in your own work that limitation is present.
>>: So it wasn't totally clear to me your solution. So you had the secret sharing
technique and then that also increases the size of the public parameters [inaudible] you
had sub I and the Is was the number of shares of the secret, right?
>> Brent Waters: So that was not the size of the public parameters. Should I go back to
the slide?
>>: Yes, that would be great. My basic question is whether like what was the purpose of
secret sharing? Is that what was giving you the unbounded that you could keep going
level after level and needed to increase the number of shares of the secret [inaudible]
unbounded?
>> Brent Waters: Okay, let's bring up the system. So maybe I will…
>>: What is J?
>> Brent Waters: So J is the level, but notice the public parameters are here…
>>: What makes those…
>> Brent Waters: Those are constant.
>>: [inaudible] not the public [inaudible] those are [inaudible] text sizes.
>> Brent Waters: That does go with the level.
>>: Yes.
>> Brent Waters: Which is the same as previous systems.
>>: So J can go to infinity and [inaudible] sizes too much…
>> Brent Waters: J can go to infinity. So the ciphertext size does grow with the number
of, I mean, so one question is can you do this with a compacts ciphertext, but this kind of
matches with what was done with previous, in the Boneh-Boyen system for example, the
ciphertext size grew with the number of levels. It just, I can pick any, when I am
encrypting I can pick any J I want. The public parameters, there's nothing in the public
parameters that dictate me to be how far I need to go. It is the case that it does grow
linearly with J but there is nothing in the public parameters which specifies like a
maximum J.
>>: So is the role of this, [inaudible] the sum of these things. So that must've come out
somewhere in the proof that you showed us with your calculation [inaudible] cancel
things [inaudible] and not proof the correct [inaudible] encryption or whatever.
>> Brent Waters: You mean this part here?
>>: Yes. I am having trouble understanding the mapping of secret sharing scheme to
the, to what you showed us. I can't quite follow the details of [inaudible]. Are these
supposed to be like independent secrets that are given at each level? If you are the person
that is delegated out on the J levels you are going to get all of these guys?
>> Brent Waters: Well, you will get them in the exponent over here.
>>: Oh, okay.
>> Brent Waters: I mean if I give them to you in that [inaudible] you can break them. So
here is, let me first say that, you had this other question? Yeah, I didn't, so I kind of took
Allison's site and I modified them a little bit. The secret sharing part was kind of done
before in the previous systems more or less or another thing, I mean it is part of it, but it
is kind of more of this structure of the ciphertext which is more of a novelty in this local
cancellation. So I am making a key for you. I am making a key for let's say you are at
depth five. So the authority, what it does is it chooses lambda 1, lambda 2, lambda 3,
lambda 4, all the way to lambda 5s, essentially that they sum to alpha and I just, and I
give you the key of this according to this algorithm.
>>: And you give me alpha?
>> Brent Waters: No I don't give you alpha. That is the master secret key; I shouldn't
give you alpha. And I don't even give you the lambdas; I just gave you…
>>: The thing that is bothering me is just that it seems weird that like normally keys you
think of them as being random, and here you have them related, right? You took like say,
one instance would be like lambda five would be one more than lambda five and in
another instance lambda four was one less than lambda four in the other instance. So add
to the same thing.
>> Brent Waters: Okay. But here is how I do it. I choose lambda one randomly. I
choose lambda two randomly and lambda three and four randomly. And then I set
lambda five to be alpha minus…
>>: [inaudible] doesn't make sense it is related to the other.
>> Brent Waters: Yeah, they are not completely random. But if they were completely
random, anyone could make a private key. They have to tie together somehow. You
want decryption. You want these things to relate. If they don't relate to alpha in any
way, they are completely random group elements then…
>>: You wouldn't be able to decrypt. But I am just thinking about the security issue. It
seems that there is something that seems a little weird. So is it secret sharing in the sense
that when you do the decryption calculation that it looks like it is the secret sharing thing?
Why do they call it secret sharing?
>> Brent Waters: It is like an n out of n secret sharing. In the HIBE you have to match
at level one. And you have to match at level two. And you have to match at level three.
And you have to match at level four and level five. So basically I am taking this secret, I
am basically executing, I am sharing the secret alpha into these exponents and then I am
embedding them. In the ABE system, if I have some policies like, you know, attribute A
or B and C, I will do C. Pretty much the attribute-based encryption system is just really
the same thing except for we share alpha like according to some [inaudible] something
secret sharing system that represents the policy. But I will just remark that this idea that
alpha is embedded, like in all of these previous systems like the Boneh-Boyen one, alpha
is embedded in the key. So at no point do you have private keys which are completely
random. Like if we lifted up the screen again we would see the Boneh-Boyen system has
alpha embedded in it. So I wouldn't say the fact that alpha is embedded somewhere in
here is a strange thing. Yeah, you have to make the security proof go through, but if it
wasn't embedded in there I would be scared because what the heck is alpha doing? You
know, like these things should all be reflected somewhere. I guess Carl, then Leo.
>>: This is a much less technical question. So you have been using these examples
[inaudible] Kristin and doing [inaudible] delegation and so it has been something of a
disappointment with public-key infrastructure. The delegation changes are typically not
very long. And part of the reason for that is that if you go down to the registration
authority to find the things that you would need to do a long depth chain, basically when
you go climbing back into another place the trust relationship would be very weak and so
having a depth of chain greater than 20, it is hard to imagine that anyone anywhere else in
the tree would trust someone at that lower level with all those registrations [inaudible].
So having a very great depth of tree, it is not very likely that that the type of [inaudible].
I just want to understand if I could how to reconcile that with what you are saying about
the need to have attributes. So having 100 attributes is not all that plausible. It is really
doubtful that that will happen. And so could you help me understand a little better this
relationship between the depth of the tree and the size of the features [inaudible]?
>> Brent Waters: I think during the middle of my talk I did say, for reasons that you are
giving here, that the motivation is stronger in ABE.
>>: I understand. [inaudible] so this depth of tree as far as it's like multiple
delegations…
>> Brent Waters: Okay. Actually, can I grab some whiteboard? In some sense this
HIBE, it is almost like an and, sorry Josh I didn't mean to. This is almost like an and
policy. It is like you match at level I and level II and level III. If you forget about the
delegation for a second, it is almost like you have to match that level I and level II and
level III and level IV and level V, just one big… so this ABE, so that is just and policies
so ABE is just sort of, well we have better than and. We have any Boolean formula. So
it is just kind of like how, it's how many different attributes, how many different, so when
you're in the ciphertext you, when you are in the HIBE you can kind of give something
up for each different level and attribute-based encryption you give out something for each
different attribute. The techniques are very similar. I use HIBE because it is a simpler
thing for pedagogical reasons to give in a talk. But once you understand the HIBE thing,
getting the attribute-based encryption is like a very small step.
>>: So is this relating the depth delegation of HIBE to the depth of the policy that you
have?
>> Brent Waters: Yeah, no, yeah, it's a little bit of a, that is a little bit of a false
connection. It turns out I have to give a component, in HIBE I have to give a component,
we're just counting components of the ciphertext. So for each level in HIBE I have to
give out something for each component of the ciphertext, I have to give out something.
And then in attribute-based encryption for each kind of attribute I have, I have to give out
a component of the ciphertext. I can see how you might hold the depth of--yeah I can see
how it leads you a little--Leo?
>>: So I had a question on attribute-based encryption. What Boolean formula support
[inaudible] or [inaudible]?
>> Brent Waters: Which Boolean formulas do we support?
>>: Like a very deep nested [inaudible] Jesse
>> Brent Waters: Any Boolean formula.
>>: And the cost is sort of [inaudible]?
>> Brent Waters: There are two different kinds of ABE. Let's focus on the key policy
one. Basically the, so think of the number of nodes, leaves in the Boolean formula, or the
size of the Boolean formula. There is like a group element or two, whatever, a couple of
group elements in the private key. The size of the private key grows with the size of the
Boolean formula.
>>: In whatever form you write it for is this like [inaudible]?
>> Brent Waters: In whatever form you write it.
>>: Okay.
>> Brent Waters: So if you can find a good representation then it is fine. If you find a
really bad representation, then it is equally bad. And that is pretty much the same in all
of these ABE systems. Anything else?
>> Kristin Lauter: Terrific.
[applause]