 So, authenticated encryption is one of the success stories of cryptography in creating a dialogue between theory and practice, and this characterized by repeated interaction among academia, industry, and standards bodies. And in fact, you can see already in the 90s, you have these technologies coming out, you know, web, SSL, GSM, where they're trying to combine encryption algorithms, authenticity algorithms to somehow achieve security with, of course, varying degrees of success. This is what then inspired Velary and Namprempre in 2000 to identify and isolate this goal of authenticated encryption, which I've described at the top of the slide, which is, of course, the symmetric key goal of achieving confidentiality and authenticity simultaneously. Then following the work of Velary and Namprempre, there were various back and forwards between academia and the industry, in particular, standards bodies. Immediately following, there is this so-called first wave of authenticated encryption algorithms, dedicated authenticated encryption algorithms, which are able to add authenticity at very minimal cost over the basic encryption algorithms. I've listed three of them up here, IPM, XCBC, and OCB. However, these algorithms also came with patents, and these patents is what made, you know, standards organizations like this, perhaps, a bit uncomfortable, and when they were looking for new modes of operations, they looked more towards others, which had come in response, kind of a second wave of dedicated authenticated encryption algorithms, which were then patent-free. These algorithms, in particular, GCM, were then adopted into many different standards. So I already mentioned this recommended GCM, they also recommended CCM. Then in 2004, you also get GCM and IEEE 802.11. And in 2008, you get GCM and TLS 1.2. So GCM starts to spread in all these standards and by 2013, what do you see? Well, it's hardly deployed, actually, in fact, in TLS. There's usually just RC4 being used for the encryption over there. But then, after a lot of work by researchers, a lot of attacks. And in fact, you want to see a related story, see the SHA-1 collision presentation being given later on, crypto. After a lot of work, you're finally able to convince people to start using algorithms other than RC4. And in 2017, more than 70%, you see it deployed, GCM deployed. But still, you can see, it took about roughly 10 years to see widespread deployment of GCM after its creation. And there are all kinds of reasons for that. There's migration costs, effort, why should you switch if it works? There are no attacks and why should we switch algorithms? And maybe the already deployed algorithms have been optimized so far that the new algorithms might not be able to compete as well. Although in GCM, a lot of work has been placed into improving that. So then, that naturally leads to the question, well, then, what are we going to do with all these new different settings that have been discovered in the past few years in authenticated encryption and academia? I've just listed a few over here, you know, okay, non-smissive systems, robust authenticated encryption security and the variable stretch online schemes, release of unverified plaintext, multi-user security. And just a few of them are missing others. Then there's a whole bunch of schemes coming out with a Caesar competition, which is supposed to end in December of this year. So, I mean, from a past experience, it seems like it might even, it might take 10 years, maybe even longer if at all, if these schemes get deployed. So, you know, kind of thinking, so then what's the point? But there have been situations that have been, you know, results which have actually been able to make it faster to practice or at least try to. So, for example, they try to exploit already deployed algorithms as much as possible. Here I've already listed one sponge wrap, which tries to, which converts SHA-3 into an authenticated encryption algorithm with kind of the idea that if SHA-3 is deployed, then you can easily get authenticated encryption immediately. Then there's also this TLS 1.3 non-srandomization. This was introduced during the discussions of TLS 1.3. In order to, I mean, there were concerns on multi-user attacks, basically attacks that are possible once you deploy algorithms very widely. And this non-srandomization is a very simple modification. You just, it allows you to use the authenticated encryption algorithm still as a black box, but you change, you randomize one of the inputs and this is supposed to add some extra security to this, to these, against these multi-user attacks, which was then formally analyzed by Larry and Takman last year at crypto. And then another example is GCMS IV, which is published at CCS. What they do over there is they exploit all these improvements that have gone into making GCM as efficient as possible on these Intel architectures. And they say, okay, but GCM itself is fragile, can get something better out of it and still using just basic GCM components, but rearranging them, they create GCM SIV, which is, which basically addresses this non-spragility issue in GCM, but still is able to take advantage of all the progress that's been made on GCM itself. So then the research question we kind of, well, at least our motivation for our research was, given all this long deployment time and the fact that there are all these new settings, how do we squeeze as much as we can out of the currently deployed algorithms? And how can we get these new settings faster out into practice? So what we focused on is two settings, okay? We just kind of roughly, we looked at non-smith resistance, originally formalized by Rockaway and Shrimpton, Eurocrypt 2006, and also it's release of unfairified plain text setting. And this is roughly the rest of the talk, it's just one part and then second part. So starting with this non-smith resistance, we actually kind of isolate this different property that you can achieve, which we call non-smith use resilience. And just to give a brief background for those who aren't familiar, what is non-smith use resistance? Well, okay, you've got an authenticated encryption algorithm over here. You've got a sender and a receiver, sender and the receiver share a secret. And whenever the sender wants to send a message, it takes a message, sends it through the authenticated encryption algorithm to get a Cypher text, sends it over to the receiver who then decrypts it and either gets the original message or an error symbol. And in order to be able to achieve security, this authenticated encryption algorithm needs to be stateful or randomized somehow. And the way that this is usually formalized is via an additional input, okay? So the authenticated encryption algorithm is usually deterministic and stateless, that's how they're defined. And then there's this additional non-synput which gets attached to the message and that will then get processed into the Cypher text. The non-syn is still attached to the Cypher text and sent like that to the decryption algorithm. And the catch is that this nonce itself, it either needs to be random or it needs to be some unique value, kind of capturing this state or randomness. And what happens in nonce misuse settings? Well, the nonce is then no longer unique. It's for some reason, it's repeated due to some errors. And then the question of course is, what kind of security can you get in that kind of setting? So most conventional schemes, they have these nonce misusing attacks, they lose all security. So you get OCB, GCM, you get confidentiality breaks, you get authenticity breaks. And as a solution, so Ragoway and Shrympton, they came up with SIV. Then there was GCM SIV that I mentioned. These provide so-called best possible security when you have these nonce misusing attacks. And then you can ask yourself a question, well, okay, this is a nice idea, but can you do nonce misusing attacks out in the wild, out in practice? And kind of guided by Adam Langley's statement, the internet is vast and filled with bugs. This bokeh is all they did, performed an internet-wide search, searched for TLS servers and tried to see what they were doing with their nonces basically. And they found three different settings. They found one in which the nonce was generated randomly. That means that you wouldn't really see a repeat, but if you collected enough data, you might see one. There's a second setting in which the servers repeated the nonce once and then actually continued correctly updated the nonce each time. And then in the third setting, of course, the nonce was never changed. So for this last one, there's nothing you can do. The best you can hope for is that maybe they're using one of these nonce misuse resistant algorithms. And that's it. But then these first two settings, and what basically, what can really go wrong in practice? What kind of attacks can you actually mount against algorithms in which the nonces repeated, might be repeated randomly or repeat once? So to kind of look at this question, let's take three algorithms. Take GCM, OCB, and Chacha 20 plus Poly 1305. All three algorithms are insecure in the nonce misuse setting, but all three behave very differently when you look at attacks. So GCM, there is Jews Forbidden Attack. It's been talked about already quite a while. And the moment you repeat one nonce, you can actually do a key recovery, partial key recovery, and all authenticity is lost for every single nonce. However, confidentiality, you do lose confidentiality for those nonces which are repeated. In fact, you can retrieve the X or the plain text of the nonces that are repeated. But it's only for those nonces that are repeated. You can't recover the encryption key and you can't figure out plain text for other nonces. We'll get any information about plain text encrypted under other nonces. OCB, in contrast, you get intermediate key leaked. All securities lost, regardless confidentiality and authenticity for all nonces. This is an attack that we describe in the paper. And then Chacha 20 Poly 1305 is actually an interesting algorithm. As far as I can tell, it was first introduced via an RFC and not from academia, but from settings without ASNI. And it actually learns from this attack over here, from Ju's attack, and they modify GCM's design. The design is pretty much the same as GCM except for one little change. It's still insecure in the nonce misuse setting. However, this Ju's attack is much more restrictive, much more limited. So then our designs like Chacha 20 plus Poly 1305 are the sufficient for most practical settings. And can we kind of formalize and describe exactly what advantage does Chacha 20 plus Poly 1305 give over the other two? And this is why we looked at this setting, this nonce misuse resilience, which describes an algorithm's ability to recover from security after a nonce is repeated. So this is exactly to address those, kind of understand what happens in those settings in which you might not have the nonce repeated all the time. So using this, then using this formalization that we come up with, you're then able to distinguish routine of three algorithms and actually formally justify that Chacha 20 plus Poly 1305 actually improves over GCM and OCB. So just to kind of briefly go over what those definitions look like, what the formalization looks like, this is a traditional definition, the conventional definition of confidentiality. You've got a distinguisher and an adversary over here which interacts with one of two worlds, either real world or ideal world. In the real world, it's interacting of course with the algorithm, with a particular key and can input the nonce and the message. And in the ideal world it's interacting with the random uniform random function with cell nonce and message as input. In the conventional definition, the adversary may not repeat the nonces. That's just a restriction that's placed on the adversary. And in the nonce misuse resistant setting, there is absolutely no restriction on the adversary. So how do you then formalize nonce misuse resilience? Well, you introduce an additional oracle that the adversary interacts with. So now the adversary interacts with still the encryption algorithm and still the random function over here. And with these algorithms, it may not repeat nonces. It needs to be nonce-respecting just like in the conventional definition. But then we also give it access to another kind of attacker oracle where it can then perform all its nonce misuse attacks, do whatever it wants to study about the algorithm under whichever nonce. With the only restriction being that it can't, any nonce that it queried here, it cannot use over here. Okay. So this kind of idea of adding additional oracle comes from Barwell at all, subtle AE, where they call these two oracles the challenge oracles and these two the honest oracles. So then just briefly comparing nonce misuse resilience to resistance. So resilience, of course, you still leak a significant amount of information when a nonce is repeated. It's just all it says is that the damage is limited. If you want proper security, then you want nonce misuse resistance where only quality of plaintext are leaked during nonce repeats. However, the advantage with resilience, there's already a widely deployed algorithm available who has nonce misuse resistance. I'm not a hundred percent sure about this, but I believe there haven't been any deployed algorithms, but I could be wrong, maybe key wrap or something. And then another advantage of resilience is that you can very easily construct a GCM variant which achieves this, okay? You could see Minomatsu and Iwata at ESC 2015. They talk about this kind of composition. So that's the first part where we looked at nonce misuse resistance. Then the second setting that we looked at was release of unverified plaintext and our new construction, which achieves it, GCM route. So, okay, again, briefly background, release of unverified plaintext, a lot of authenticated encryption algorithms that are out there. You can roughly categorize them in two different categories. This has nothing to do with generic composition. It's just that the way that the algorithms are designed. So they either, when they decrypt, they either decrypt and then verify or they verify and then decrypt. So decrypt and verify, meaning they take the ciphertext, compute a plaintext based on the ciphertext, and then verify using the plaintext. And then in verify, then decrypt, they take the ciphertext and tag, they verify that already and then only compute the plaintext, if necessary. So OCB, for example, is an example of the left-hand side. GCM is an example of the right-hand side. Although, as you'll see in a few slides, there's nothing about GCM that forces you to perform the operation like this. So, okay, what are some settings that might happen? So looking back over here, for example, these decrypt and verify algorithms, you're actually, before verification has completed, you're actually computing sensitive information over here, the information that you want hidden. And a lot of times in practice, this might be infeasible to hide that information. You might have side channels, there might be implementation limitations, you might have insufficient secure memory to sort the entire length of the plaintext. And there might be implementation bugs, where for some reason, the algorithm due to an optimization decides to release the plaintext without having completely completed the verification. So to give you an example of the latter, here's GCM, okay? So just to kind of walk you through this, the main components of GCM, you've got this counter mode over here, which is the encryption algorithm. And then over here, this is authentication, okay? So the way GCM works is it takes the plaintext, takes the nonce, plugs it into counter mode, and then encrypts like that. That gives you the ciphertext. And then this nonce is then sent through a block cipher, the ciphertext is processed through universal hash of here to compute the tag. Now, during decryption, so this is why I call it, so this is actually kind of an encrypt, and then you verify, I mean, sorry, encrypt and then authenticate. So that means that technically decryption would be, you first take the ciphertext, send it through here, you take the nonce and you verify, and then you are allowed to decrypt. However, these two operations can actually work completely in parallel. So you can imagine a fully optimized version of GCM in which one process runs the verification using the nonce and the ciphertext, and another process performs decryption using the ciphertext and the nonce in parallel. And maybe for some reason, the decryption, the plaintext is computed before the verification is completed. So that's why I say that GCM, there's actually nothing that forces you to perform the verification before you've completed the decryption. So release of unverified plaintext describes a setting in which authenticated decryption algorithms leak plaintext, regardless of whether verification occurs. And the type of solutions that we currently know that achieve good security in this rub setting are all kind of variable input length ciphers or wide block ciphers. So they often, these are very heavy constructions, they often require multiple passes, or you can get very dedicated constructions like AZ, very specialized, perhaps not so easy to implement. In particular, all these designs are very distant from deployed algorithms out there. And achieving release of unverified plaintext security seemingly requires a completely new approach. However, as you might guess from the theme of the talk, we say that we see that you can actually take GCM, apply some minor changes and achieve rub security. So at a high level, how do we do this? So this is just kind of an abstraction a little bit of our solution. What we do is we take the nonce and the plaintext and they're still used to compute the ciphertext kind of like GCM does with counter mode. Then this nonce is sent through, is going to be encrypted basically, but it's going to be kind of encrypted with a tweak, which is a digest of the ciphertext. So you're going to process the entire ciphertext and combine it and encrypt the nonce and now the encryption of the nonce will depend on the ciphertext. Then if you look at decryption, what happens if an adversary were to change one bit in the ciphertext or try to manipulate anything? Well then the decryption of the encrypted nonce would turn something completely random and you would get garbage over here. So this solution, this then high level solution can be applied to GCM. Here I've indicated the three modifications that we introduced to GCM. So the nonce now, instead of being sent into this hash function call and then sent through the block cipher, we send it straight to the block cipher. The output of the universal hash is extrad once before and once after the block cipher call and a zero, you know, constant string is padded before the plain text. Quickly, the features are that it's basically as efficient as GCM takes advantage of all current GCM expertise. It's more robust than GCM because it achieves this rub security. There's of course a trade-off, claim absolutely no nonce misuse resistance, possibly resilience, and it's an interesting alternative to GCM aside. And okay, finally there's also this, if you look in our paper in the appendix, there's this interesting application where you can use GCM rub to provide a very efficient solution to prevent crypto-tagging attacks in Tor which are actually attacks on anonymity. So just have a look at the paper for the more details on that. So to summarize, motivation attracts as much as possible out of tools that we already have. We looked at, we introduced nonce misuse resilience and GCM rub construction. Thank you for your attention.