 So this particular research project started when we were looking at TLS and in particular the new the upcoming version TLS 1.3 I guess since you all attended Brian's great lecture this morning I don't really have to motivate what TLS is about, but let me just say as a photographer I envision it usually starting with the following. Oh the clicker does work with the following idea Which I'm going to show you on the next slide Okay, great Okay, so I assume that this here is my my laptop computer and I'm going to access some some secure website So there's a web server and I want to secure connection between my laptop my client computer and the server but of course there might be attackers that try to Well degrade my security try to attack my connection Well, actually this isn't quite how the world looks like because there's about a billion of other people maybe using Their web Processes as well to to connect to web servers. There's main servers using TLS database servers There's embedded devices and sensors that use TLS to communicate their data to whatever service they want to communicate to So the world looks a bit more like this and Actually, even that's not quite how the world looks like because there are adversaries. They're not actually Interested in breaking my specific connection, but they do math surveillance So they have Huge capacities in storage and computation and they do mass surveillance on the internet and try to attack Well, we have to assume that they try to attack whatever they can So let's have a bit more of a closer look to TLS so from a like ten thousand foot perspective TLS looks like this It starts with a with one protocol phase Which is usually called the handshake and uses asymmetric cryptography and the role of this is to create a symmetric key Which is shared between the two parties that take part in the protocol And they use this key in the second protocol phase usually referred to as the record layer protocol To protect the actual payload data and this is based on authenticated encryption Until as 1.3 at least So in particular, it's non space Authenticated encryption and I just want to remind you what that means it means we have two algorithms and encryption and a decryption Both obviously take the key The encryption takes the message and an additional message the nonce and as long as the nonce is unique This is going to achieve some good notion of security, which I'm going to explain in a minute But the important property is we want this nonce to be unique. We don't need to be random There's a deterministic algorithm and the nonce just has to remain unique until we switch the key then we can reuse the nonsense The decryption also takes the key and the nonce and also of course the ciphertext to generate a message or maybe an error symbol So we want confidentiality, which means the ciphertext shouldn't tell you more about the plaintext There may be the length of the plaintext and we want integrity which is usually described as if you don't have the key You won't be able to come up with ciphertext. That is going to be accepted by the receiver so DLS in principle can use different types of non-space authenticated encryption But the one that is kind of in the pole position to be used in most connections is AESGCM, which I've tried to draw on this slide So there are some important properties here first the key to the authenticated encryption is going to be used as a key to the AES block cipher and it's used only there Okay, so whenever we use the key it is key AES The nonce TLS only uses 96-bit nonces and for those nonces GCM will work as follows It will take those 96 bits and append another 32 bits before it 96 bits and 32 before it gives them to AES And basically this part of the scheme here is then just a counter mode encryption that starts at the nonce Okay over here. We just evaluate AES with a key that we got on a all zero bit string This is just to generate another like uniformly random value Which we are going to use as a key and in a hash function So this here is an almost X or universal hash function. It's based on finite field arithmetic But that's not important for us today and basically what we do is we hash the ciphertext that we computed we computed it Here using counter mode meaning we X or the message blocks to the output of the block cipher And we hash this and then again apply another like mask value that we obtained from AES To obtain the last block of cypher X. This is basically a Mac So you can think of this as being an authenticate then and sorry encrypt then Mac scheme with counter mode and a Almost X or universal hash function based So how would this be used in TLS? How would TLS use authenticated encryption to predict the data? So first of all, there's two directions one from the client of the server one from the server to the client They use completely independent keys so we can focus at them independently. I'm only talking about one direction on the following slides and The goal of TLS is to actually Transmit like a sequence of messages Okay, so client and server may communicate for some time and we want to communicate those messages in sequence. It's a sequence of byte string that byte strings So what we would do then is we use the authenticated encryption Of course with a key that we got in the first phase The message that we want to transmit and the sequence number of that particular message So we count the messages and just use the sequence number to encrypt message use that as a nonce and of course like the nonces are 96 bit lungs. They're not going to overflow So this value is going to be unique and it's going to be a very good nonce And as long as we're in the kind of the single connection domain We only look at the security of the single kind of a single connection. There's a perfectly good scheme Okay, but now so this is all discussion which happened on like Before our research project even started, so I'm basically just recapping this There is a possible attack that a very powerful computationally and start twice powerful entity could run and this is as follows I'll I'll quote the first part of ASGCM here. Okay, so I'm going to look at the first of the encryption of the first block of The first message of the channel now the first sequence number is all zero. So the first nonce we use is all zero So the nonce that we input here turns out to be actually 126 Zeroes than a one and then a zero. I don't know why I put it to here should be one zero And also, let's look at the output here because for most protocols for example agent if you if you encrypt an HTTP connection the first Message that the client is going to send to the server is going to be it's going to be HTTP get and then you are on So we know what this plain text is going to be the same holds for almost like any other protocol that is specified They start with some kind of header information which is fixed So by just looking at the traffic we will actually be pretty good in predicting the first blocks of the plain text Okay, so when we attack a connection, we can just assume that this isn't there we can kind of uncompute this and Get the output that must have been used To encrypt that part of the plain text And now if you are a very powerful entity with a huge storage and computation center Maybe in the desert of Utah then you could have the idea to compute a huge table For this input. Okay, and this table contains some huge selection of keys However much you can store and the corresponding output of the block cypher using that key on that input Okay, and now if you once you see your connection you try to compute this this output value by kind of predicting the head of Oh, you that is encrypted and you look up In your in your table you look you look up the key that might be used in that connection and you might have the key I mean there may be several keys or so but there's a pretty good probability that if you find the key that it's actually the correct Now is this attack realistic? so Let's make some bold assumptions here. Maybe the NSA can store two to the 64 of those ropes It's probably a bit more than they can actually store, but it's not too far away Then we have some billions of devices that run TLS sessions every day And by just assuming each of them runs a hundred sessions. We arrive at pretty much two to the 40 sessions Okay, so a s has a 128 bit key So we still have a security margin of something like two to the 21 and a million chance So is this really a problem? Well, I'm not sure I'm kind of undecided because on the one hand It's the NSA is going to see one purely random connections So most likely a picture of a cat or something like that But on the other hand, I've not used any particular property of AES Maybe they know something about AES where they can slice off some additional bits and they can store a bit less or they can I don't know optimize this attack in some way And then it becomes kind of close to being uncomfortable, right? It becomes kind of close to being They can actually break connections Okay, so what the TLS working group then did is They said well a very important property of this attack is we all use the same value here Because if we wouldn't use all the all use the same value, we wouldn't be able to pre-compute the table Okay, so let's just not all use the same value instead Let's add some kind of a randomizer here and randomize the nonce before we actually give it to AES Okay, so they're going a random value 96 bits random value that they don't change during a connection So they choose it basically when at the same time they they get the key. It's actually derived from the same key material and They just use what I explained before it's just randomizing the sequence number with this nonce before they give it to be Authenticated encryption And now there are some obvious questions. The first one is well formally What did they want to achieve with this second? Didn't they did they achieve it and third if they did or if they did not quite can we do better? Okay, the answer to the first question in our opinion is what they want to have is kind of multi user Authenticated encryption security so authenticated encryption security where we do not only care about the security of one connection We care about the security of the multitude of connections Then we show that actually this TLS countermeasure can be seen as kind of building a new Authenticated encryption scheme from the one we started from and Finally, we analyze in the model that we we provide in the paper the plain ASJCM Then the mode that is proposed in TLS 1.3. We will call it our GCM for the rest of the talk and Also, we are going to propose a mode that is called x gc that we call x GCM Which is basically GCM using a as x where a as x means We apply a mask before and after Using a yes, I'll show that on one of the next slides two important things here one is all the statements are in the idea cipher model and for the purpose of the talk we focus on key recovery security the main reason is it's a bit simpler and The full authenticated encryption security is basically do the same as for key recovery security and then standard ASGCM analysis So you wouldn't learn anything new if you're at the ASGCM papers anyway okay so those are the schemes and On one slide kind of what we show is that in GCM Basically, if you increase the number of users you're losing what you would expect by the hybrid argument Okay, and our GCM achieves something which is better. So basically You start at the same security for a single user, but then your security degrades a bit slower and X GCM the one that we describe basically it has it has just better security overall So we also increase this or improve the security in the single user case and that kind of goes on for as many users as You want to have Okay, so let's first talk about multi user key recovery security So we formalize this as a game where we give the adversary Well for now three oracles the first one allows him to create new user instances and the The only thing that happens is there will be a new key sampled in the game Then we give it an encryption oracle using the instance They choose supplying a nonce and the message obtaining a ciphertext and accordingly a decryption oracle They can again choose the instance the nonce and the ciphertext and we return whether it was a valid ciphertext or not and the goal of the adversary is To guess one any one of the honest user's keys Okay, so if there's one key which the adversary guesses you want this is kind of why it's multi user security As I said before all we do is in the idea cipher model an idea cipher You can see it as basically a family of uniformly random permutations Indexed by this key. So for each key you get a uniformly random permutation that you can query Forward or backward, whatever you want Both the scheme and the adversary have access to this idea cipher Basically, we formalize it as an oracle that can be queried by the scheme and by the adversary and it idealizes block cipher For example, AES So the full multi user key recovery security model in the ID cipher model looks as follows We have the same three oracles as before and now we also have the oracles to To query both directions of the idea cipher the goal is still to guess the key Okay, I'll have to speed up a bit So let's now look at the multi user key recovery security of GCM So the proof idea is as follows all the proofs we do follow this same structure first We kind of we have the idea cipher here and here so the the states of these oracles are kind of entangled So the first step is going to be then that we say this is almost the same as if we were using a different idea cipher here And here and this is where the main part of the proof actually occurs And then once we did this these oracles are of no help because they don't have any correlation with the rest of the random experiment So but also remember that the key is only used as a key to the idea cipher nowhere else So the actual value of the key never appears in the game So what you're actually what the adversary actually has to do is he has to guess one out of you Where you use the number of users uniformly random keys and overall he's going to Resolve this or to solve this with a probability you over to to the kappa where kappa is the length of the key Okay Now in a bit more detail You can envision the idea cipher as follows it's basically a table where we have the keys here so each key describes one column each input describes one row and Assume that the user used these or the honest user instances used these two keys Now we're in the step where we want to detangle these oracles I should have explained this before Okay, so we're in the first proof step We basically want to show that these are irrelevant and we want to replace the idea cipher that is used by both sides By different idea ciphers the only way for the for the adversary to detect this is to basically make a call to the idea Cipher which is a call both here and here and See that there's a difference. Otherwise. He's just going to get like independent values Okay, so the only way he can do this in that case is by guessing a correct key of a user Okay, so he will guess one of these Whatever number of uses we actually have rows and the probability for him to do this you can I mean it's it's a probability-theoretic computation We have to do so it's it will end up to be u times p where use the number of user instances P is the number of idea cipher queries of the adversary over to the cup Okay, once we have done that we are in the step that basically We can replace the two idea cipher the one idea cipher by two independent ones And we can use the same argument as before and the over probability that we're or the overall advantage of the episode That we get is you times p plus one. This is one from the guessing the key Okay, we show an adversary strategy that actually shows this bond is pretty much tight So this is a small constant. It's probably like one over ten for realistic parameters And otherwise we get the same we describe an adversary strategy that basically just implements What I've explained on the very on one of the first slides which just checks Which encrypts the same value with the same nonce and then just does this Recomputation and this adversary strategy will pretty much achieve the the bound that we gave for the scheme So now let's look at how we can view the RGCM scheme as an authenticated encryption scheme Basically, we view the randomizer as a part of the key and then we just inside the scheme So this dash box shows our GCM. We just x or it to the nonce Okay, now it's an authenticated encryption scheme as before it just uses a longer key Okay, and now We follow the same proof structure as before but it's going to be more intricate because now we cannot give up once the adversary Just guessed one of the honest keys we used because otherwise we would end up with a very same bound as before so we look at what our GCM actually does and Basically the the parts of the ID cipher used by the honest guys. They look somehow more like this So for one key, this is one user instance There will be patches in here, right because this it's basically we do a Counter mode encryption. So we use some part of the idea cipher What that that is kind of continuous and this is one message. This is one message This is one message and so now we can do a similar argument before we can count the adversary queries we can count basically the number of queries done by the honest users and Estimate what the probability of the adversary is to actually guess in one of those regions Okay, and now this is you times number of users times you number of adversary queries times basically the Area of these patches and but now the overall The denominator here becomes bigger because we don't only have to guess one of the rows We have to guess one of the row and column combination combinations of one of those at Patrick's Okay, that's why we get improved security here Okay, but we also have backward queries because the output of the cipher is not Randomized we can basically just view a part of the cipher text or the adversary can take a part of the cipher text Which is an output of an AES blog and try to basically Invert the random permutation invert AES and try to figure out the sets figure out the keys by this So if we look at the outputs of the idea cipher, so this is now the back of the inverse direction Basically, it's much more sprinkled out. So it's some random. We for each key. We see some random cipher texts here Okay, and now we can the adversary can guess any one of those lines and can try to find a key corresponding to this But in contrast to the very first Attack this doesn't scale anymore because most likely if he sees some cipher text block It has been used by one or only a few users So whenever he does an inverse query to the block cipher is going to attack only a very few number of user keys So the attack doesn't scale as it did in the first Okay So this ends up to be a small constant times P over 2 to the kappa, but this is independent of the number of users Okay, is that all and the answer is unfortunately no But I have to be quick on this and the reason is here this this query to the block cipher is not randomized Okay, so we cannot replace this dependent idea cipher by a completely independent one at this step Unless we also make this part here independent But this is one fixed input to the idea cipher that the adversary can easily give as well So this is just is this We have to take care of this in the proof and we basically do this So this is also why the proof I show here only holds for For passive adversaries that do not use the verification article we do this by basically saying We do this X or here So we as we kind of change the distribution here a bit Gathering some error in the in the security bound to be uniformly random and then you don't get any information about this value here What's ever so that's how we deal basically with with this stupid query. So that's your mobile It's pretty complicated. But what I want to highlight is we have u times p here Which was the problematic term, but the denominators are pretty big and here with the smaller denominators We do never have u times p. We have p's and use but only additions So these terms are much much smaller and that's why so these are kind of for The actual security these are very relevant and they don't like they don't grow with the hybrid argument Lineal growth Okay, we we show but we show that this term here for example is necessary So there is an adversary strategy that actually works on inverting particular ciphertext outputs or ciphertext parts and The bound is that part of the bond is tight Okay, just Explain that this here is basically x a or a as x So this is another part of key like 128 bit of randomness Which we use to mask the input and the output of the block cypher and so this entire scheme is what we would call a sx gcm Okay, and the idea here is we can basically use the result of key, you know and draw the way who analyzed Well, they analyze desk x so used and that We have to kind of adapt it a bit to the multi-user setting and then we basically get in differentiability of the construction And query in the component from these two independent ciphers, which is exactly what we are going to need in our next proof So that proof is actually being a combination of this in differentiability argument together with the proof of JCM And we see that this bond is much nicer and also much much better than the proof of the bond of our GCM And it holds for all types of also active adversaries so the Authenticated encryption scenario or security is basically the same woman. Okay Is basically the same as standard authenticated encryption with multi users So we have the new Oracle and various instances in encryption and decryption and we are in the idea cypher model Okay, and the results that we obtain there are basically this is the readside for GCM So this is the key recovery term and these terms all stem from the analysis of ASGCM standard analysis single user model and so So that's how then we obtain all the actually authenticated encryption security Okay, I'll have to stop here. So I just say thanks for your