 Welcome to my talk on succinct and adaptively secure attribute-based encryption for policies represented by arithmetic branching programs and based on K-linear assumption. This is joint work with Rachel. Since the talk is about attribute-based encryption, let's first define it. In ABE, there's an authority setting up the system, generating the master public secret key pair. With the master public key, everyone can encrypt a secret message mule with a public attribute x. The authority also issues secret keys to users tied to policies specific for each user. Each policy is represented by a function f. If the policy authorizes the attribute, meaning that f of x is known zero, then the user can use the key to decrypt the ciphertext and recover the message. This is equivalent to computing mule times f of x. In this case, we say the key is authorized. Security of ABE says if a key is unauthorized, meaning that f of x equals to zero, then the message mule should be hidden. And the scheme should be collusion resistant. The message should remain hidden, even if an adversary gets arbitrarily many keys, as long as each of them is unauthorized. Formally, we consider IND CPA security, captured by experiments between a challenger and an adversary. To begin, the challenger sends the master public key to the adversary. Next, the adversary can ask for secret keys of his choice. The challenger will generate them for it, and this can repeat as many times as the adversary wants. Then the adversary chooses an attribute x and two messages. The challenger encrypts one of the messages with the attribute x and sends the ciphertext to the adversary. Afterwards, the adversary can continue to query secret keys. Of course, the adversary cannot ask for authorized keys, and IND CPA requires that the two experiments be indistinguishable. There is also a weaker notion called selective security, in which the adversary must commit to the attribute x at the very beginning, before it even sees the master public key. In this work, we consider the stronger adaptive security. Aside from adaptive security, we focus on the efficiency of AB. In particular, we want the ciphertext size to be as small as possible. It turns out that most existing AB schemes achieve ciphertext size linear in the attribute length and the message length. In fact, by using AB as a key encapsulation mechanism, the dependency on the message length can be made additive, which is as good as we can get, because the ciphertext will encode and hide the message. However, x, the attribute, is public and not hidden, and it's actually possible to make the ciphertext size independent of the attribute length. Such AB schemes are said to be succinct. Note that this will not break correctness, because the decryption algorithm will always get x, which is stored and transferred in the clear. Achieving succinctness is interesting for both theory and practice, so that we can use potentially very long attributes without incurring overhead in disk space or network bandwidth. In this work, we obtain succinct AB that supports expressive policies, enjoy adaptive security, and is based on standard assumption. Our scheme is based on the matrix decisional Diffie-Hellman assumption in parent groups, which is implied by the K-linear assumption. It supports policies represented by arithmetic branching programs, and the ciphertext size is 2k plus 2 number of source group elements and one target group element. The scheme is concretely efficient. If we instantiate our scheme based on SxDH, which basically says k to be 1, then the ciphertext is just four source group elements plus one target group element. The plaintext space in our scheme is the target group, and it easily extends to handle arbitrary messages by the chemtric. In addition, we also consider ciphertext policy AB, where attributes are tied to the keys and the policies to the ciphertexts. Our CP AB has succinct keys, consisting of 3k plus 4 source group elements, when based on MDDHK. Let's compare our KP AB with some previous succinct AB schemes. This is definitely not an exhaustive list. The works by Attrapadon and John et al. construct succinct AB for monotone spam programs. But the schemes either rely on non-standard assumptions, such as Q-type assumption, or are only selectively secure. The recent work of Tomita et al. constructed succinct and adaptive AB for NC1 policies based on MDDHK. Our work constructs succinct and adaptive AB for ABP. Aside from subsuming NC1, our scheme is the first succinct AB natively supporting arithmetic computation, whereas both MSP and NC1 are Boolean. How do we construct our AB scheme? Our starting point is the framework of our previous work appearing in Eurocrit. It uses a computational tool, function-hiding inner-product functional encryption, or IPFE for short. It also needs an information theoretic tool called arithmetic key garbling scheme, or AKGS, which is a special randomizing coding. By combining the two ingredients, we obtain a one key, one ciphertext, secret key AB, or one AB for short. With some additional effort, it can be upgraded to full-fledged AB. This framework is used to obtain compact and adaptive AB, where the ciphertext size grows with the attribute length. However, it cannot be used as is to obtain succinct AB. Because of the function-hiding property of IPFE, its keys and ciphertext cannot be succinct, which is inherited by the AB. We'll see why later in the talk. To overcome this issue, we replace the function-hiding IPFE by a public-key IPFE, which is not function-hiding. Instead, it satisfies a new security property we propose in this work, called gradual simulation security. It's possible to have succinct keys in such a scheme, which eventually translates to succinct AB. As a consequence of replacing the IPFE, our one AB also changes. What we obtain from the new two ingredients will be a ciphertext policy, one AB, which is a public-key scheme. By using the well-known techniques of dual-system encryption or hash-proof systems, we will simultaneously switch the rows of keys and ciphertext and upgrade one AB to full AB. So we'll obtain KPAB from CP1AB. To see this more clearly, let's first review the ideas from the previous work. In one AB of the previous work, the message and the policy are associated with the key and the attribute with the ciphertext. When they're put together, we'll obtain a randomized encoding of mu times f of x, which is our AKGS. The encoding can then be used to recover this value. The encoding should be secure. It should hide mu if f of x is zero. Since in AB, we do not protect f or x, the encoding does not need to hide them. This is known as a partially hiding randomized encoding. The encoding should also be simple. It is linear in x so that we can compute it using IPFE. Now let's take a closer look at the tools of AKGS and IPFE, starting with AKGS. In AKGS, there's a garbler and an evaluator. They both know some arithmetic function f and some public input x. The garbler first garbles the function f with the secret message mu, obtaining label functions l1 through lm. In traditional Boolean garbling, these functions correspond to pairs of labels, and the function is simply selecting one of the two possible labels, depending on some particular bit in x. In the arithmetic setting, these functions are linear functions of x. Here, the number m of label functions depends on the complexity of f. The next step is to encode input x with the label functions to obtain the labels small l1 through small lm. With the knowledge of function f, public input x, and the labels, the evaluator can evaluate the garbling and recover mu times f of x. We also require the evaluation procedure to be linear in the labels. This is possible as we only require the scheme to be partially hiding. The c is captured by a simulation procedure that simulates the labels, given the function f, the public input x, and the value of mu times f of x. Again, f and x are not hidden and are used by both the evaluator and the simulator. Now that we have a randomized encoding, we need to securely compute it using IPFE. In IPFE, we can generate keys and ciphertext tied to vectors, and the decryption will yield their inner product. The basic security requirement is IND-CPA, which hides ciphertext vectors u beyond the inner products and does not protect the key vectors v at all. This notion applies to both public key and secret key IPFE, and is possible to have succinct keys. We can also consider a stronger security notion, function hiding, where only the inner products are reviewed and both key and ciphertext vectors are protected. This notion only applies to secret key IPFE, and neither key nor ciphertext can be succinct. And this is the security notion used in our previous work. In the talk, I'll often use the block vector notation, so isk of v1, v2, v3 is an IPFE secret key for vector v1, concatenated with v2, concatenated with v3. And similar for ICT of u1, u2, u3. Upon decryption, we obtain the inner product between the concatenated vectors, so u1, v1, plus u2, v2, plus u3, v3. One last thing I want to mention about IPFE is that we'll use IPFE based on groups. And decryption will give us the inner product in the exponent, denoted in the double brackets. With the tools of AKGS and IPFE, let's come back to the framework of our previous work. Recall that when the key and the ciphertext are put together, we'll first compute a randomizing coding of mu times f of x. This randomizing coding will be AKGS labels. AKGS labels are the evaluation of label functions, which are linear in the public input x. So they can be written as the inner products between the coefficients of the label functions and the public input x. We use IPFE to compute them. To generate a key for f, I can garble f and generate IPFE keys for the label functions. Those IPFE keys will be my ABE key. To generate a ciphertext for x, I simply generate the IPFE ciphertext for x. When they're put together, IPFE decryption will give me the labels in the exponent. Although the labels can't be extracted in the clear, thanks to the linearity of AKGS evaluation, I can perform the evaluation and recover mu times f of x in the exponent. Intuitively, this should be secure. First, by IPFE security, only the labels are reviewed. Then by AKGS security, only mu times f of x is reviewed. When f of x is zero, mu should be hidden. However, the proof in our previous work uses function hiding property. In particular, the label functions in the keys must be hidden. Otherwise, there seems to be no way to apply AKGS security. However, using function hiding means the scheme cannot be succinct, and the ciphertext size will grow with the length of x. Okay, so we want to avoid function hiding. Our first idea is to use an IPFE without function hiding. Since we don't require function hiding, we can also just use a public key IPFE. Again, in order for the security to hold, the label functions must still be hidden, so we'll put them in IPFE ciphertexts and put x in IPFE key because it's public and not hidden. Now we have swapped the roles of key and ciphertext, different from our previous work. Actually, everything just feels more harmonious now. The message is associated with the ciphertext, and since the IPFE is public key, the 1AB scheme is also public key, and naturally, it's a ciphertext policy 1AB. I want to emphasize that we're still only considering one key security, so it's still 1AB. Now, if the underlying IPFE has succinct keys, our CP1AB automatically inherits the succinctness. Eventually, this will translate to succinct ciphertext in full-fledged key policy, and we do know public key IPFE with succinct keys from the work of Agrawal et al. What about security? It turns out that selective security is a piece of cake. Here, selective security means the adversary queries x then f, so its first key then ciphertext. However, adaptive security, or f and x, is very tricky, even more so than our previous work. Let's first do the easy one. In the honest algorithm, we have isk of x, then ict of the label functions. Here, I added an extra slot for the proof, and the honest algorithm will put a 1 in the key. The inner products are the labels. Recall that the label functions are created using mu, and we want to show mu is hidden. To do so, we first remove the label functions and hardware all the labels. When generating the ciphertext, instead of encrypting the label functions, I'll encrypt the labels in the extra slot. I know both x and the label functions, so I can evaluate the label functions to obtain the labels. Note that the inner products are still these labels, thus unchanged. So we can simply rely on the IND-CPA security of iKFE. Now we only use labels as opposed to label functions. The next step is to play our AKGS card and simulate the labels. Since the adversary cannot query authorized keys, we know f of x is zero, and this hybrid does not contain information about mu and mu is hidden. This is all good. What about the other case, f of x? Well, the proof breaks down in the very first step. When generating the ciphertext, we don't know x yet, so we cannot compute the labels, and consequently cannot hardware them into the ciphertext. An obvious, yet naive attempt is to hardware the labels in the key instead. We can further enlarge the vector dimension, and in the hybrid, we put ones in different positions in the ciphertext and all the labels in the key. But this doesn't quite work for two reasons. First, we're hardwareing too much information into the key. Second, we're resorting to function hiding to hide the fact that the labels are hardwareed in the key. Either of them will lead to non-succinct keys and defeat our purpose. Fortunately, they can be solved. Let's start from the problem of hardwareing too many values. In our previous work, we have formulated a strong security notion for AKGS called piecewise security. This allows us to hardware fewer values, and it has two requirements. First, each label except for the first one must be marginally random, even given all subsequent label functions. By label functions, we mean their coefficients. Second, the first label, L1, can be solved from the correctness equation, which is a linear constraint over the labels. More precisely, there's an efficient reverse computation procedure that can find the value of L1, even f, x, mu times f of x, and the other labels. We'll call this procedure RC later in the talk. The two priorities together are what we call piecewise security, and we do know a piecewise secure AKGS for arithmetic branching programs due to E-SHI and WE. Let's take a look at how piecewise security is helpful in the proof. In fact, it implies a special simulation structure. Consider the distribution of labels. The first label can be solved using the reverse computation procedure. Once we're not using the first label function, we can use marginal randomness to simulate the second label as random. Marginal randomness can then be repeatedly applied until all the labels except the first are simulated as random. In the simulation, we're sampling L2 to LM as random, then solve L1 from f, x, mu times f of x, and the other labels we just sampled ourselves. We can translate label simulation into one AB simulation, and we need two additional dimensions. In the simulation, we'll put all the labels except the first in IPFE ciphertexts, and the first label in the key. All by the first labels are random. They do not depend on x, so can be sampled before x is chosen. The first label is reversely computed, and will make evaluation appear correct. In order to prove real and simulation are indistinguishable, we do hybrids. In the first hybrid, we hardware L1 into IPFE key, relying on IPFE security. Once hardwareed, L1 is switched from honestly evaluated to reversely computed. Then, we'll switch the label functions to random labels one by one. Suppose we have switched the second to the j minus first label functions into random labels, as shown in hybrid j. Our task is to move to hybrid j plus one, where the jth label function is switched to a random label. For this, we temporarily hardware the honestly evaluated label Lj into IPFE key, relying on IPFE security. Then, we can invoke marginal randomness to replace Lj by random. Now that Lj is independent of x, it can be moved back to the ciphertext, again relying on IPFE security. This completes the transition. As we can see, using piecewise security, we only need to hardware two values in the key, which is quite affordable. However, we're still using function hiding to hardware the labels L1 and Lj in the key, which is a deal breaker. Now comes our next idea. We'll use simulation security to replace function hiding. Let's define adaptive simulation security. Given a simulator, consider two experiments. One is real, the other is simulation. At the beginning, IPFE master public key is given to the adversary, either real or simulated. We'll use to this to represent simulation. Next, the adversary can query IPFE keys of vectors of his choice. The keys can be real or they can be simulated. In this stage, the simulator only gets the key vectors as input. Then, the adversary can query an IPFE ciphertext for one vector u of his choice. It's either real or simulated. If it's simulated, the simulator does not get the vector u. Instead, it gets the inner products of u and all vectors in previously queried keys, because the ciphertext will be decrypted to those values by those keys. Afterwards, the adversary can query keys again. If the key is simulated, the simulator gets the inner product between u and the key vector in addition to key vector itself. This is because the key needs to decrypt the simulated ciphertext to the correct inner product. Simulation security requires the two words be indistinguishable. Note that in the post-challenge stage, the simulator will necessarily hardware the inner products in the keys. The definition is all good, but can we achieve simulation security? The answer is yes. And in fact, the scheme by Agrawal et al is indeed adaptively simulation secure. The definition also naturally generalizes to any constant number of simulated ciphertexts. In adaptive security, the input to the simulator will be quite different depending on the progress of the experiment. Instead of digging into the complicated definition, it's simpler to use this rule of thumb that the simulator uses an inner product only when this inner product can be decrypted. So much for simulation security. Let's come back to the proof and fix it. Recall that the previous proof uses function hiding to hardware L1 into the key. With simulation security, we'll instead simulate the first IPFE ciphertext. When simulating this ciphertext, we do not need to supply anything to the simulator because there are no keys to decrypt it. Only when simulating the key later do we need to supply the desired inner product to the simulator. This inner product is simply the first label. And remember that at this point, x is known. Now, let's look at the hybrids for switching one label function to random label. Again, we need to switch the jf label function. In order to do this, we temporarily simulate one more ciphertext, namely the jf1. When the jf ciphertext is simulated, nothing is supplied to the simulator. And when we simulate the key, we need to supply both the first label and the jf label because that key will decrypt those two simulated ciphertexts. This achieves the effect of removing the jf label function and harboring the jf label. So the same trick of AKGS marginal randomness applies. After LJ becomes random, we just undo the simulation for ICTJ. Cool. We're using at most two simulated ciphertexts during the proof. And it seems that we can materialize our idea with a simulation secure IPFE supporting two simulated ciphertexts. However, there's a subtle issue. The issue is on simulating one more ciphertext in the presence of other simulated ciphertexts. The usual definition of simulation security only stipulates indistinguishability between real and simulation. Even if the simulator supports more than one ciphertext, the definition only allows us to switch on or off simulation in one shot. However, what we really need in the proof consists of two parts. Real and simulating one indistinguishable and simulating one and simulating two indistinguishable. It's precisely the second part that is missing from the usual definition. Enter gradual simulation security, our strengthened version of simulation security. The notion is parametrized by a bound T, the maximum number of simulated ciphertexts. Still, we have two words. In both words, the adversary is given the master public key, simulated. The adversary can query simulated keys and ciphertexts. Then the adversary chooses the vector U, it will receive either an encryption of U or a simulated ciphertext for U. Afterwards, the adversary can continue to query simulated keys and ciphertexts. We require that the two words be indistinguishable, and this precisely captures the idea that we can simulate one more or fewer ciphertexts, even in the presence of other simulated ciphertexts. The only constraint is that we cannot exceed the capacity of the simulator, so the number of simulated ciphertexts should be at most T in the right world. Certain details of this definition are quite non-trivial. Let me demonstrate this by two points. First, in the pre- and post-challenge phases, the adversary is not supplying the input to the honest algorithms, which are key and ciphertext vectors. Instead, it's supplying input to the simulator, which are key vectors and the desired inner products. Second, in the post-challenge phase, if the challenge of ciphertext was simulated, then the experiment would insert the inner product between U and the key vector so that the simulator gets the expected inner products and works properly. Once we have a gradually simulation-secure IPFE, we can obtain CP1AB. The good news is that the scheme due to AgriWall et al. can be modified for gradual simulation security. The key size of the modified ALS grows with the bound T and not the vector dimension, which corresponds to the attribute length. As explained earlier, we only need to set T to be 2 for the proof to go through, so our scheme will be succinct. The modified ALS is a direct construction for best efficiency. In fact, we have a generic transformation that converts any IPFE with selective IND-CPA security into an adaptively gradually simulation-secure one. This transformation also preserves key succinctness. To summarize, we propose a new security notion called gradual simulation security for public-key IPFE, and construct such a scheme with succinct keys. By combining it with piecewise-secure AKGS, we obtain ciphertext policy 1AB. Using dual system encryption or hash-proof systems, we obtain key policy AB. These techniques can also convert a KP1AB into CPAB. To connect the dots, we note that KPAB truly is a KP1AB by ignoring its multi-key security. From this blueprint, we obtain succinct and adaptively secure AB for ABP. I cannot go more deeply due to the time constraint, and please refer to our paper for more details. Thanks for watching, and that is the end of my talk.