 Hi, I'm Glierem and welcome to my presentation on revisiting RCC security and replay protection. This is joint work with Christian, Willy and Christopher. So, security notions are usually designed with concrete applications in mind. However, they often do not match the exact security requirements of their intended applications. So, what is their purpose? For example, what is the purpose of CCA2 security for PKE schemes? On one hand, we know that CCA2 security is sufficient to achieve confidential communication. However, there are also non-CCA2 secure schemes that also law for this type of communication. The same happens with RCCA security. So, RCCA security is a relaxation of CCA2 security. Relaxation in the sense that, on one hand, it is implied by CCA2 security. On the other hand, it does not imply CCA2 security. So, as I was saying, in RCCA security is necessary to achieve confidential communication. Actually, it is also sufficient to achieve confidential communication. But it is only so if and only if the message space size is large. For small message space sizes, in RCCA does not capture non-malleability, which is a requirement for confidential communication. This means that, in general, in RCCA does not capture confidential communication. So, in this work, we identified technical inconsistencies with existing game-based security notions, namely, in PDRCCA and in STRCCA security. We show that they are not implied by CCA2 security for the case of probabilistic decryption. And this actually contradicts the claim made in earlier work. And furthermore, they have no known operational meaning. So, this diagram represents the previous diagram of in CCA2 and in RCCA, but now it is two new notions. So, these notions in PDRCCA and in STRCCA security were supposed to be between CCA2 and RCCA security. However, as we show in this work, in CCA2 does not imply in PDRCCA security. As it turns out, it does not even imply the weaker in STRCCA security. In this work, we clean up the space of game-based security notions for capturing confidential communication. And we do so by following a systematic approach for characterizing security using a composable framework. Essentially, we define different applications of PKE schemes as benchmarks which are composable security notions and then use these benchmarks to assess whether gameplay security notions capture the intended application. So, we consider three benchmarks. The first, corresponding to the confidential communication I was referring to just before, this benchmark is taken from earlier work. The second benchmark is a variant of confidential communication, but where this time the receiver can filter out suffer text replays. The third benchmark is yet another variant of confidential communication, but where this time a third party can perform the suffer text replay filtering. So, we introduce these benchmarks and for each one of them, we introduce a game-based security notion capturing the benchmark. For the first benchmark, we introduce NCL-RCCA security. For the second, SRPRCCA security and finally for the third, PRPRCCA security. For each of these notions, we show that they capture the intended benchmark. In this presentation, we are not going to capture benchmark 3 nor int PRPRCCA security. Finally, in this paper, we give a full characterization of our game-based security notions. We show that they are correctly placed between CC2 and RCCA security and we also give all possible relations between all our game-based security notions. So, we prove all possible implications and all possible separations between the notions. Okay, with this, let's go into some preliminaries. First, let's go over preliminaries about PKE schemes. So, PKE scheme is just a triple of PPT algorithms and for correctness, we require that for any adversary A, the adversary cannot output some message such that for this message, encryption and decryption do not work correctly. Now, we are going to introduce a generic game-based security notion, X. So, a PKE scheme Pi is in X secure. If no efficient distinguisher can tell with which system it is interacting with, G0 or G1 and we will define these systems in the next slide with no negligible advantage. So, the game systems are defined as follows. Initially, the game systems generate a public-secret key pair using the key pair generation algorithm of the PKE scheme and send the public key to the distinguisher. There is a first encryption stage during which the distinguisher can ask for decryption of ciphertexts. The game will then decrypt the ciphertext that the distinguisher asks to decrypt and send the resulting plaintext back to D. Then, there is a challenge stage during which the distinguisher can simply ask the game to encrypt one of the two test messages and exactly what test message is encrypted depends on the game that the distinguisher is interacting with and the game will encrypt one of these messages and reply with a ciphertext back to the distinguisher. This ciphertext, which we hear with the note by CSTAR, is called the challenge ciphertext. Then, finally, there is a second encryption stage. During this decryption stage, the distinguisher can ask the game to decrypt, well, for ciphertexts again, but this time the game might actually refuse to decrypt some of these ciphertexts. The decision whether to refuse to decrypt or not is done based on some predicate PX, which is defined by the game based notion itself. Essentially, if this predicate outputs one, then the game refuses to decrypt the ciphertext that she submitted and otherwise the game decrypts the ciphertext and outputs the message back to the distinguisher. Okay, so let's just see a couple of examples of such predicates. So, for example, for CCA2 security, we could define the predicate as just checking whether the ciphertext that the distinguisher is asking to decrypt matches the challenge ciphertext. For RCCA security, we could define the predicate as just checking whether the ciphertext decrypts one of the two test messages. Essentially, for some security notion X, this predicate PX can be interpreted just as defining what the security notion considers to be a replace of the challenge ciphertext. So, then, the games defined by the security notion simply do not allow the distinguisher to obtain decryptions of replace of the challenge ciphertext. Okay, now let's go into some preliminaries about channels. We consider four types of channels in this work. Two of them are very similar. The first one is the insecure channel. Whenever Alice inputs a message M into the insecure channel, this message is simply output to if. Whenever if inserts a message M star into the insecure channel, this message is simply output to Bob. In the authenticated channel case, things are a bit different. Whenever Alice inputs a message, this message is immediately sent to both if and Bob. It is authenticated because only Alice can input messages into the channel. Finally, we have the confidential channel and the replay protected confidential channels. Here, whenever Alice inputs a message M, if only gets to see the length of M. If can either choose to deliver the jth message that Alice input or it can inject some new message M' into the channel. Depending on what if does, Bob then gets a message M tilde output at its interface. What is the difference between confidential and replay protected confidential channels? Well, the difference is that confidential channels allow for replays and replay protected confidential channels do not. But what does this mean? Essentially, each deliver query for the jth message that Alice sends in the confidential channel case is processed, causing the jth message that Alice sent to be delivered to Bob. In the replay protected confidential channel, this is different. So, only the first query to deliver the jth message that Alice sent is processed. Later queries for the same j are simply ignored. With this, we can now go to the benchmarks. The first benchmark captures confidential communication. Essentially, in the real world we have two resources, an authenticated channel from Bob to Alice and an insecure channel from Alice to Bob. Alice runs an encryption protocol and Bob runs a decryption protocol. Initially, the decryption protocol generates a public secret key pair and sends a public key over the authenticated channel to Alice. Of course, this public key also leaks to if. Whenever Alice inputs a message into her encryption protocol, the encryption protocol simply encrypts this message using the public key outputting some ciphertext through the insecure channel. If then sees this ciphertext and can choose to inject some ciphertext C prime into the insecure channel. The decryption protocol run by Bob will then try to decrypt this ciphertext C prime and if it is a valid ciphertext it will output some message empty to Bob. In the ideal world, we have a confidential channel and we also have a simulator sigma. Initially, the simulator generates a public secret key pair and outputs the public key to if. Whenever Alice inputs a message m, the confidential channel only leaks the length of m to the simulator. The simulator then somehow has to generate a ciphertext C and send it to if. Whenever if inserts some ciphertext C prime into the simulator, the simulator will choose to either deliver some message or inject a new one into the confidential channel and again depending on what the simulator does Bob will get some message emptied output at its interface. We say that benchmark one is achieved if the real world and the ideal worlds are indistinguishable. Okay so now let's go into benchmark two. The main difference is that well now the decryption protocol has an additional memory resource which it can use to store well ciphertext that it has already decrypted and output to Bob. Essentially everything else works as before except that now whenever if inserts some ciphertext C prime into the insecure channel the decryption protocol then checks into its memory to see if it has processed any related ciphertext and well if it has it simply ignore C prime. Otherwise it will store C prime into its memory resource it will decrypt C prime and output it to Bob. Okay in the ideal world everything is as before except that the confidential channel is replaced with a replay protected confidential channel. Again we say that benchmark two is achieved if the real and ideal worlds are indistinguishable. Now let's see why in RCCA security is not sufficient. So recall how the predicate for the security notion is defined. Essentially it just outputs one if and only if the ciphertext that the the distinguisher is asking to decrypt decrypts to one of the two plaintexts to one of the two test messages. So I would like to highlight that the confidential channel requires non-malleability and this is so since well if can only first learn message lengths sent by Alice. Second it can forward the messages that Alice sends to Bob and finally it can inject new messages and prime into the confidential channel which are then output to Bob. But since if does not know any of the messages that Alice sends it simply cannot insert or cannot really interfere with well the messages that Alice is sending. In particular it cannot take one of the messages and transform it into another related one. So essentially this confidential channel really captures non-malleability. However there are malleable pke schemes that are in RCCA secure and this is so since if you consider the binary message space then well the secret decryption stage does not really help in distinguishing well g0 from g1. So even if a pke scheme is malleable a distinguisher cannot take advantage of the second encryption stage and because of that cannot take advantage of the malleability of the pke scheme to manage to win the security game. Okay now that I explained why in RCCA is not sufficient to achieve benchmark one. Let's actually achieve benchmark one. So we introduce INCL RCCA security to achieve benchmark one. We say that a pke scheme pi is INCL RCCA secure if well there is an efficiently computable predicate V such that no efficient distinguisher can distinguish if it is interacting with g0 or with g1 with non-negligible advantage. The predicate for this security notion is defined as follows. So it outputs one if and only if well first the ciphertext that is asking to the crypt is related according to V to the challenge ciphertext and furthermore it also decrypts to the same as a challenge ciphertext. Notice here that the distinguisher is not given oracle access to V and the goal of V is to dissolve strategies that could win the security game but would not really help in breaking confidentiality. Checking whether the ciphertext that the distinguisher is asking to the crypt really decrypts to the same as the challenge ciphertext is key to ensure that no meaningful molding attacks are being disallowed by the game. So we show that INCL RCCA achieves a benchmark one for a single message and we also show that for the end challenge version of INCL RCCA achieves a benchmark one for N messages. So we introduce INCL RCCA and we show that it captures benchmark one and now one could ask well is INCL RCCA also sufficient to achieve benchmark two or in other words does INCL RCCA capture replay protection well we could not prove this and that is for two main reasons. First recall that V takes as input the secret key. Since the game does not give oracle access to V then how could the reduction check if two arbitrary ciphertexts are replaced off on another? The second reason is that actually V might not even compute an equivalence relation so it's not clear whether V could detect detect certain replays. Okay so to achieve benchmark two we introduce INCL RCCA security. We say that the PK scheme by is INCL RCCA secure if there is an efficiently computable predicate V satisfying two conditions. First for each keeper in the support of the key per generation algorithm V must compute an equivalence relation over ciphertexts. Second for each keeper in the support of the key per generation algorithm and for each ciphertext C and C prime if V declares this ciphertext to be related then they must carry essentially the same information what does this mean? Well it means that the description the statistical distance of the decryptions of C and C prime must must be negligible. Okay so PK scheme by is INCL RCCA secure if there is an efficiently computable predicate V satisfying these two conditions such that no efficient distinguisher which is given oracle access to V on any pair of ciphertexts and throughout the entire game can distinguish if it is interacting with G0 or with G1 with non negligible advantage. For this security notion the predicate is simply defined to be V so we introduce INCL RCCA security and we show that it captures benchmark 2. Here predicate V can be used by the decryption protocol for detecting and first also filtering out ciphertext replays. To achieve benchmark 3 which we did not introduce in this presentation we introduce INPRP RCCA security this security notion is defined very similarly to INPRP RCCA security the main difference is that now predicate V is not given the secret key so we introduce INPRP RCCA security and we show that it captures benchmark 3. The predicate V given by the INPRP RCCA security of a PK scheme can be used for detecting and filtering out ciphertext replays. Finally we give all possible relations between our game-based notions. We show that CCA2 implies PRP RCCA security which implies SRPRCCA security CLRCCA security and finally INCL RCCA security implies INRCCA security. Regarding separations we also show that INRCCA security does not imply INCL RCCA security which in turn does not imply INSRPRCCA security INPRP RCCA security and finally INPRP RCCA security does not imply INCCA2 security. For more details please have a look at the paper which is available on e-print. Thank you for your attention.