 So let's move on to the last talk in this session. So this talk is titled, On Symmetric Encryption with Distinguishable Decryption Failure. It's a paper by Elena Bogereva, Jean-Paul de Gabrieli, Kenny Petsen, and Martin Stam, and Jean-Paul. Let's give you the talk. Afterward. Afterward. OK. This is a joint work with Sasha Bogereva, Kenny Petsen, and Martin Stam. My talk will consist of two main sections. I will start with some motivation. I will describe what the distinguishable decryption failures are. And I will point out to a gap that they raise between theory and practice. And then as I propose solution, I will propose the amount of the recipe, which requires a change in the syntax and encryption schemes. And then, since this change in the syntax results in a different object theoretically, we'll have to revise a bit of the theory that we know about in the encryption. OK. So consider the following class of attacks. We'll have a center receiving an adversary. So the adversary intercepts ciphertext from the center. Let's say, let's call it the green ciphertext. And then the adversary is able to model this green ciphertext into a new ciphertext, the blue ciphertext, and sends it over to the receiver. And by observing whether the receiver manages to successfully decrypt this blue ciphertext or not, the adversary is able to recover some information about the underlying plaintext and the green ciphertext. And what makes these kinds of attacks firmly quite powerful is that the adversary is able to iterate over this procedure over and over. So he's able to obtain more ciphertext. Let's say the orange ciphertext and submit it again and recover more information by just knowing whether the ciphertext is valid or not. And by doing this over and over, he is able to recover the plaintext underlying the green ciphertext. Typical examples of these kind of attacks are black and blackers' attack on RSA and the voting spreading rocket on CPC encryption. And when these attacks first appear, they motivated the required NCCA security. But as I will show, as I will describe shortly, NCCA security does not always grant security against these kind of attacks. And this is because, for example, during decryption, an algorithm might perform a number of checks. And if any of these checks fails, then the decryption fails. However, if the adversity is able to distinguish between which checks fail, this might convey more information to the adversity. And such ability of this adversity is able to distinguish the exact decryption failure has an able number of attacks against, for example, TLS, the TLS, and like I said. On the other hand, in the NCCA model, the adverse beauty of the way that we describe genetic encryption, or we specify symmetric states, the adversity only gets the same error symbol, regardless of whether decryption fails or not cares. So you always get the same symbol per. So this creates a gap between what the adversity is able to do in the security model and the NCCA and what the adversity is able to do in practice. The common response that I usually get from the auditions is that this is a flaw in the implementation. And can be easily fixed by ensuring that errors are distribution in practice. However, this stands out not to be so trivial in practice because, first of all, as you remember, that errors have a use in practice, right? They're useful for public shooting. They're there for reason. Moreover, other side channels like timing side channels or the security protocols interaction with layers above or below can reveal which decryption failed, or which test or which check in the decryption are going to fail. And these things are hard to predict and prevent in practice. On the other hand, it is very easy to account for these distinguishable decryption failure attacks, indeed, by just redefining the symmetric scheme to return multiple errors. So we just let the decryption algorithm return a message, either a message, or instead of one symbol per, we let that be a set of symbols, a set of error messages, which we denote by S per. But since this technically results in a different object, we need to revisit a bit the theoretical result that you know about decryption. And then just at the top, I will do this. I will just revisit some of the non-results with you and see how things change and the amount of errors I think. So let's start with the following relation that was proposed by Brian Namperempra and at the same time by Katzenius. So this says that if a scheme is NCCA-secure and it satisfies cyber-less integrity, then the resulting scheme is also NCCA-secure. So this relation and its simplicity provides a versatile way of achieving the NCCA-security in the symmetric setting. And it also turned out to be quite useful because NCTEX and NCCA by themselves guarantee strong confidentiality, which is NCCA, and also much justification. So it became the target security notion for the decryption. Later, in a work by Brian Namperempra in 2004, under analysis on SSH, they extended this relation to the stateful setting. So now we have NCCA and stateful cyber-less integrity guarantee stateful NCCA. So these stateful notions, they are just standard variations of their normal counterparts and that they also capture replay and the other impacts. So these notions guarantee also security against replay and the other impacts, which are very important practice. And it can be shown that an encryption scheme satisfies these notions and must be stateful. And hence, that's where the name comes from. So the first thing we ask is, do these relations hold in the multivariate setting? So do these relations still hold if we allow schemes to have multiple errors? And the answer to that is no. So we have to follow in separation, which assumes that if a pseudo-uninfunction exists, then there exists a scheme which has multiple errors. And it is both NCCA and it satisfies NCCA text, but it is not NCCA secure. And similar separation does hold for the stateful setting. We can prove the same separation for the stateful setting. As a technical note here, we will see shortly in a few slides that it is possible to extend the notion of cyber-text integrity in two main ways, which are very natural. And these separations hold irrespective of which notion we assume for cyber-text integrity. OK, so given that these relations were quite useful in the past, can we obtain something similar in the multivariate setting? And that will be just our next result. So we prove the following relation, that any notion, or relatively new, which is in distinction between the chosen or under cyber-text validity attack and cyber-text integrity imply NCCA. And informally, NCCA is just a starting variation of NCCA, where the adversity is additionally given access to a cyber-text validity organ, which returns whether a cyber-text is valid, but no plain text, or if the cyber-text is invalid, it returns the exact description error. Also here, in this relation, with cyber-text integrity, it refers to the stronger variant that I will define soon. So we're only able to prove this relation using, assuming the stronger variant. And similar relations can also be obtained for other variants of NCCA security, like this. The stateful variant, or in this situation, is from random bits. OK, so here's how we can extend the cyber-text integrity for the multivariate setting. I will start by showing you the weaker variant, which will be denoted by NCCA star. So the experiment goes as usual. We obtain the genetic key, decentralization, and then we give the adversary access to two items, an encryption oracle and a try oracle. The encryption oracle behaves quite in a standard way, that it returns cyber-text and keeps the risks of the cyber-text that returns. The try oracle, then, when it is given a cyber-text, it will return whether the cyber-text is valid or not. In addition, if an adversary is able to submit a cyber-text to the try oracle, that was not previously output by the encryption oracle, and is valid, then the adversary wins the game. So before showing you the stronger variant, note that here that the try oracle only reveals whether a cyber-text is valid or not. So the stronger variant is defined very similarly, except that now the try oracle also reveals whether the cyber-text is valid or not. But when it's invalid, it also returns the exact RSMB. So OK, good questions to Oscar. Obviously, one can easily see that NCCA implies the recurrent notion of NCC-text R, but it's not clear immediately whether the converse is true. Secondly, you might question whether the other relation that we obtained, that is an NCCA and NCC-text imply NCCA, whether that still holds if we assume the recurrent variant, or just because we're not able to prove it assuming the recurrent variant doesn't mean that it doesn't hold, right? And both of these questions can be settled through the following non-trivial separation. So we show that given a scheme, which has a sufficiently large method space, and it's both NCCA secure and NCC-text R secure, we can construct a multiplier scheme that is both NCCA and NCC-text R, but not NCCA secure. So this immediately shows that NCC-text R is a weaker variant, obviously we restrict the weaker than NCC-text, and also shows that the relation will be proved assuming the recurrent variant doesn't NCC-text. So the next thing we look at is a notion called NCCA3. You might also know it under a different name. This was performed by Roger H. Simpson, 2006. And basically it concisely compresses the two notions of NCCA and NCC-text into a single notion. And this is defined as follows. So we define two gains. And the first gain, the adversary is given an encryption oracle and a decryption oracle. And in the second gain, the adversary is given an encryption oracle, which returns the encryption of a random message of the same size, and a decryption oracle, which always returns a pair. The thing we ask here is, can we extend this notion to the multiplier setting? And if so, what is the security that this notion guarantees in the multiplier setting? To difference this way to do, we simply change the definition to allow. So since now there's more than one single error message, we require that there exists an error message per node and the space of messages, the space of errors of the scheme. And that for all adversaries A, no adversaries in a single repeated two words. And in the two words, we now give the decryption oracle, which always returns a pair of nodes. So this is a very natural way of extending the notion to the multiplier case. So then, let's look at what's securing this notion guarantees in the symmetric setting. So we show that NCCA3 is equivalent to the combination of these three notions, which is NCPA, Nc textiles, the weaker variant of cypherless integrity, and a notion which we call error invariance. And informally, error invariance says that all inverted cyphertexts that are inverted can come out with the same error. So still the question remains whether this is a good notion. So then we show that NCCA3 implies NCCA and Nc text, and from the range of the pain before, this implies NCCA security. So NCCA3 still guarantees strong potentiality, which is NCCA, and it guarantees the general indication. So it is still a good notion for authentic encryption, but maybe it is too strong because it can be shown that NCCA3 is strictly stronger than the combination of NCCA and Nc text. So the next thing we look at is generic composition of authentic encryption, so realizing the authentic encryption to generic composition. And this was first looked at by Belaina Bramble in 2000. And one of the main results of their work is that anchored and matched empirages as the preferred generic composition technique for obtaining linear encryption. And the reason being that for any encryption scheme, which is NCCA secure, and any MAC, which is strongly enforceable, anchored and matched provides a scheme that is always in a scheme that is NCCA secure. And the same can be said about matched empirages or anchored and matched. Over later, or shortly after, crafting show that the matched empirages is also NCCA secure. When the encryption used is CBC mode or counter mode. So for the case of CBC and counter mode, which are the two that are mainly used in practice, at least as far as the generic composition techniques go, we really don't have or these papers don't tell us anything about, don't tell us much, why anchored and matched with CBC or counter mode should be better than like they are encrypted with CBC or counter mode. And however in practice, it turns one has been observed that the anchored and matched was less prone to attack than matched and encrypted when these even weren't synthesized with the CBC or counter mode. So we believe that we're considering a generic composition through in the light of distinguished application failures can provide new evidence of why anchored and matched is better than matched and encrypted. So we consider and extend the version of anchored and matched We also include an encoding part to account for the pre-processing that is common in practical schemes. So practical schemes normally include either padding or some kind of formatting. And that can be modded by including the encoding part and the composition. And then we have the volunteering that says that for any multiple error encoding scheme, so that we allow any encoding scheme to return any number of encryption or any number of errors. And any encryption scheme, which is in CBC secure and has any number of errors as well, that is multiple error. And any matter that is strongly affordable, the EEM composition means a scheme which is in CBC secure. So the good thing or the nice thing about this theorem is that security holds irrespective of the error behavior of both the encoding component and the encryption component. So this says that EEM is a very robust composition that does whatever encodings can be used and irrespective of the error behavior of the encryption scheme, security still holds. And if we look at the example I gave before about the attacks on SSL in the second that I mentioned, so I didn't present the attacks and the TLS, these serve as counter examples to show, for example, that a similar statement could be made about MAC, then encode, then grid. However, it may seem unfair that we don't allow the MAC to return multiple errors. But this can be justified as follows. First of all, MACs in practice are normally realized by having attack component and the verify component but the verify component is normally realized by generating the MAC, again the MAC tag and comparing it to the one that is attached or the one that's given. And there's not much space of how to do this like of different ways of doing this, right? So there's only one test condition that is happening there. And secondly, when the only example we could think of where you could have a MAC that returns multiple errors was the Geyser library example where the implementation of the MAC was implemented in a very bad way that it was verifying the MAC tag byte by byte and the adversary was able to distinguish which byte in which position the first MAC was different from the expected MAC. However, this results in the MAC itself being unsecured. So there's not much you can say about security if the component you're using or the component you're using is not secure. So it seems a fair assumption to assume that the MAC only returns one singular error. Okay, so in summary, we proposed the multiple errors, I think, in order to account for distinguish the description failures and our security models. And the hands-up and security guarantees are more or less into practice, but they are less dependent on the implementation. So, and this can be used in two main ways. For example, we can use it in a preventive approach. So whenever we propose a scheme, we can assign different errors in this to each check that's in the description algorithm and then prove it secure under this assumption. So then we have security, which is less implementation dependent and is less prone to being secure when implemented. Alternative, we can use it to look at the schemes that are already out there and try to model them and see if they're still secure and address is able to distinguish between different description failures. So that concludes my talk and thank you very much. Thank you.