 Hello, I'm Shweta and I'm going to talk about CPABE for circuits and more in the Symmetry Key Setting. This is joint work with Shota Yamada. Let's start by defining the problem. ABE stands for Attribute Based Encryption. This is an ocean introduced by Sahai and Waters and it's a generalization of public key encryption that was introduced to enable fine grained access control on encrypted data. So let's see an example. Let's say that you have an organization, let's say an educational institution and you have various users in this institution as well as different files. What you would like to do is associate with each user a secret key that corresponds to different attributes of the user. So these attributes could be things like the role that they are in the department that they belong to, their affiliation date of joining and such other things. And the files in turn could correspond to access control policies. So for instance, let's say you have this file with an access control policy that says that only a professor in the computer science department at IIT Madras with date of joining satisfying some constraint should be able to decrypt this file. And every file will have similar restrictions or similar access control policies. And as you would expect, you would like that a file should be decryptable if and only if a user's secret key has attributes that satisfy the policy embedded in the file. And for security what you'd like is that even if a set of users pull together their keys or they collude together, they still cannot decrypt any file that they were not individually authorized to decrypt. This property is known as collusion resistance and it's a very important security property for ABE schemes. Now ABEs come into avatars. There's the ciphertext policy variant which is the kind that we've seen so far. Here the ciphertext is the one that contains the access control policy. There's also the key policy variant. So here you switch things around. So now the file contains the attributes and the secret keys of users contain the policies. There are additional desirable properties that you might ask from these constructions. So far in what I showed you, neither the attribute nor the function in the construction are hidden. But you might ask for them to be hidden. So these are called the so-called attribute hiding and function hiding. Here what we know or here what we want is that as I said the attribute should be hidden whether in the ciphertext or in the secret key depending on whether you're in KP or CPABE and analogously for function. So for function hiding. And the prior work in this area can be summarized as follows. So in the key policy setting for restricted circuit classes ranging from point functions to NC1 circuits, there's been a long range of elegant constructions. A big breakthrough in this area was by Gorbunov, Vekuntanathan and we who provided the first construction of key policy ABE for all polynomial size circuits. And there were improvements or adaptations of this work in follow-up work. In the ciphertext policy setting for restricted circuit classes, the story is similar to the key policy setting where we have some nice constructions from pairings or from learning with errors sometimes both for all polynomial size circuits, the story is significantly worse. So we only have one candidate construction by Bredersky and Vekuntanathan. And this is a heuristic. So this is a candidate construction. It does not have a security proof. And the additional properties that I talked about, let's just discuss what was known about them. So we know that for strong attribute hiding, a natural strong notion of attribute hiding, ABE actually becomes equivalent to functional encryption, which in turn implies indistinguishability obfuscation. For weak attribute hiding, we know that or we call weekly attribute hiding ABEs as predicate encryption. And here also we have a construction for all circuits from learning with errors. For function hiding, we know that function hiding functional encryption. So not ABE, but the generalization functional encryption, we know that this implies IO. But function hiding ABE, we don't know anything yet. So presumably constructions are still possible. So now let me tell you about our results. So the main result that we have here is to sort of provide another entry in this table. So in the CPE setting for poly-sized circuits, we provide the first construction. This is from the learning with errors assumption. But it's a full solution is only in the symmetric setting. So we do provide something in the public setting, which I'll talk about, but an optimal solution we provide only in the symmetric setting. So let me tell you about our results in a little more detail. We provide the first symmetric CPE for polynomial sized circuits. These circuits can be of unbounded size. I mean, they have to be polynomial, but this polynomial need not be fixed a priori. The encryptor can choose a circuit of any size. That it likes our construction supports unbounded collusion. So it's fully collusion resistant. And it's based on the learning with errors assumption. We also adapt this to the public key setting, but this is this solution only works for bounded size circuit. So this is why I said that it's not a full solution. There are some aspects of it, which are optimal. So for instance, the size of the ciphertext secret key, the runtime of encrypt key gen and decrypt, these are optimal. But the runtime of the setup algorithm and the size of the public key, these are huge. They depend on the size of the circuits that can be supported by the scheme. And therefore we're stuck with bounded size circuits. In terms of the additional properties that I talked about, we show that function hiding attribute based encryption also implies functional encryption and hence IO. And we weaken the notion of function hiding for ABE and then provide a definition and then provide a construction from the learning with errors assumption. So let me talk a little more about our techniques. A CP ABE consists of the following algorithms. There's a setup key gen encrypt and decrypt. In the symmetric key setting, the setup only outputs a master secret key. There's no separate public key. And this master secret key is input both to the encrypt and the key gen algorithms. The key generator takes as input some attributes X and provides the corresponding secret key. The encryptor takes a message M and some policy or function F and provides the corresponding ciphertext and decrypt works to reveal M if and only if if and only if F of X is equal to one. So now we'd like to construct a CP ABE for circuits and we have a KP ABE for circuit. So here's a folklore approach that goes via universal circuits. Recall that a universal circuit U takes as input a function description as well as an input to that function and emulates the computation of that function on that input. So U of F comma X where F is a function and X is an input to the function is simply F of X. So I'm going to represent input inputs by these boxes, rectangular boxes, and I'm going to represent functions by triangles. And now a very natural folklore transformation given a KP ABE is just that, you know, use the universal circuit to convert the input into into a function. So, you know, just take the universal circuit and hard code X inside it. This is now a circuit. And the function F it can be now converted to a string. So the function representation can just now be a string which is meant to be an input to the circuit use of X. Given this, it's completely trivial how to use KP ABE. The CP ABE encryption will just run the KP ABE encryption, but now the circuit F is represented as a string. So you can just run KP ABE encryption and the CP ABE key generation as you would expect just runs KP ABE key generation for this function use of X. Decryption is just decryption and everything works just as you want. But this is not a satisfying solution. So in particular, the size of the public key, the cipher text and the running time of setup key generation encryption and decryption, they are now all going to grow with the maximum function size F max. Okay, so in particular, you cannot support unbounded size circuits. So how do we get around this? Well, the first trick that we use is that of redistributing computation. A similar trick was used in AMY 19. And here is the idea. Now we'd like to support unbounded size circuits. But in and in this setting, only the encrypt algorithm knows what is the size of the circuit because it gets it as input. So encrypt can depend on the size of the circuit and so can decrypt, but setup and key generation cannot. Okay, so the problem with what we saw before is that if if I want to run the KP ABE key generation for a function use of X, this forces key generation to depend on F max. And why is this because the circuit use of X takes as input a string of size at most F max. So clearly the there's a size dependence there. And this is what is leading to the problem. So the idea that we use here is that we don't ask the CP ABE key generation to compute this KP ABE key. But rather we'd like to distribute the computation between the CP ABE encrypt and key gen so that each respects the efficiency requirement of CP ABE. So here's what I mean by this. So currently in what we've seen so far, you have this key generation just simply running the KP ABE key generation and computing the key for use of X. This is, you know, bad for us. Like I said, now what I'd like to do is the following. So the key generation has the input X, but it doesn't have the time. You know, it doesn't have time depending on F max in which to run. On the other hand, the encryption algorithm, it has time. So it knows the length of F and it is allowed to run in that much time. But it does not know the input X. So the question is whether these two can somehow do something, you know, they don't talk to each other, but they do have some shared state in the form of the master secret key. So can they somehow collaboratively produce this KP ABE secret key? One given the input, but not the time and one given the time, but not the input. And the answer is that, yes, you can. You can use functional encryption. I'll talk about how. And this was a trick that was already used in AM by 19, like I said. So here's the definition of a key policy functional encryption scheme. This is just like key policy attribute based encryption, but here we insist that the attribute be hidden. So in particular, the encryptor is now going to compute a ciphertext for some message M. And given the ciphertext and a secret key corresponding to some function F, decryption should output F of M and nothing else. So in particular, no information about M outside F of M should be revealed by this construction. Also note that what we're looking at now is a public key scheme. So the encryptor only gets the public key does not get the master secret key. And what we know here is that as long as the adversary only requests for a single key. So if for, you know, collusion, there's no collusion resistance. So the adversary can only get a single key. In that case, we know how to construct this key policy FE for all circuits based on LW. So now let's see how to use this to redistribute computation. So the CPABE key generation now it takes its input X, it does not convert it to the circuit use of X. It does because it does not have enough time. It simply encrypts it using functional encryption. And the CPABE encrypt, which does have time, it does some computation, you know, that depends on the size of use of X. And it produces a function functional encryption key for some circuit C. I'll tell you what it is in a second. And together these two, when they're put, when they're put together the FE decryption algorithm output C of X, and I would like the C of X to be the KPAB secret key for use of X that I wanted, right? So that's, that's how I define my circuit C. So here the key observation is that the circuit C is, it's the KPABE key generation circuit for some use of X. So this circuit C clearly depends on use of X, which in turn depends on Fmax. However, the neat thing here is that the output of this circuit, so C of X evaluated, you know, on, on some X, this output, the KPABE key is actually short in the construction by Bonnet at all. So we're really crucially relying on the fact that even though the circuit size is actually large, the output size of the circuit is quite short. It can be bounded by some fixed polynomial. And this is a very nice property that, that is achieved by the construction of BGG plus. So it's not, it's not that you can use any old ABE scheme or FE scheme here. They really have to be chosen carefully so that the efficiency requirements are met. And now if you have the KPABE secret key, well, the, you know, the earlier idea from the folklore construction of providing the KPABE ciphertext for FMIM, well, it can still do that. And ABE description can still work to give you exactly the functionality that you want. So here, as I mentioned briefly before, the components have to be chosen carefully so that the efficiency requirements are met. So in particular, the functional encryption scheme must, must be chosen carefully. You want that the functional encryption ciphertext should not grow with the size of the circuit C. And in order to achieve this, we can use the one key succinct functional encryption by Goldwasser at all, which is based on LWE. This ensures that the FE ciphertext only depends on the depth input and output of the circuit and not the size of the circuit. So the size of the circuit is bad for us, but we don't incur a loss based on the size. So since we only, since our FE ciphertext only depends on the depth input and output, it turns out that, you know, we can satisfy the efficiency requirement of the CPABE key generation algorithm. So we get in particular that the key generation only depends on the size of X and the encryption only depends on the size of F. And the KPABE secret key, as I already showed you, is just generated on the fly. However, the drawback of this approach is that it restricts the scheme to be symmetric. And this is because you have the CPABE encryption algorithm running the FE key generation algorithm, which is obviously a privileged procedure. So it needs the FE MSK. All right. So we made a little bit of progress, but observe that so far we're still only restricted to bounded size circuits. And this is because if our underlying KPABE must encrypt the string F, then the KPABE setup must then be initialized with a bound on F. So some F max and this then only supports bounded size circuits. So here there's one natural way out. Well, the CPABE encryption, which gets the circuit F as input, clearly it knows the size of F and it's a symmetric key algorithm at this point. So may as well let it run the KPABE setup as well. Okay. So now this was our picture from before. And now we're saying that the KPABE setup should also be run by encrypt. So that's fine. But we have to be more careful. So one thing to observe is that this use of X, as I already said, depends on the size of F. Therefore, the circuit C depends on the size of F. And even though the C is a fixed description in the sense that it's always the KPABE key generation algorithm circuit, it varies depending on the size of the input. So the input in this case is F. And every time that the CPABE encryptor gets some function F, if the size of these functions vary, then this fe.keygen has to actually generate fresh keys each time because the circuit is going to change as the size, the circuit C is going to change as the circuit F has varying size. So now this becomes a problem because in what we just said, it implies that for different CPABE encryptions, I'm going to have different fe secret keys. And this is a problem because the underlying fe is only secure against an adversary who does not do collusion. So the adversary only gets a single key. But we can solve this by using the following by now standard trick. Well, you pad the circuit size to a power of two and run lambda instances of single key fe. The CPABE key generator does not know the size of F, but it knows all the lambda fe keys. So it's just going to run the fe encryption for all of them. So it knows the public keys of these fe schemes, it's just going to run the encryption for all of them. And it turns out that that will just work. For attribute and function hiding, so for weak attribute hiding, there's a very nice compiler from lockable obfuscation, which can be constructed from LWE and this transforms any ABE to a predicate encryption system that satisfies weak attribute hiding. For function hiding, what we show is that even in the symmetric key setting and even only for attribute-based encryption, function hiding in fact implies a secret key functional encryption for circuits, which in turn implies indistinguishability obfuscation. So what we do is that we weaken the definition of function hiding and then we provide a construction supporting all circuits. I don't have time to go into the details of these constructions. I refer you to the paper for that. So I'd like to conclude with some open problems. The main most pressing open problem is to generalize this construction to the public key setting for unbounded circuits. And as I already mentioned, the hurdle here is that we want to compute the fe key by using within the encryption algorithm. And this fe key needs the master secret key, but the encryption should be a public key algorithm. So there's a tension there. So this is the main hurdle and resolving it in any way would be really fantastic. So CPAB for circuits from LWE, well from anything actually, CPAB for circuits is not known. And this is a you know, fairly significant open problem CPAB for NC1 is known from pairing based assumptions and getting even that from LWE would aid us considerably in our understanding of these constructions. So that's that's all I had to say. Thank you for your attention.