 And I'll talk of the Waters session, functional encryption for regular languages by Brent Waters. Thanks, Juan. OK, so I'm Brent Waters, and I'm going to be talking about functional encryption for regular languages. And to start, in this session, we have been talking about functional encryption. And this is a new way of thinking how we share data. In the past, it was usually that, let's say, Bob wanted to send a particular message to a particular user, Alice, and no one else should see it. And now we have a situation where, let's say, Bob will have some data x that he will embed in the ciphertext somehow. Alice's, in general, will have a private key associated with some value y. And for functionality f, she should only learn f of x, y. So let's see here if we're to animate this. The authority will give Alice the secret key for y. Bob will somehow encrypt using the public parameters in x. And now later on, if Alice is able to get a hold of this secret key, she's able to learn f of x, y. I won't get into deeply into the security definitions here, but intuitively, we want the property that she should only learn the function f of x, y. OK, so let me start by talking about a common, or perhaps popular form of functional encryption called key policy AB, or attribute-based encryption. Here, a key is going to be associated with a Boolean formula, or it could actually be a circuit for the purposes of this talk. And the ciphertext will be a pair of a hidden message and a set of assignments to variables, let's say to n variables 0, 1, through n. And the functionality that we want is if this assignment satisfies the Boolean formula, you can decrypt and you will be able to see the message. And if not, you won't learn anything about the message itself. Here, we're actually going to be working on what we call the public index model, which just means that we're only trying to hide the message. We're not going to hide this assignment of variables itself, so I'm kind of just think of these as being out in the clear. So what I want to do for this talk is to actually focus in on one particular limitation for this type of functional encryption. In particular, here, the key is going to be a single, not a family, a single formula or circuit. And by definition, essentially, this means that it will only operate over a fixed size input. This formula is only going to look at so many variables and just won't consider anything else. OK, so in real life, there's many interesting forms of data that are fixed size, let's say, filling out a form. Perhaps if we want to get kind of imaginative of what we could do with the circuit, we could do some kind of cool image processing for a fixed size image. But there's also interesting forms of data which aren't, like, a priori bounded, let's say, like an arbitrary text, some type of arbitrary text, or perhaps some video that was captured. So what I want to do in this talk or this work is to initiate the study of functional encryption for arbitrary length inputs. That's the goal. And a natural starting point for doing this is to study this for regular languages. Really, two main features here. First of all, regular languages, I think, are good to study since they've been well-defined, have been well-defined for a while, and actually are also used in many different computing applications. So a language, roughly, well, is regular if and only if it's the strings that are accepted in it can be determined by some deterministic finite automata or DFA. And there's also many different applications like we'd have a search application where we try to match all HTML matching tags by a regular expression. I don't write these things too often. Or a firewall rule that we might want to match based on a regular expression for whether we apply some firewall rule. OK, so in this talk, I'm going to basically express regular languages through DFA's. So let's take a look at DFA's. I imagine that almost everyone in this audience has come across these at some early point in their computer science education. So I'll try to make this pretty brief. So DFA will be a machine capital M. It will consist of q, a set of states, an alphabet sigma, a start state q naught, and a set of a sub-states f. Finally, there's also going to be a transition function, which will say, OK, if I'm in this state and the next symbol on the string is some sigma, then it tells me what the next state to go to is. So just to maybe make it a little more concrete, let me just throw up a simple example really quickly. Here I try to accept some kind of simple language, like I'll accept all strings, which begin any string that begins with a 1 and has an even parity. So here my start state will be a. And if I get a 1, I can go over to b. And more ones will toggle back and forth between a and b, whereas 0 will stay either respectively in a or b. And finally, if I end up in the bold outline, I'm sure everyone's seen this in some Sipser textbook. If you end up in c, then you will accept. So here, for example, the string w1010 will be accepted by this DFA. So to kind of initiate the study, I'm going to do what I call a DFA-based functional encryption system. And here the key would be associated with the description of a DFA. A Cypher text will be associated with a hidden message m that we're going to try to hide, and an arbitrary length string w. And the semantics that we're going to want are going to be pretty analogous to the KPAB. That is, if the machine associated with your DFA accepts w, then you should get to learn this message small m. If not, you shouldn't be able to learn what the message is. So basically, this is that written down. Again, we're going to be in the public index model where, kind of like a lot of forms of IB, we're going to just assume that w is given away in the clear. So this system, given the somewhat short amount of time we have here, I won't be able to give everyone a complete picture of how it works, since it has, you could say, many different moving parts. However, I'm going to try to call out what I think are a few interesting features to look at. I hopefully give some intuition of what's going on. In particular, I want to give people an idea of how the DFA is embedded in the key, how the string is embedded in the Cypher text, and a sense of how decryption follows evaluation of the DFA on the string. So the setting that we're going to work in is a bilinear group G of prime-ordered p. There's going to be q state. So if a key has size of q states, we're going to pick q random group elements, d sub 0 through d sub q minus 1. A Cypher text will be an L symbol string for some value L, which will change with the Cypher text. And here, when I'm encrypting, I'm going to pick random exponents S0 through S sub L. Now, the interesting part for decryption is decryption is going to be like an iterative process that follows the execution of the DFA. And if someone over here, let's say, was decrypting, and I grabbed them in the middle of their process and looked at what they were doing, what I would find is that they would have computed some intermediate value, e, that's the bilinear map function, of G comma d sub x raised to the S sub j. And that means that when they're decrypting, they're able to get this if they're in state x after j symbols. So when you're doing this iterative decryption, this is being able to get this represents that there's computation on the DFA. And to actually realize this, to build the whole system, I like to organize it into three different mechanisms. The first mechanism is what I call initialization, which says that, OK, you can get e of d sub 0, where d 0 is associated with the start state, to the S0. Before I see any symbols, I'm in the start state. That makes sense. The next one says the transition says that if I have this accumulative value, let's say e of G comma d x to the Sj, and there's a transition on state x, and if, let's say, the transition function on state x this should be j plus 1, actually, is equal to y, then I'm able to get this next intermediate value. So that's the transition function. Finally, there's going to be a completion mechanism, which says that, OK, if I end up in d x, and if I end up in a sub state at the end raised to SL, I can take this all the way and actually get the message. So these are really the three parts that I need in getting the system to go together. For this talk, I'm just going to focus us in on the parts needed to build this transition mechanism. And hopefully, I think that's kind of the most interesting part of or maybe the most novel part of what's going on here. OK, so let's take a look at at least some pieces of the system. There's going to be four algorithms set up in crypt key gen and decrypt. The set up algorithm will take as input an alphabet sigma. And here, we'll choose a bilinear group G of prime order P. Then we'll also choose a random exponent alpha, some other random group elements. Let's not worry too much about them. But notice there's a group element per each symbol in the alphabet. And then we'll give most of these away for the public parameters. But the difference is we'll only give way E of GG to the alpha for the public parameters. And we'll withhold G to the alpha for the secret key. OK, so let's take a look at how part of encryption works. The input is going to be a message small m along with an L symbol string W. I'm going to choose these random exponents S0 through S of L. And now the part I want to show here is that for i's equal to 1 to L, we give away G to the Si and also H sub w i associated with the i symbol to the Si and Z to the i minus 1. And sorry, Z to the S sub i minus 1. So the point here is that I am somehow embedding the string W in the ciphertext itself. That's the point I want to do here. So I'm getting all these symbols in here. And this linking is going to preserve the order. I don't want some attacker to be able to essentially switch the order, permute the order of the string in any way. Note, I'm only showing components for the transition mechanism. So if you're wondering, oh, where's the message play in, this is why. I'm just showing you a particular piece of it. For key generation, it's going to take as input a message m, the alphabet set for the whole system. Sorry, it's going to take a DFA, capital M, the alphabet set for the whole system. And we're going to say x, y, and sigma is in the set t if there's a transition from x to y on symbol sigma. Again, for each state in the system, we're going to choose a random group element and also choose a random exponent for each transition. Now, the part I want to get across here is that there is, again, we are embedding somehow this transition from x to y on symbol sigma in the keys. Like we have this d sub x inverse and this d sub y and h sigma to the r sub t. So of course, there's not enough time to make complete sense of this, but I just want to give people a sense that we are embedding this DFA in there somehow. OK, so let's see how this transition mechanism actually comes together, which is going to be part of decryption. OK, so let's suppose that the ith symbol is equal to sigma. And I'm going to want to go from some representation of being on, let's say, state x after i minus 1 symbols to state y after i symbols. Well, I can grab some pieces from the keys in the cipher text. And if I plug things in, the second line is I get what looks maybe like perhaps a somewhat complicated formula. But one feature I'll point out here is that for this a bunch of things cancel out and we get something simpler, a key feature here is that this w sub i here has to match h sub sigma or else things won't cancel out in the right way. So what I get is if you actually follow the math, which you can probably do offline a little bit more, you can see that this value I end up with is exactly what allows me to transition from here to here. I just multiply this by this. These things cancel out. And now I've taken the next iteration in decryption. I've actually taken this step forward. So really, most of the decryption is just repeating this transition. You have to get started. OK, I won't show that. But once you get there, you just repeat this mechanism over and over again. And you get hopefully to the end where you're hopefully in a step state. And then you do this final completion mechanism that finishes things off. So really, the system up here is falling the execution of the DFA. OK, so I'd like to, of course, summarize up here. Of course, to get more details, we'll have to look a little closer at the paper offline. But the main point here that I want to summarize is that the goal for this work was to start looking at functional encryption for arbitrary length inputs. I think we took the first step by looking at it for regular languages or DFA's. I'd like to leave this talk with putting out three problems, which I think are pretty challenging. And I'd be pleasantly surprised to see a solution to them in the near future. But I think they're good to really put down and identify. The first one is, can we support, instead of DFA's, can we support NFA's inherently? Well, NFA's and DFA's decide the same set of languages. But there can be regular expressions and NFA's that have compact representations. But if you try to give them as a DFA, it's going to combinatorially explode. So it'd be good to be able to do this, let's say, natively as an NFA. I think this is kind of similar analogous to the problem of being able to do formulas in AB and not do circuits. So I think this might be a little bit tricky. The next very natural thing to do is, can we climb the Chomsky hierarchy? Right now, we can do this for regular languages. Why not context-free? Why not context-free? I kind of know why not. But we like to push it forward. We like to be able to do more and more. Or another way of looking at it is I can bed things for a DFA. Obviously, I like to do it for a Turing machine instead. I mean, that would be obviously more powerful. Again, I think this would be pretty challenging. Finally, just one kind of last note. I talked about working in the public index model. And this is an open problem for this arbitrary length or the fixed length, like the circuit or the formulas also. We like to be able to, right now, I'm just saying, OK, we're going to have to give out W in the clear. It would be even better if we could somehow do some oblivious evaluation and also hide it. Again, I think that's probably a pretty challenging problem. OK, thank you very much.