 Okay, so our next talk starts, and since it's two minutes late, the talk after Brunt will also start, two minutes late. Okay, let's start. Okay, thanks, Rachel. Hi, I'm Brent Waters. I'm going to be talking about a punctured programming approach to adaptively secure functional encryption. So let me just start by talking very briefly about functional encryption. This is a way of thinking of encryption that moves beyond the all or nothing decryption semantics of traditional public key encryption. In this system, what we want to do is endow this user Alice with a secret key which doesn't let her necessarily see the whole message, but lets her learn a particular function of the message. So we'll have an authority which generates a master's secret key, public parameter pair, keeping the master's secret key to herself. She'll generate then a secret key F for Alice. And Bob, if he encrypts a message M, and eventually this ciphertext gets to Alice, she can learn the function F of M on the message. So this might be something like she learns if an encrypted email was spam or not, but doesn't learn anything more than that, for example. Okay, and then, you know, the progression of works that led to this and around 2008 we first started using the term functional encryption, sort of changed it over from predicate encryption. Okay, so to explain the state of the art in functional encryption, I think it helps to kind of look sort of pre-offication, this whole obfuscation explosion and post. So pre-offication, there were sort of two different flavors. One was this attribute-based encryption, where there'd be this payload we wanted to hide, and we have this metadata which we sort of evaluate the function over, but this metadata itself is tied to the ciphertext but not hidden. So at first we could do things like boolean formulas on it, and then eventually we're able to, especially this neat GVW work, we're able to move to circuits, which was pretty neat. Okay, but that only hides this payload. Then for kind of true functional encryption, we were limited to things like doing a dot product with a ciphertext and both the key were these vectors. We could do a dot product test if it's zero or not, which can build so many things off of that, but it's still a far cry from, let's say, polynomial-sized circuits. Then when obfuscation came along in this GGHRSW paper, what we are also able to show there is that if you combine indistinguishability obfuscation with a special type of simulation, sound nizics, you could get functional encryption, or at least what we call selectively secure functional encryption. This is where an attacker that says, okay, you cannot distinguish, or a attacker says I can distinguish between these two messages. He's forced to declare these two messages before even seeing the public parameters. So it's kind of a useful model for, I mean it's a challenge to get to this point, but ideally we want it to be adaptive. Okay, so for this talk I try to answer these two questions in some sense, can we build a better functional encryption system, one that is a simpler, and hopefully without this extra nizic type primitive around, and the second one is can we make it adaptively secure, that is, can we get a polynomial time reduction from our system to the underlying, with polynomial loss to the underlying indistinguishability obfuscation. Okay, so to present this talk, I have this really two results here. The first one is going to be a simple, collectively secure functional encryption system that comes from IO, indistinguishable obfuscation plus one-way functions. Actually it's a little more secure than that. We actually can do it for this semi-adaptive thing where all private key queries come after the challenge side for text, a little bit better than the selective, but I'll just call it selective. Second, we're going to present the first, actually that came in the literature, adaptively secure FV scheme that comes from indistinguishability obfuscation plus injective one-way functions. And to present this talk what I want to do is first go into the selective construction proof so you can get some idea of these kind of punctured programming machinations used to get around in all this stuff. Second, for the adaptive one, just due to, in some sense, how complex it is and time constraints, I'm more going to give an overview of the main ideas, which I would say the central idea there was we can take a one-bounded scheme that is adaptively secure and kind of connect this with a selectivist techniques to get full adaptive security end-to-end, and this is actually, and then finally, I'll kind of actually just make a couple of remarks we'll share here a good talk from Pranjan on how this bootstrapping technique can be simplified and kind of made better and stuff like that. Okay, so for selectively secure functional encryption, let me first go over the basic definitions and tools we're going to use. Functional encryption scheme again has four algorithms set up in crypt, keygen and decrypt that have roughly the semantics I talked about earlier. Informally correctness says that if we have a ciphertext that encrypts a message M and if I have a secret key for F and I execute decrypt, I will learn F of M, okay? And security, I try to shove it into, you know, let's say half a slide here for this indistinguishability game. Here what we basically have is that the challenger will give the public parameters to the attacker. A attacker can query for secret keys from many different functions, and it submits two, and gets these secret keys, and it submits two messages M0 and M1 with the constraint that for each function, F of M0 must equal F of M1. Otherwise the system could be trivially distinguishable just using the natural power you get from the secret keys. Okay, then the challenger does the usual thing. It flips a random coin B, encrypts the message M sub B. We can ask for more private key queries with the same constraints, and the attacker's job is to guess B prime, and his advantage is that probably he does this over one half. Okay, so in some sense the usual definition. Selective security is where we sort of remove this selection thing up to step zero ahead of seeing the public parameters. So in some sense the security game here, the adaptive one seems like the right one, and we like to be able to get to there, and of course without using sub-exmanential hardness assumptions in this kind of usual trick. Okay, so the first tool, if you guys haven't, I guess we even have the song about it now, is indistinguishability obfuscation. And so the idea is that we can take some original program, run it through some obfuscator compiler and get out a functionally equivalent program, but one that should hide it in a certain way. And the definition for indistinguishability obfuscation, which I guess is the most believable one in a sense, is that if I have two circuits C0 and C1 that are functionally equivalent, they give me the same output on every single input, then you cannot tell whether I gave you an obfuscation as C0 or I gave you an obfuscation as C1. Okay, now to build upon this, we're going to use this punctured programming ish technique introduced by Mitzvah and myself in 2014, where we want to like sort of the methodology, you remove a key element of a program that doesn't change the functionality, but it makes an attacker hard to win with it. The mechanism for this will be, the main tool will be this punctured pseudo-random function, which is really like a pseudo-random function, but I can give you a punctured version of it, I can give you a punctured version at x star, and that basically says that you can evaluate the function everywhere except for x star, and moreover, at the point of x star, you cannot tell the difference between the functions output at x star and just the truly random value. Okay, that's the idea of a punctured pseudo-random function, and this can be built from one-way functions, GGM tree, that type of deal. The second thing I'm going to have is a slightly higher level abstraction, which I can build from puncturable PRFs, I'll call it PDE, and this is a deterministic encryption system, this is going to be a tool I'm using to build other stuff, and it has the usual encryption, decryption semantics, but I can also give you a punctured version of this, and here I puncture on two messages, and what this means, essentially the puncture key means, if I puncture on M0 and M1, that means you can decrypt ciphertext for any other message other than M0 and M1, remember there's only one ciphertext per message because it's deterministic, and moreover, if I show you ciphertext for M0 and M1 for M1, but I don't tell you which is which, I don't tell. Okay, so I puncture this, an encryption from M0 is ambiguous relative to an encryption for M1. Okay, so that's going to be our other tool, which we're going to be using to make this, and we can derive it fairly simply from previous work I'll mention. Okay, so let's actually see the selectively secures system, I'll give it a little bit of detail, as I said. So first of all, the public parameters are going to be this program obfuscated, so they're going to include a puncture period K, and pretty much what this program will do is just take an input R and do it, let's say, length-doubling pseudo-random generator T, and evaluate the pseudo-random function on T to get a small K will actually be a PDE, a puncturable deterministic key K. Actually, let's skip the secret key for a second and go to encryption. So to encrypt the message, I'm just going to choose a random value R and run it into my program, which will give me an output some tag value T and a corresponding K. Okay, so that's how I'm going to encrypt, is just feed it into this program. Now, the secret key for function F, what it will do is if you give it a tag T, it will actually compute that PDE secret key K, like as F of capital K comma T, and then it will decrypt the C that you give it, so this is a PDE ciphertext C, so it sort of decrypted under the system and then evaluate the function on it, and give you that output. Okay, so we have the public parameters, which are just, encryption is pretty much just feeding in a random value into the public parameters. Oh, and then, so I want you to do that. You should use that to encrypt the message M under the PDE system, sorry about that. And the secret key is something that decrypts this PDE, kind of figures out from the tag what this PDE secret key is and applies the function on that. Okay, so not too complicated as far as things, as far as things go. And now I'd like to just kind of give you an overview of like kind of how this security proves in these punctured programming sort of look. So here's the first security, this is sort of the security game instantiated with our concrete scheme. So here we have the public parameters from our scheme, the secret key from our scheme, and there's going to be some challenge ciphertext, which will be generated by choosing R star randomly and saying T star is equal to PRG of R star, this is all done honestly, and then we're going to get this K star, which is this PDE key, and encrypt the message AMSA be under it, okay? And what I want to do is I want to create a sequence of games where I say the attacker cannot tell the difference between these games, but I'm slowly going to make it hard to actually win in this game, okay? So the first step I'm going to do is a simple PRG step, where instead of choosing R star randomly and driving T suit a randomly, I'm just going to choose T star, which let's say be two M bits, I'm going to just choose it randomly. And by PRG security, the attacker's advantage shouldn't be any better in this game than the previous one. The important point, though, is that now T star is, with high probability, T star is outside of the range of the PRG, okay? Whoops. Okay, so step two, what I'm going to do is I'm going to take away the ability to evaluate the PRF on T star from this public parameter program, and this can be done from indistinguishability obfuscation. The main point is that since T star is outside of the range of the PRG, this program will never need to actually use this. So it's okay to cut it out. This is almost like extra fat. And this is like a common technique in puncture programming. Since T star is likely, very likely not in the range of the PRG, taking away this capability doesn't hurt the, doesn't change the public parameters program, but it takes away this kind of knowledge in a sense. Then the second thing, it's a little more complicated step. On this tag T star, which is for the encryption tag, I'm going to sort of hardwire in how you're supposed to decrypt these messages C0 and C1. So here for C0 and C1 correspond to encryptions of either M0 and M1, but no matter what one you see, you don't actually kind of do what you normally do. You just hardwire in the output. And you're able to do this because by the rules of the game, F of M0 is equal to F of M1. Okay, so if T is equal to T star, then you just kind of hardwire the output. Otherwise you can, you know, otherwise if T is equal to T star, not those, you do the decryption of the PDE. And otherwise you just drive some other key. Okay? Okay, and then the step stuff to that, since we kind of punctured all these things out, we're able to derive this K star here, not from the punctual puref. We're able to do it randomly. And then once we have that, we can finally apply the security of the PDE scheme and I can change M sub B to always be an M sub 0 and kind of lose all information about the bit B. Okay? So I know I went through fairly fast, but I hope this at least kind of gives a, you know, some sense of relatively simple hybrid. You know, five steps, that's kind of the whole proof. So it's a fairly simple, selectively secure scheme. We kind of take these capabilities to evaluate outside. We cut it out of the public parameters. We hardwire the key. And once we kind of hardwire in what you're supposed to be doing, we can kind of flip the message. Okay? Okay, so that is the selectively secure scheme, in a sense, in a nutshell. And now we get to the, okay, the main, in some sense, the main result is how do we do it from adaptively secure. And so the good news is I won't try to torch you with another 15 steps of puncture puref hybrids for this one, but instead of what I want to do is kind of give you the high level idea of how we do things. Okay, so at the highest level, what we're going to do is we're going to combine selective-ish for some definition as selective-ish indistinguishably obfuscation techniques, which we saw some of in the previous slides. Along with, it was open whether we could do adaptively secure functional encryption, but if we do this one bounded case, this case where you only give away, let's say there's only one ciphertext and only one private key, this was actually known from previous work, like the GVW scheme. Okay, so we actually have this, but for the case we're not usually aiming for is this one bounded, we want unbounded occlusions, but we can actually make use of this as a tool, and we can kind of bootstrap or combine these to get an adaptively secure functional encryption scheme. And so the way it kind of looks, let me give you kind of one snapshot of how things are going on. So a ciphertext for message M would be a pair of a tag T, and along with an obfuscation, the ciphertext will embed somehow the tag T and the message M, and the secret key for function F will be associated with a different tag Y and will somehow embed the function F, I guess along with Y2 I should say. Okay, and the idea of that is that these are kind of our ciphertext, and what they're going to do, instead of kind of decrypting or evaluating the function directly, they're going to generate one bounded ciphertext. So we're going to take these obfuscated programs instead of doing the job directly, they're going to kind of generate a fresh, in a sense, fresh relative to these tags, and then have the one bounded schemes actually do the work of decryption. So the first step what we'll have here is this key obfuscated program will take in the ciphertext tag T, and what it will do is it will produce a one-time functional encryption key itself relative to a key that's kind of generated from the pair Y, comma, T. So it's sort of pseudo-randomly generates a one-time system key relative to the pair of tags, like Y and T for the function F, and also develops what I'll call a signal, alpha sub Y, T, here. Now for the second step, we're going to feed the tag of the secret key along with the signal that was generated. The signal source says it's okay to go ahead to this obfuscated ciphertext, and this will generate a one-time functional encryption ciphertext for the message M. And importantly, this kind of subscript Y, T means for the same one-time key, like the one-time key is kind of pseudo-randomly generated from this P pair Y, comma, T. Okay, well, now that I have these two things, I have a one-time functional encryption key, a one-time functional encryption ciphertext. I can just run the decryption algorithms of these one-time existing schemes themselves, and I can do this one-time decryption algorithm and get F of M, okay? So this is this kind of bootstrap and going on instead of dealing with it directly, we generate these one-time schemes. Okay, now, you know, I won't have time for the actual proof, but I have a couple of highlights from it. First of all, there's many hybrids actually between each one I'll show you here, but we sort of embed and challenge the message M sub B. And then what we do is, in the ciphertext, in addition to embedding M sub B in there, the challenge message, we also embed always M sub zero, no matter what the bet is, kind of in this unused space at first, kind of doing nothing. And then what we do is we change the signal that I showed from the previous slide in each key. And the signal before said, hey, use your normal message, and now the signal kind of says, no, use this alternative previously unused message to decrypt. So I keep on changing the keys to say to use the different message in the system, and at the end, after I change all these keys, it's actually this first part that's unused, and then we can kind of excise it out so that no information about the bit B is left. Okay? Now, of course, this is very high level and there's many, you know, to actually execute this, it was kind of a bit of a pain. I will remark that it's the step two of changing the signals where kind of most of the action happens, where we, you know, I guess step two caused the most pain in a sense. Okay. So, for the final part of the talk, I just want to conclude by saying, you know, I think, you know, it's one thing, one good thing is, you know, just to get out this adaptively secure and in some sense, the idea that I think will last, you know, of course, everything gets improved upon, you know, over time, is this idea of taking a one-bounded scheme and bootstrapping from it, you know, kind of taking a complicated mechanism and in some sense, yeah, not doing the decryption directly. And something we'll hear obviously more detail in a little bit is this ABSV paper, which we'll hear about next, kind of had a neat different way of looking at it, which the way I kind of saw it, and I'm sure Pribanjan will give you much better insights and all that stuff, is that the first thing they do, they kind of flip the way we do bootstrapping. And this flipping made it a lot simpler, which, you know, kind of kicked myself for a little bit later on. But, you know, in the way I did bootstrapping, there were kind of two heavy primitives, obfuscation on the key side and obfuscation on the ciphertext side. And you can kind of, if you look at it in a different way, you can get only heavy stuff like the ciphertext side program on only on the key side and just a one-time thing on the ciphertext. And then, you know, once you kind of make that flip, then, you know, instead of obfuscation being the heavy thing, you could have, like, they'll show you how to do a selectively secure thing. Now, again, just like the previous steps here, actually, you know, much easier said than done. So we'll get to see a lot of the kind of neat mechanisms and stuff to do it. Again, I'm sure Prabanja and Ziko over there will be able to give you better insights from what I remember. Okay. Thank you very much.