 Hi everyone, so I'm Ruth and I'm presenting some work that I did together with Mihira and Bjorn and our work is called Nonsense Unnoticed, AEAD Revisited. So our work's on symmetry encryption, so maybe when you think of symmetry encryption you get a picture like this in your head. I think we can all agree encryption should probably take a message, it should probably return something and decryption should probably take that output and recover the message. Encryption and decryption should probably also share a key. And you would think for how long we've been using symmetry encryption, we should have figured out by now all the other inputs but we seem to still not have made up our mind. So let's step through a bit of the evolution of how symmetry encryption has worked over the years. So I guess it's a crypto talk so I need to start with the one-time pet and we eventually moved on to randomized notions of symmetry encryption and our security goals moved forward to privacy in CPA style security goals. This was usually a company with schemes that were motor operation, block cipher things like CBC. If I can fast forward to where we are currently, you will see that standards and protocols are using non-space encryption, what I'm going to call NBE1 syntax and our security goals have moved from privacy only to now requiring privacy and integrity better known as AEAD. So your NBE1 schemes are GCM which everyone knows is used in TLS and other things like OCB and the final portfolio of CSER and stuff like that. So why did I call this one NBE1? Obviously because I'm going to define NBE2. So we like to see our work as the next step in this evolution. We find our problem with the syntax of NBE1 and we propose a new syntax NBE2 and we give a slightly stronger notion of security which is non-siding AE. So I'm going to go into this now. So maybe let's take another step back and talk about what does it mean to have a cryptographic definition. So perhaps you are aware there are two components to every cryptographic definition, syntax and security. So what's syntax? Syntax is what are the inputs and outputs of your algorithms? Are they randomized? Are they deterministic? That kind of stuff. And so as I showed on the previous slide, we all have the message and the output of the ciphertext and the key and what the syntax should really tell us is what additional inputs your algorithm should be getting. As security, we usually define this using a game and the game just needs to have an adversary. It has oracles and the game decides when the adversary wins and how well the adversary is doing by an advantage function. So let's go into how NBE1 is defined. So this was defined by Rogoay and others. So if we have a scheme SE1, our syntax NBE1 will take a message and produce what we call a core ciphertext. And from this core ciphertext, you should be able to retrieve the message. And the special input we have here is what we call a nonce. So what is a nonce? A nonce stands for a number used once, so it should be any non-repeating quantity. And so in the real world, I guess the most common cases of nonces are random numbers and counters. But you can also see people use things like this sector numbers, packet numbers, device identifiers as nonces, so long as it's non-repeating. And I will draw your attention to the two things in yellow that's very important for the rest of this talk. That we're supposed to be able to pick any non-repeating quantity and that the nonce is given as input to both encryption and decryption. And I'll also make the note that half of AEAD is the AD part, but I'm going to leave that out for this presentation to keep it simple. You can look at my paper if we want to talk about AD. So let's go to a high-level idea of what the security goals are. This is privacy and authenticity. So an adversary without access to the key K should not be able to distinguish the outputs of encryption from random. And it should not be able to get the decryption to return anything but reject. For those of you who like games, this is a picture depicting the game. You see the adversary has access to two oracles and it needs to distinguish between a real world and an ideal world. And idealized encryption should return random strings. Idealized decryption always returns bot. And I will just note that these are the notions of security under which things like GCM and OCB have been proven secure. And of course, to capture the idea of a nonce, we don't let the adversary repeat a nonce to the encryption oracle, but it can repeat nonces to decryption however likes. So now we can get to the main question that motivated all of our research, which is how does this nonce that goes into encryption go over to decryption and go into decryption? And we realized that there's a difference between how it was presented in theory and how it actually happens in practice. So in theory, it looks something like this. It seems like between encryption and decryption, it sort of magically gets there. Maybe they conjure it up on the other side. Maybe there's a wormhole. I don't know. Not mine to judge. But in practice, we haven't really figured out the wormhole yet. So we send it in the clear with the ciphertext. Seems like a simple solution. Seems like it can't hurt, right? Right? So just to give you some idea that I'm not making all this up, these are some quotes from the original Rockaway paper that says that all nonce transmission is kind of outside the model. It's kind of out of band. All right. But if you look at RFC 5116, which talks about how you should implement AEAD, it says, well, send it with the ciphertext. You should be all right. So this is where we get to the title of our paper, which is nonces are noticed, which says that, well, sending a nonce in the clear can compromise privacy in kind of an obvious way. So think about an adversary who gets to pick the nonce and literally sets the nonce to be the hash of the message or sets the nonce to be the first block of the message. There's an obvious idea of semantic security that's being flouted here, but yet our formalization doesn't capture this because the formalization doesn't need to communicate the nonce between the sender and receiver. And even if we don't talk about message privacy, we can talk about sender privacy where nonces are effectively metadata and it reveals information about who the sender is and thereby compromises user anonymity. And you can see this in RFC 5116 again, which recommends that part of your nonce should be made up of a device specific identifier. And this would obviously be able to let an adversary tell which device you're sending something from if you're sending the nonce in the clear. And we will note also that because AE1 and BE1 is supposed to be indistinguishable from random, it's supposed to give you anonymity sort of for free. But if we then go and send the nonce with it, well, you've kind of defeated the whole point. So I guess the natural next question would be, what impact does this have on things like GCM and TLS? Are we completely screwed? No, no, it's not a problem in TLS for those of you who are worried because in TLS, the nonce is not transmitted in the clear. But it may be a problem depending on how you use in other uses of GCM, other uses of other MVE1 schemes because the attack that I sketched on the previous slide kind of can be extended to any MVE1 scheme that chooses to send the nonce in the clear. And so it's not that this problem somehow shows that AE1 security does not hold. It just says that there's a gap between how we thought about it and how it's actually being used. So to fill in this gap, what we did was we want to propose a new definition of a new syntax and a new security definition. And after that, I need to show you how to do it, how to get schemes that achieve this notion of security. So we're going to do this by transforms which take existing primitives like an MVE1 scheme and return MVE2 schemes. So let's do a brief interlude to say that we're not alone in pointing out that this is an issue that needs to be addressed. Shortly after our paper was published, Dan Bernstein came up to us and said that he was concerned about similar stuff when they were writing up the call for CISA. And it was reflected in the call for CISA because CISA has sort of a public message number and a secret message number. And this was actually formalized as AE5. But this is different from our formalization. And Atoll, Dunkleman and Lux used the MVE2 syntax, but they used it to achieve RUP, which was kind of cool. And we think that the future direction of our work would be to extend our syntax to all these other interesting kinds of AE that's coming up and see if sending nonces in the clear causes any problems down the line for any of this stuff. All right, so let's return to our two parts of a security definition and start with the MVE2 syntax. So spot the difference. There's not a big difference here. The difference is that decryption doesn't receive the nonce anymore. It's only an input to encryption and we're going to call this C now the full ciphertext as opposed to the call ciphertext. In particular, this means that if decryption needs the nonce to perform decryption, you need to somehow send it inside of C. And so we have a better way to inspect how the nonce communication is occurring. Let's move on to security. So security is not too different from the initial notion. We basically just extend it to cover the new syntax. So the only thing to note is that decryption now doesn't get n anymore as an input. And the encryption oracle should return a random string that's of a length comparable to the full ciphertext and not the call ciphertext. Okay, so I can move right along to how do we construct these AE2 secure NB2 schemes. And we think that the correct way to do this is by transforms because if we start constructing AE2 secure NB2 schemes from scratch, you're kind of ignoring all the work that has been done to standardize and optimize and prove secure all these great NB1 schemes, not to mention other primitives. So how a transform works is it takes an NB1 scheme SE1 and maybe some other primitives and gives you back an AE2 secure NB2 scheme. It's like magic. It's great. And what goals do we have for these transforms? Our goals are we want to have no ciphertext overhead and we want to have constant computational overhead. So I'll note that for the zero ciphertext overhead, it's not a simple comparison of the length of the core ciphertext and the length of the full ciphertext because that's kind of not a fair comparison. If in usage you're sending the nonce in the clear, what you really should be comparing is the length of the nonce concatenated with the core ciphertext and the length of the full ciphertext. So that's what we're going to define as ciphertext overhead. And this actually makes it slightly non-trivial to achieve AE2 secure NB2 schemes in practice because often nonces are shorter than one block of your encryption primitive, block cipher primitive. So you can't just do the trivial thing of like let's push it through a box cipher and hope it works. Okay. So to give you a flavor of how it works, here's one of our transforms, which I put in a picture over there. So how the transform works is with this equation over here where SE sub hn1 is an NB2 scheme and it takes an NB1 scheme SE1 and a PRFF and it outputs an NB2 scheme. So the basic idea here that's occurring is you take the first block of the core ciphertext C star that comes out of the encryption oracle and you encipher that using the PRF. Then you use this as a masking value to mask the nonce. So this is how and then you mask the nonce and during decryption you can unmask the nonce because you have access to the core ciphertext and you can retrieve what the masking value was. And under this construction, we truly can say that any non-repeating nonce would have been fine because even if you chose the hash of the message or some equally silly nonce, you haven't been masked by this random string and now you're golden. The whole ciphertext looks indistinguishable from random. It's great. So we show in our paper that if F is a PRF and SE1 achieves AE1 security, your scheme as a whole will achieve AE2 security. And just to show you another transform, this one may be a little bit simpler. This one uses a synthetic nonce. So what you do is you encipher the nonce, you get a nonce N2 and you use that with the encryption instead. This is a simpler construction, maybe a little bit reminiscent of SIV. And it's more efficient too because in decryption you don't need to retrieve the nonce anymore. It's kind of sent with it. And you can see some of the trade offs between computational overhead and security here because this one's much more efficient, but the security bound is worse. So let me just sum up all that I have today. So our talk deals with AE1 secure NV1 schemes like GCMO, CB and the CSER candidates. We address a gap that we think exists between formalisms and usage. We want to say that communicating a nonce in the clear is not as fine as it may seem. It violates privacy. And to address this issue, we give a new definition of syntax and security. And we show that it's very simple and efficient to construct AE2 secure NV2 schemes. That's all I have. Thank you very much for the presentation. Are there any questions? Was there a question? People just pointing at each other. Okay, then I would have a question, please. So you said you leave out the details of the AEDs. You said you focus on a version of encryption which doesn't consider associated data. Do you have results about AEDs in your paper? And if yes, can you give a brief overview of what's happening then? Is it the same just AEDs edit or is there more structure happening? Yeah, so in our paper, we treat, our whole formalism has headers or associated data in it. And for the basic constructions that we sort of give here, it's pretty much a natural extension because the header is just given as input to your NB1 schemes. But with our, we also have some advanced schemes in the paper that I didn't talk about here, which kind of extends non-smiths use. And then it gets a little bit more interesting how to fit the header in. Yeah. Okay, thank you. Any more questions? And they aren't back. There's microphones apparently somewhere. Can you? It's okay, I can hear you. Okay. Well, it depends on the model that you're referring to. So I'm not super familiar with which 32 bits you're talking about. But what I will say to that is if your version of encryption covers those 32 bits or nonce, 32 bits, then it needs to, you need to come up with a formalism that incorporates that. Thanks. I have a question. I'm here. Oh, hi. So there are people who want to use some very short nonces. They just assume that nonces do not repeat. But if you transform these short nonce into another nonce in a pseudo random way, you may have some problem with collisions, right? So you need some collision resistance. So are you losing something this way? So it depends on which one of our transforms you use. So some of our transforms will incur sort of like a birthday bound problem, which is something like the last transform I showed. But we also have some transforms that avoid that problem using some other techniques. So yeah. I have a question. Part of your model is that the attacker, the sender is trying to leak data and you're going to stop the sender from leaking data in a world where everybody's internet connected. I don't just don't see the point. So you're saying that what the sender doesn't want to leak data? Well, the sender wants to leak data, he'll put it on the dropbox. I mean, he can't. I understand. And we're not saying that we're not saying that there's anyone out there who is setting the nonce to be the hash of the message or something equally stupid. But even something like counters, right? I mean, that reveals information that is not captured in the model, right? A counter would differentiate between a stream that's sending many packets and the stream that's sending very few packets. Yeah, but there are five fields in the metadata and you're talking about one of them, right? Well, I would argue. I think it's all fine. It's a long discussion. Thank you. Yeah. I was wondering what your constructions had to do with Canetti's paper on generic construction. A lot of what I saw in your slides looked very similar to Canetti's paper that talked about different secure ways to use nonces. I wonder how your work relates to that paper. So like I tried to say in our presentation, we're not trying to claim that these transforms are like somehow new or exciting. And we think that the main contribution of our paper is definitional. But we included the transforms, which makes use of many existing known techniques, which we cite in the paper. Because it seems logical that if you present a definition, you should tell people how to achieve that level of security. So yeah. Okay. Thanks. Okay. Thank you very much.