 Welcome to my talk. I'm Liu and going to talk about updatable encryption. In this work, we propose a new definition for updatable encryption. We call it backward leak unidirectional key updates. Then we show that backward leak unidirectional key updates are strictly stronger than the existing unidirectional key updates. We also propose two secure constructions of updatable encryption. First, I'll review what is updatable encryption. Let's consider the following scenario. I saved her encrypted data on the Cloud server. Her computer is attacked and her secret key is leaked. To protect her data, she generates a new secret key. She should not reveal the secret key to the Cloud server, so she downloads all encrypted data from the server, decrypts them, encrypts them by the new secret key again, and uploads them to the server. This incurs significant efficiency loss. To resolve this issue, we use updatable encryption. In updatable encryption, we can periodically update a secret key and cyberdex. An updatable encryption scheme has key generation encryption and the decryption algorithm reasons as a standard encryption scheme and has two additional algorithms. One is the token generation algorithm. We can generate an update token from two secret keys. In this talk, we focus on cybertext-independent updates, where we do not need a cybertext for generating the token. The other one is an update algorithm. We can convert a cybertext under an older key into one under a new key by using an update token. If Alice uses updatable encryption in the scenario that I explained first, she generates a new key and an update token. Then she passes the token to the server, and the server can directly update all cybertext without using Alice's secret key. One issue is whether a token leaks information about secret keys or not, since the token is generated from two secret keys. In previous works, there are three categories for key updates. The first one is the bidirectional key update. We can infer a secret key from both directions via a token. That is, we can infer a new key from a token under an older key and vice versa. The second one is the unidirectional key update. We can infer a new key from a token under an older key. However, we cannot infer an older key from a token under a new key. The last one is the no-directional key update. We cannot infer keys from a token. All previous updatable encryption schemes have a bidirectional key update. This is not desirable since such tokens leak more information about secret keys. Another issue is whether a token allows downgrading cybertext or not. There are two types of updating. One is the bidirectional cybertext update, where we can both update a cybertext and downgrade a cybertext and a new key into a cybertext under an older key. The other one is the unidirectional cybertext update, where we can only update a cybertext. The unidirectional cybertext update is more desirable since a token gives less information to adversaries. However, all previous updatable encryption schemes have bidirectional key updates. A simple example of updatable encryption is as follows. A secret key is an element in the P. A token is X sub E plus one over X sub E, where X sub E plus one is a new key. A cybertext is an algorithm-like cybertext. We can update a cybertext by using the token since X sub E is canceled out. It is easy to see that this example is the bidirectional key update and bidirectional cybertext update. The type of key and cybertext updates affects trivial winning conditions in security games of updatable encryption. Let's see an example. In the table, each number denotes a time period called epoch. In UE security, we consider secret key corruption and token corruption. In the corrupted key law, X mark means the secret key is not leaked. And check mark means it is leaked. In the corrupted token law, X mark means the token is not leaked. And check mark means it is leaked. In the bidirectional key update setting, we can infer the secret keys of the second, third and fourth epochs, since we can infer from both directions. In the unidirectional key update setting, we can infer the secret keys of the second and third epochs. However, we cannot infer the fourth secret key since we cannot infer in the backward direction in this setting. If adversaries obtain a secret key that they want to attack, they can trivially break the security of encryption. So the bidirectional key update triggers more trivial winning conditions than the unidirectional key update. This means the security in the unidirectional key setting seems to be stronger than the security in the bidirectional setting. However, Jan proves that the security in the bidirectional key update setting is equivalent to the security in the unidirectional key update setting. This is surprising, since the direction of updatable encryption does not matter much. However, here is a question. Why do we consider the unidirectional key update where key inference is the fourth direction? We can consider another unidirectional key update variant where a key inference is the backward direction. That is, we can infer an old key from a token and a new key, but cannot in the opposite direction. This is a very natural setting. To distinguish two types of unidirectional key updates, we call the previous unidirectional key update forward leak unidirectional key updates. Let's see the backward leak unidirectional key updates are preferable to the forward leak one. Here, we assume that the ciphertext update is unidirectional. Suppose that the middle secret key is leaked. Then, in the forward leak setting, we can get the newest secret key we are talking. In this case, even if we securely delete all the ciphertext, we cannot protect the newest ciphertext and updating the ciphertext does not help us since the newest key is inferred. In the backward leak setting, we can get the oldest secret key we are talking. In this case, if we securely delete all the ciphertext, we can protect the newest key and the ciphertext. Note that I assume that the ciphertext update is unidirectional. Later, I add that unidirectional ciphertext update could be standard in the backward leak unidirectional setting. This fits the spirit of updatable encryption. In this work, we introduce the definition of backward leak unidirectional key updates as I explained so far. Surprisingly or unsurprisingly, we also show that the backward leak unidirectional key updates are strictly stronger than the forward leak unidirectional key updates. This is in sharp contrast to Jan's Equivalence theorem. More concretely, we show that existing secure UI schemes in the forward leak unidirectional key updates setting are not secure in the backward leak unidirectional key setting. We present two updatable encryption schemes. One is secure in the backward leak unidirectional setting under the learning with errors assumptions. The other one is secure in the no-directional setting and based on indistinguishability of the session and one-way functions. This thought the open problem posed by Jan at age of 50 to 2020. This is the comparison with previous schemes. All known schemes are secure in the bidirectional key updates setting and the bidirectional cyberdex updates setting. By Jan's Equivalence theorem, these schemes are secure in the forward leak unidirectional key updates setting. We propose the first secure schemes in the backward leak unidirectional and the no-directional key updates setting. Our concurrent and independent work by Slamanin and Strix presents a secure scheme in the no-directional key updates setting. However, the size of secret key and the cyberdext depends on the total number of updates. In previous and our schemes, the size of secret key and cyberdext is constant. Let's see the backward leak unidirectional key updates are strictly stronger than the forward leak one. First, we see a simple but crucial observation here. UE needs the power of public key encryption. All existing UE schemes need PKE power since they rely on concrete assumptions that imply PKE. In addition, Alamati, Montabomelli and Patronavis prove that UE implies PKE. So, we can assume a UE key consists of the secret key and public key parts. A token is generated from two keys. Here, an older secret key is necessary. Otherwise, the token does not have the power of converting an older cyberdext into a newer. How about a new secret key? In fact, we do not need the secret key part of the new key. Let's consider a token generated from an older secret key and the public key part of a new key. This token potentially converts an older cyberdext into a new one since the public key part of the new key is sufficient for encryption. In addition, the token does not have information about SK sub E plus one beyond the PKE sub E plus one. So, the token could be backward leak in the directional and could not be used to downgrade a new cyberdext into an old one. In fact, our backward leak in the directional scheme has this structure. In contrast, a token generated from two secret keys is forward leak and bi-directional. Note that if we use PKE sub E, it is not clear whether a token can convert a cyberdext. Now, I present a concrete example that is secure in the bi-directional or forward leak in the directional setting, but not secure in the backward leak in the directional setting. Jan's equivalence theorem says that we trigger the trivial winning conditions in the bi-directional setting if and only if we trigger the trivial winning conditions in the forward leak in the directional setting. We consider the leakage condition in the table. In the bi-directional setting, we can infer the second, third, and fifth secret keys via corrupted tokens. As I show in the table, the first, sixth, and seventh secret keys are protected. In the forward leak setting, we can infer the fifth secret key, but cannot the second and third secret keys. However, we cannot set the second and third epochs as a target, since we can convert a cyberdext under second and third keys into one under corrupted keys via tokens. So, as in the bi-directional setting, setting second and third epochs as a target triggers the trivial winning conditions. In the backward leak setting, we can infer the second and third secret keys, but cannot the fifth secret key. Here, we can set fifth epoch as a target, since we cannot convert a cyberdext in the fifth epoch into one under corrupted keys in the unidirectional cyberdext update setting. Thus, unlike the forward leak unidirectional and bi-directional setting, the fifth epoch does not trigger the trivial winning conditions. This corruption setting shows the separation result. Previous schemes are secure in the bi-directional or forward leak unidirectional setting. In the setting, we can not set the fifth epoch as a target. However, in the backward leak unidirectional setting, we can set the fifth epoch as a target. Non-secure schemes do not prevent extracting a new secret key from a token under all the keys. So, it means non-schemes are not secure in the backward leak unidirectional setting. I do not explain security experiments for UE since they are not crucial to understanding the difference of directions in UE. Now, let's see our construction. First, I explain our backward leak unidirectional scheme. The idea is simple. I use fully homomorphic encryption to explain our idea. A token is the ciphertext of an old secret key SK sub e under new public key pk sub e plus 1. A rectangle denotes encryption under some public key. A ciphertext is simple encryption of a message under pk sub e. To update the ciphertext, we encrypt the ciphertext by using the new public key pk sub e plus 1. Then, we homomorphically decrypt the ciphertext under pk sub e by using the evaluation algorithm of FHE and get the ciphertext of M under the new public key pk sub e plus 1. This idea is based on FHE. However, we directly construct our scheme by using the key switching technique. So, we do not rely on FHE in our scheme. The construction idea comes from unidirectional prox with encryption based on the LW assumption. The token can be generated from an old secret key under new public key. So, it is easy to see that the token is backward mid-directional. We can also see that our scheme has unidirectional ciphertext updates. If we can downgrade a ciphertext by using the token, we can break the security of the old key without the old secret key. Note that we do not need to use the old secret key to generate a token. Lastly, we see our non-directional scheme. The idea is obfuscating re-encryption circuit. A re-encryption circuit takes an old ciphertext, decrypts it, encrypts the result again and outputs the re-encrypted ciphertext. A token is an obfuscated re-encryption circuit. In the circuit, the old and new secret keys are hardwired, but they are protected by the security of obfuscation. So, this scheme has the non-directional key updates. It is easy to see that this scheme has unidirectional ciphertext updates. In our construction, we cannot use secret key encryption in the black box way since we use indistinguishability obfuscation. We use punctual QRS as secret key encryption and achieve secure UE. Let me summarize my talk. We propose a new definition for updatable encryption, backward leak indirectional key updates. We show that existing bi-directional key updates scheme are not secure in the backward leak unidirectional setting. This is in sharp contrast to Jan's Equivalence Program, which says the security in the bi-directional key update setting is equivalent to the security in the forward leak unidirectional setting. We propose two new UE schemes. One is backward leak unidirectional scheme from the LW assumption. The other one is no directional scheme from IO and one way functions. Both schemes have unidirectional ciphertext updates. Our take-home message is the direction of updatable encryption does matter. That's it. Thank you for watching my talk.