 And as evidence of just how popular, how quickly this notion became, there were nearly two dozen submissions to the Caesar competition that either claimed online authenticated encryption security or some notion closely related to it, or were claimed by others to possess one of these properties. So my message today is the kind of apolitic one that says that the FFL definition, which I'll call OAE1 in this talk, well, that it doesn't really make a whole lot of sense. And the plan is this. I'll describe what the online authenticated encryption definition actually says and then discuss and criticize it, and then I'll present to you an alternative notion, which seems to me to make more sense. So first of all, let me make clear that I think the goal of online authenticated encryption is a worthy one. Both the property of being online and being non-three-use secure seem to me good properties that we would often like in a scheme. Let me make sure the online characteristic is clear to people what I'm asking for is after some constant delay, as we read in this message bit by bit, we can spit out the corresponding ciphertext, the encryption scheme itself, employing only a constant amount of memory. For the non-three-use part, there already was a decade earlier a definition in the literature called misuse-resistant AE, M-R-A-E abbreviated here, and let me spell out how that notion looks. We imagine an adversary A who possesses a pair of oracles. In the world on the left, the real world, the oracles actually encrypt and decrypt the adversary's responses. There are three arguments provided to encrypt the nonce N, the associated data A, and the plain text M, or over on this side, the nonce, the associated data and the ciphertext. This is what happens in the real-world setting. In the idealized setting, what we ask is that the encryption output look like a bunch of random bits, the appropriate number of random bits, and that the decryption output always return bottom, an indication of invalidity. You forbid the trivial ways of distinguishing these pairs of oracles. In particular, the adversary is not allowed to repeat a triple to the encryption oracle of a nonce associated data and a message. The adversary is allowed to repeat the nonce. That's what makes this such a strong definition. Nonce repetitions are okay. Only the triple may not be repeated. And then, of course, you also have to forbid querying a decryption query of NAC after some prior encryption query of NAM returned C. The intuition behind this definition is that when the nonce does repeat, authenticity is completely undamaged and that privacy is undamaged only to the extent that is inherently unavoidable. In a deterministic scheme, we can't help but releasing repetitions of NAM triples, and that's all that's being released. I'd like to point out, though, that any scheme that meets this definition can't possibly be online. And the reason is very simple. In order to have these two worlds look the same, the first bit of the ciphertext has to depend on the last bit of the plaintext. Otherwise, we'll have a trivial distinguishing attack. So we need to somehow save up the entire plaintext. So Fleischmann, Forleur, and Lux, trying to get around this problem, went to the notion of an online cipher as a starting point. This had been suggested earlier by Bellarie, Boldweireva, Knudsen, and Nonprene Prey. And let me review for you the notion of an online cipher. So this is a cipher. We're deterministically mapping plaintext to a ciphertext, and we assume that the plaintext is a multiple of some block length N. It's important that this notion is parameterized by the block length N. Now we ask that the first ciphertext block depend only on the first plaintext block, the second ciphertext block depend only on the first two plaintext blocks, and so on. So the entire thing is a permutation for each key K, but it has this locality property that we're able to spit out the ife block of ciphertext, having read only the first i blocks of plaintext. We can call o-perm of N the set of all permutations that satisfy the property I just said, and it'll play the role of the reference object in our notion of security. The notion of security will say that the random, that the cipher in question, E sub K, should look like a random sample from o-perm of N. So FFL's definition for a secure online AE scheme, the OAE notion, takes on the following syntax. First, the encryption scheme has an additional argument. The header plays the same role as what I called the associated data a moment ago, and when we decrypt, we output either a string M or an indication of invalidity. The definition assumes that the plaintext has a multiple of N bits for some value N. It's going to build on the online cipher notion and inherits this limitation, that the definition only is sensible for strings that are multiples of some fixed value N. And then what FFL asks is very simple. First, that the ciphertext core that we produce, the same length as the message, and having a multiple of the block size N, that this part resembles an online cipher. As an authenticated encryption scheme, though, there's going to be some additional bits in the ciphertext, and FFL assumes that those additional bits are a tag of some fixed length tau, and they want this tag to resemble a random function. This is the complete definition. So we can define an advantage notion and measure how far off you are of this abstraction rather easily. In the game on the left, you have an honest encryption and decryption article. In the game on the right, you see for each header a random permutation to correspond to what we're doing to the ciphertext core, and we associate a random tau bit tag to this message and that header. Encryption gives that pair. Decryption gives an indication of invalidity. So that's the notion, and I want to investigate it a little bit. And the first thing I'd like to point out is that it's quite weak in the sense that when N is small, there is inherently a way to promote a chosen plaintext attack to a method that will leak the plaintext given any ciphertext. That's easy to see. Let's suppose N is equal to 1. So that means that the first bit of ciphertext is supposed to depend only on the first bit of plaintext. So we ask the bit 0. We have some particular ciphertext we'd like to decrypt. So we first ask for the encryption of the message or any message that begins with 0 and we'll learn what's the corresponding plaintext bit for the first bit of plaintext for c. And we continue in this way, learning one bit of plaintext for each chosen plaintext query and in this manner decrypt the ciphertext c using a number of queries which is the length of c, a number of encryption queries. It's certainly highly atypical that a chosen plaintext attack immediately implies the ability to decrypt any ciphertext. You could conclude from this that we need a large block size N to have any meaningful kind of security. One bit won't do, but maybe 128-bit block size, for example, will still give you a reasonable notion of security. You certainly won't be able to mount this kind of attack. But that isn't true and I think I won't spell out this attack in full. But if we suppose that we have the ability to prefix any string we like by a chosen plaintext, any secret string s by a chosen plaintext and then obtain the ciphertext for this string, the chosen plaintext and the secret suffix s, then this ability will once again give us the capability of decrypting the ciphertext c using a small number of encryption queries and the attack does not depend on the value of N. It works for any value N. And what we do here just follows quite directly the beast attack that I'm sure many of you have seen. One can conclude from this that OAE-1 is a somewhat weak notion, but perhaps that's implicit in any notion of authenticated encryption and it's simply allowing us to understand and refine our intuition for what online authenticated encryption can achieve. But I think the problems with the OAE-1 notion actually run much deeper. First of all, this block size N. When we look at a scheme that is offered to achieve online authenticated encryption, the value N is chosen by the cryptographer according to the structure of the scheme. It's typically a value like 64, 128. But the intuition that we're trying to capture is that the user has some amount of latency that he's willing and capable of tolerating and this has nothing to do with that which has been convenient for the cryptographer's design. So there ought to be a separation between the latency that a scheme allows and that which was convenient for the scheme to implement from some underlying tool. The resource constraint of the user in particular, this shouldn't be coalesced with the block size parameter N. Secondly, the security definition needs to explicitly indicate what happens on strings of any length, not just those that are a multiple of N. Saying that in an actual scheme we will add plain text just begs the question, you still need a definition for what security notion you're achieving for arbitrary strings. Next, I would question the utility of making encryption online but levying no similar demand for decryption. It would seem a very bizarre situation in which a party lacked the ability to buffer up an entire plain text before acting on it but had the ability with respect to ciphertexts and that's effectively what's demanded in the 081 definition. And finally, I'll say that this reference object that we dreamed up isn't ideal. Why should we imagine that the encryption scheme had the format that blocks get mapped to corresponding blocks and then there's a tag at the end? Mightn't we be able to do better by not assuming this particular structure in a scheme? So to get around these, I need to change the basic syntax of an authenticated encryption scheme. Instead of saying that there's some fixed parameter n to which m is partitioned into blocks of that size, I'm going to say that the message m that we're dealing with gets partitioned however the user wants it partitioned. You could think of this as being a kind of API directed definition. The user makes a first encryption call providing a message block m1. It can have any lengths. Later, he'll make another call providing the next block m2 and so on. Wanting the scheme to be online means that when the message m1 is presented, we need to spit out the corresponding ciphertext block c1. Furthermore, m1 should be recoverable from c1. Next, when m2 is presented, we produce the corresponding ciphertext block c2. To keep things simple, I'm going to assume that each ciphertext block has a length which is some number of bits tau more than the corresponding plaintext block. At the very beginning, we need to process the key k and the nonce n, and so encryption then requires this entire tuple of algorithms, an initialization scheme, a next scheme to tell you what to do when you receive the next chunk of plaintext, and finally some kind of finalization procedure which should be distinguished from these because the end of a message is somehow different from prior blocks of the message. Decryption recovers the corresponding plaintext piece by piece. Let me indicate what we expect to be happening if one of the ciphertext blocks should be corrupted. We intend for the decryption algorithm to recover an indication of invalidity, and once that invalidity has been recognized, all subsequent blocks should likewise be declared invalid. Finally, let me throw in the role of the associated data. If the message has been regarded as a vector determined by the user, it seems to make sense to regard the associated data in the same way. This general approach to thinking of the message as a stream to be partitioned up by the user has appeared in earlier work, in particular I'd call your attention to the duplex construction which described the task that they were trying to accomplish very much in these terms. Here then is the syntax, and I'll skip over the further details. We want to formulate the security notion that sits on top of this syntax, and the paper actually offers three different definitions. The first, what I'll regard as the basic scheme and that I'll give you a sense of, captures that which OAE 1 often claimed it was trying to capture. Best possible security, even if nonces should happen to get reused. At the other end is the security notion that treats this segmentation of messages as the important change we've made for dealing with online authenticated encryption and disentangles the nonce reuse question from it. Nonces are still assumed to be used as nonces, used at most once. In between these notions is the idea from the sponge paper, which I don't have time to describe. So I'm going to sketch for you what this OAE 2 notion, the strongest of these three notions, looks like. Here is the message M segmented by the user into these possibly varying size chunks, the nonce N that corresponds to it. You've got to spit out a ciphertext C1 as soon as you've seen the first chunk, M1. And furthermore I told you that we were going to assume that the ciphertext is some number of bits tau longer than the corresponding plain text block. So the best you could hope to do would be to emulate a random injective function that expands by tau bits. It has to be injective because we want to be able to decrypt. In processing the next block, M2, the best we could hope to do would be to emulate a random tau expanding function that now depends on the nonce and the prior block M1. And we continue in this way. At the very end I warned you that the last message block is somehow different, and therefore we ought to treat this function here again as separated from the others. The associated data isn't shown in this picture. You would add in the dependencies A1, A2, A1, A2, and so on. So that's the basic security notion. Here it is written out as a game. The ideal online authenticated encryption corresponds to the process I just described on the last slide. And you have to be careful in defining the corresponding decryption oracles behavior. The way this is done is to return to the adversary on a decryption query the longest prefix that is judged valid with respect to the ideally chosen function F. The definition I've just described, we capture in multiple different ways. They're effectively equivalent, and by defining it in multiple different ways, we get to explore the space of what effective equivalence actually means. So the first definition, the one I just described, is roughly equivalent to a notion in which each of the ciphertext blocks is declared to be a randomly chosen string. And we can explore how close those two are as a function of the expansion of the value. In between these two is, again, the stronger notion where we capture more directly the adversary's ability to grow the plain text incrementally, to ask a message M1, get the corresponding ciphertext C1, and to use it in the formation of the next chunk, M2, and so on. Here is a scheme that achieves the definition that I've just described. Our sense is that online authenticated encryption is not a goal for which you should try and come up with a basic primitive in the sense that Caesar submissions did, but rather that we achieve a high-level authenticated encryption scheme and build an online authenticated encryption scheme out of it. So here is a recipe for creating an online authenticated encryption scheme out of a misuse-resistant authenticated encryption scheme when tau is large or what we called in the last Eurocrypt paper a robust authenticated encryption scheme for a general value tau. The constructions seem straightforward, but I'll mention that in the absence of this plain text XOR, it doesn't work. This scheme is somehow close to what Netflix is doing as they stream messages across to your client. They don't use a robust authenticated encryption scheme, but a more conventional authenticated encryption scheme, and this works for achieving that non-spaced authenticated encryption variant of the definition that I just showed to you. I need to wrap up. Let me conclude that, first of all, it was a kind of odd coalescing of misuse-resistance as a deciderata and the online property. These two things really had nothing to do with each other, and I think it's just historical artifact that the two goals were bundled together and in a way which made us, in some ways, not see what online authenticated encryption really should be about. I would say my own sense in evaluating the myriad of CSER candidates is that claims of OAE-1 security should effectively be ignored. It's really not achieving a notion that seems very useful or desirable. I've comment about the odd escalation in rhetoric that we've seen in this domain. So the FFL paper was reasonably measured in its language. It didn't say in particular that we don't need nonces anymore. It tried to say that here's a reasonable thing that we could do when nonces do repeat and we want our schemes to be online. But in the couple of years that followed, stronger and stronger claims were made, often about the very same definition until in the most recent papers, it was even called nonce free and described as though if you have a nonce use it, if you don't, you'll protect it anyway. The technical definitions never guaranteed anything like that. And finally, I would say it seems to be a kind of odd social phenomenon that a definition that really is quite obviously flawed should so quickly become, should become very popular. And I think the rhetoric surrounding the notion was an important factor in making that happen. I think we need to view our definitions skeptically and make sure that that which we're saying about them corresponds tightly with that which is actually guaranteed technically. Okay.