 So, welcome to the second session of Real World Crypto this year on symmetric cryptography. My name is Bart Pradil and I have the honor to share this session. Can you please take your seats? So the first talk is an invited talk. It's entitled, Attacks Only Get Better, the case of OCB2, a talk to be given by Tetsu Iwata. Thank you, Bart, for the introduction and welcome back from the coffee break. My name is Tetsu Iwata from Nagoya University in Japan, and I'm going to talk about OCB2. This is joint work with Akiko Inoue, myself, Kazuhiko Minematsu, and Belotron Potry. The work was presented at Crypto last year, and the full version was posted on the ISCLE print archive. So this is a penguin, a famous one. Let's assume that we want to encrypt this image with the ECB mode of a block cipher. So we have a block cipher, EK, here, with N-bit blocks, and the image of the penguin is broken into blocks. It runs through MM here, and they encrypt it individually, and we obtain the cipher text. The result looks like this, the ECB penguin, and we vaguely see the shape of the penguin. So the ECB mode has issues. One issue is that if we have two identical message blocks in one message, then they are encrypted into the same cipher text blocks, meaning that if we have two same colors, then they are encrypted into the same color. And this is the reason why we see the shape of the penguin in the cipher text. The other issue is that if we encrypt the same message twice, then we will have the same cipher text twice. So if we encrypt this image today, we will see this cipher text, and if we encrypt the same message again tomorrow, then we will see exactly the same penguin tomorrow. One more issue is that it doesn't provide authenticity of data, meaning that if the cipher text is manipulated, there is no way to detect the manipulation, and the cipher text is just decrypted into a wrong plain text. And in order to securely encrypt and authenticate data, we need to use an authenticated encryption scheme. An authenticated encryption scheme is a symmetric key primitive for privacy and authenticity. We are interested in the nonce-based configuration of authenticated encryption formalized by Rogaway, and the nonce is the data that is changed for each encryption. So for instance, it can be realized by a message counter. On the formalization, there is a concept of associate data that is not encrypted but authenticated, and this talk, we will not consider associate data for simplicity. Now Alice and Bob share a secret decay, and she wants to send a message M to Bob. She uses a nonce N to encrypt the message into the cipher text and attack, and the tuple of NCT is sent to Bob. Bob decrypted into the original message, or he outputs an authentication error symbol, or the reject symbol, if he believes that this is not originated from Alice. So this is a functionality of authentication. There are many A schemes. We have GCM and CCM from NIST recommendations. There are six schemes in the ISO standard. IETF, RFC includes GCM, Chacha 20, Poly 1305. There are six schemes in the CISA final portfolio, and there are many schemes proposed to the ongoing NIST lightweight crypto standardization project. The first version of the codebook mode is an authenticated encryption scheme. There are three versions. The first version was proposed by Rogaway at all at CCS 2001. The second version was proposed by Rogaway at Asia Crypt 2004. And the latest version was proposed by Kravitz and Rogaway at FSC 2011. They are all NIST-based AE with associated data with strong features. They are fully parallelizable. We can encrypt one block cipher. It needs one block cipher code to process each end bit block, which means that the efficiency is very close to the encryption mode, only most like counter mode or the ECB mode. And they have proof of security. All versions of OCB have been extensively studied, and they all have security proofs by Rogaway at all, and there are many third party analysis. And no weakness is known, and the security is very well understood. And I have a question mark. For results, we point out structural weakness of OCB2, the second version. The weakness is independent of the block cipher and its block size. And this has been overlooked for the past 15 years. We present many attacks, authenticity attacks and privacy attacks, and all attacks are very efficient, and the success probability is very close to one. About the practical impacts, OCB2 was one of the six algorithms in the ISO standard, and they decided to remove OCB2 from the international standard. SJCL JavaScript library implements OCB2, and users may be affected, but we are not sure if users really use OCB2. We informed the issue to the team, and we didn't hear anything from them, but we understand that fixing crypto is not easy and time consuming. This is a multi-platform application for taking notes, and it uses OCB2, and they decided to wait for the decision by the SJCL team. So let me go into the technical details of OCB2. We want to encrypt, announce, and the message into the ciphertext and attack. So starting from this ECB mode, we have announced, and the first thing to do is to encrypt and announce into L. So we have L here. L is not the part of the output, but we use L to generate masks, and we apply the mask to the input and output of the block cipher. We keep doubling the mask, and this doubling is slightly different from the usual integer doubling, but the most important difference is that we use XOR as the addition, instead of the addition over the integer. Now we see that even if M1 and M2 are the same, C1 and C2 will be different because we have masks, and this means that we will not see the vague shape of penguin in the ciphertext. And even if we encrypt the same message twice, we will see different ciphertexts because we have to update, announce, and the mask will be different. So the issues of ECB are now gone, and this last message block is a little bit different if we go back. This last message block goes to here. And the last message block is encrypted in a counter mode. So we compute the big lengths of the last message block, apply the mask, encrypt it, and we don't apply the output mask, and we have the ciphertext block. This is the checksum, which is the XOR of all the message blocks. We apply a special mask, which is multiplied by 3, and we have the tag. How we decrypt a couple of NCNT, we first compute the value of L, we now can compute all the masks, and we compute the block cipher in the inverse direction. Now we have these blocks, and for the last block, we decrypt in a counter mode. So we compute the block cipher in the forward direction to obtain mm. Now we can compute the checksum, and we see if this matches with the received tag. If the equality holds, we have the message, it's returned, otherwise the reject symbol is returned. There is a theorem showing that the ciphertext and tag looks like a random string, meaning that the encryption is secure, and it says that forgery is not possible, meaning that it is secure in terms of authenticity. And this theorem was believed to be true until Inoue and Minematsu announced a surprising attack against OCB-2. The simplest attack is called a mini-malifusory, and let me explain how it looks like. So Alice has a message M, and this M has to be a specific form of two blocks, and the adversary has to know the content of the message. Let's assume that this is the case. She encrypts the message and sends NCT to both. This is a public channel, and the adversary learns NCNT, and at this point, adversary can create NC prime T prime that is not generated by Alice, but Bob accepts this as authenticated by Alice and returns a message M prime. This is called an existential forgery. So meaning that this forged message probably means nothing, but still this is something that was not generated by Alice. So let me explain a little bit about the details of the minimal forgery. I think this slide is too technical, but let me try. If you don't follow this, that's fine. I hope that you have already got the high level idea of the minimal forgery. So the first step is the adversary let the victim Alice to encrypt N and M, where M has two blocks, and the first block is the length of the N-bit to the N-zero bits. So we have N-zero bits here, and M2 is anything provided that it has N-bits. Now C1, C2, and T is sent over the channel, and the adversary creates NC prime T prime, where C prime is a one block ciphertext, which is C1 X-row length of N-zero bits, and the tag T prime is M2 X-row C2. And surprisingly, this will be accepted by Bob, and let's see why this happens. We first see that this is the last ciphertext block. So this we compute the forward direction of the block cipher to decrypt it. And we see that these two red points are the same, meaning that the decrypted message M prime should be 2L X-row the length of N-zero bits. And because we only have one block in the message, this directly becomes the checksum. Now this 2L X-row 2 times 3L is 4L, because we are using X-row as the addition, meaning that these two blue points are the same, and the output here is indeed M1, M2 X-row C2. So this T prime here is indeed the correct tag for this ciphertext C prime, and Bob will accept it as valid. And finally, this is returned. This probably means nothing, but still L can be used to reconstruct all the masks, and this can be used for more powerful attacks. And indeed we have a lot of other attacks. We can forge longer messages. We now have a universal forgery, a distinguishing attack, and a plain text recovery attack. We can also simulate the encryption and decryption of the block cipher, even though we don't know the secret T. I will not describe the details how we do these attacks, but let me show you how they look like for some of them. This universal forgery attack, in the minimal forgery, the attack forges this M prime, a message of this particular form. And this problem means nothing, but in the universal forgery, for any nonce and message, possibly chosen by the adversary, the adversary can create the corresponding ciphertext attack that will be accepted by Bob. So the adversary can send NCT to Bob, and Bob believes that this was generated by Alice. We use the minimal forgery as subroutine, so we still require Alice to encrypt some specified message, but still this is the worst authentication attack, because this could be chosen by the adversary, and it can be malicious contract documents, or it could be a harmful code if Bob is a program. And this should be avoided if we use an authenticated encryption scheme. A plaintext recovery, it's an attack in terms of privacy, and here we have a message M, which is not known to the adversary initially. Alice encrypts it into CT and sends NCT to Bob. Now by using the minimal forgery as a subroutine, the adversary can recover the entire content of the message. So it means that OCB2 does not have the functionality of encryption. All right, OCB2 has a proof of security, and we have this list of attacks, and let me explain what went wrong with the proof. So this is OCB2, and the technical specification of OCB2 is complex for direct security proof. So to prove the security of OCB2, the proof uses abstraction of OCB2. So we just put these structures in boxes, and we now have this abstracted version of OCB2. If this red box is this structure, this is called XCX because we have X-Roll, Encrypt, and X-Roll, and this blue box is this structure which we call XE because we have X or Encrypt, then we have OCB2, right? This is how we define reds and blue boxes. If the red box is Pi1, which is the ideally secure version of XEX, and if the blue box is Pi0, which is the ideally secure version of XE, then we have something different, and let's call it ThetaCB2. So there are three steps to prove the security of OCB2. The first step is to prove that ThetaCB2 is secure. So we focus on this construction where we put the ideally secure versions, Pi1 into the red box and Pi0 into the blue box. And this part works fine, and the next step is to show that for any tag-respecting adversary, XEX construction looks like the ideally secure version, and Pi0 and XE looks like the ideally secure version. We need some assumption in order to show this indistinguishability because you see that if we give exactly the same input to this one and this one, then this value here will be here, and the adversary can compute the value of L, and with the knowledge of L, we can do a lot of attacks. So we need some condition in order to show this indistinguishability, but as long as the condition is called a tag-respecting condition, and as long as we consider an adversary that respects the condition, this indistinguishability holds, so this is fine. The final step is to combine these two results to conclude that OCB2 is secure, and this step is called a hybrid argument. So what we do is to consider an adversary attacking thetaCB2, and we know that the attack doesn't succeed because this is a secure construction. And now we substitute Pi1 with this structure, XEX, and Pi0 with this structure. If this indistinguishability holds for any adversary, this adversary will not notice the substitution, and we can conclude that OCB2 is secure as well. However, it turns out that this adversary can force violating the tag-respecting condition, meaning that this indistinguishability result doesn't hold for this adversary attacking thetaCB2 because XEX and XE are misused, and this is exactly the point where the security proof of OCB2 failed. So a lesson learned here is that we have to prove all the statements. This part is fine with OCB2, and we also have to carefully check that they fit together nicely. And this was not the case in OCB2. There are some ways to fix OCB2. We can change the definition so that we use XEX for the last message block, and we have a proof of security for this fix, and we can also change the definition of the mask. And this will... We have a plan to include this in an A-print soon, and we also have some potential un-proof options. And of course, it is reasonable to avoid using OCB2, and we could, for instance, use GCM or OCB3. Okay, a little bit about the timeline. OCB1, the first version was proposed at CCS2001. The second version was proposed at Age of Crypt 2004, and OCB2 was included in the ISO standard in 2009. The final version, the latest version was proposed at FSE 2011, and it is included in IETFRFC in 2014. And it was 14 years since the publication of OCB2 when Inoue and Minematsu found a potential gap in the security proof. They studied the OCB2 paper for the educational purposes and for searching potential improvements in OCB2. They noticed this gap in the proof, and initially they tried to fix the proof because they believed that OCB2 is secure. After a month, the fix didn't succeed, and they came up with the minimal forgery. They finished writing the paper in two weeks, and this was sent to E-Print, and the initial version contained minimal forgery, extension to longer messages, almost universal forgery, and it pointed out a gap in the security proof, and it proposed a fix of OCB2. The analysis by Inoue and Minematsu focused on the authenticity, security, and Belgium potring. He noticed that privacy is also an issue. He presented a distinguishing attack two weeks after the publication of Inoue and Minematsu's work, and this means that the ciphertext of OCB2 does not look random. And I read his paper and I noticed that full plaintext recovery is possible. I finished my paper in two days and sent it to E-Print. A lot of interesting findings in the next couple of days, and the security of OCB2 has gone. So we discussed and decided to write a joint paper. So there was an exciting competition involving multiple teams from industry and academia, from NEC, Nagoya University, IBM, and Royal Holloway University of London across different corners in the world, and it took a long time until the first finding of the potential gap in the security proof. But after that, everything happened in a very short period of time. So there is a saying that attacks only get better. I think this was popularized by Bruce Schneier, quoting a word from NSA. For the case of OCB2, attacks got better and powerful very quickly, very quickly to conclude. OCB2 is broken, and I think it's fair and reasonable to say that OCB2 should not be used in any applications. And a seemingly small flaw and the security proof led to surprisingly powerful attacks. And I'd like to remark that our attacks do not apply to OCB1 and 3 because they do not reuse XCX and XC. And I'd also like to remark that the general structure of OCB is still sound. I mean, this abstracted version of OCB is still sound. And lessons learned, yes, even the most promising scheme can fail and active third-party verification of security proofs is very important. That's my talk. Thank you very much. Any questions for Iwata-san? So maybe I have a quick question. Do you think that using automation could have solved this problem or verification of proofs by tools? Would that have helped in this case? Thank you for asking. I think verification tools still need under development. I think it is useful to analyze the security of the abstract version. Verification tool can prove the security of this level of a scheme, but I think we still need some time until we see that the verification tools can handle all the details in the scheme. So I'm not sure if the current verification tool can find the flow in OCB2. Okay, if there's no further question, let's thank Iwata-san for his talk. The second and final talk of this session is entitled All on Deck, and it's a talk submitted by the Ketchak team. The Ketchak team consists of Johan Dahman, Seid Hoferd, Michael Peters, Szilvanas and Honi van Kier. Unfortunately, Michael Peters and Honi van Kier cannot make it to give the talk, but the other three will do it. Bart for this nice introduction. Also, thanks to Iwata-san who gave excellent introduction to what we will talk about here, that I can go a bit faster over certain slides. So yes, this is a talk about Symmetric Crypto, basically what the Ketchak team has been doing the last couple of years. So you see the usual name, so Mikael Gyl here today, myself. This is how you write my name, actually. I have the honor to introduce you, Seid Hoferd. So it's a person here from US, Nebraska, who sent us some mails a few years ago, and he had very relevant comments and very good remarks. He found, I think, somewhere a minor flaw in the specification of Ketchak, and he sent a few very interesting mails, and then we decided to incorporate him into the team. But we never met, we always were communicating by mail and git and so on and a conf call, so we met him yesterday for the first time, and he will now help us present this thing. So I will give Seid the scene, then Seid will speak about modes of our newly proposed function that's called the deck function, hence the title, and Gyl will talk about how to build a deck function. So, yeah. What we want to do is Symmetric Crypto, and we kind of highlight authenticated encryption in this talk. So it's thanks to that, so you all know what that is. We look at more like a generalized version where there is a message consists of plain text that needs to be encrypted, and associated data, that is data that should also be authenticated, but not encrypted. So the message is plain text associated data, and you encrypt a cryptogram consisting of the encrypted plain text, which is the cipher text, the associated data and attack. And this is done under a secret key that is shared by a supplier that should be announced. Okay. So how is that typically done? Nowadays, like a good example of this would be OCB2. It's a two-layer approach where first you build an N-bit block cipher, like AES for instance, and the goal of that block cipher is that if you instantiate it with a secret and unknown key that is uniformly selected from the space of possible keys, it should behave like a random permutation. So a permutation, a random permutation is kind of a theoretical idea that you could select a permutation from the space of all possible N-bit permutations. And we can quantify the security of a block cipher by specifying the advantage of distinguishing the block cipher from such a permutation by an attacker that could query the thing or what it is. And the N corresponds to the number of queries he can make. So it's kind of the data complexity of an attacker, the data resources he has. And N is the computational resources. And we generally assume this epsilon, this distinguishing advantage to be very small. We cannot prove it small, but we can rely on a cryptanalyst to show an attack. An attack would be something that this is not small, so a practical attack or a theoretical attack. So we cannot prove it, but we can rely on a cryptographic community to try to break it and as time goes on we get more confidence. And then we build actually a mode that uses a random permutation and there we can actually prove a bound. So that would be like ocb2, ocb, you can, oh the data cb, you can prove a bound based on the, it's like probabilistic bound based on the randomness of the random permutation. So that's really something rigorous that you can prove with probabilistic techniques, while the block cipher you can only assume it's okay and account on public scrutiny. And then you instantiate this mode with a concrete block cipher and by the hybrid argument or the triangle inequality you get that the breaking probability is upper bound by the sum of the two epsilon, the two advantages. The one in blue, so it's the one you can prove, and the one in red is the one you can only rely on by public scrutiny. So that's how it works. So this has a number of problems. So the first problem is that sometimes these modes are quite complex most of the time and computer scientists may trip over them. And I think the previous talk gave a good example that the complexity of the mode didn't help in getting the proof correct. But there are many other examples. The second is the birthday bound. So as soon as the amount of data that you encrypt with a given key approaches 2 to the power n divided by 2 where n is the block length, you get into trouble. And for triple this is 32 gigabytes. So it's a lot, but not astronomical. And you can have a look at the site on sweet 32 attack for some discussion. So it's a very interesting site. For AES, it's quite far away. That's 2 to the power 64 blocks. But it still kind of stands in the way of when you want to claim 128 bits of security. These 2 to the power 64 is kind of annoying. So it would be nice to get rid of it. The third point is that actually it's more philosophical is that block ciphers address not necessarily correct design goals. So first of all, when you build a block cipher, you want to make the inverse operation, so in ECB when you uncover the penguin again, you want to make that efficient. While many modern modes don't use it, you build a block cipher to be PRP secure, so to be hard to distinguish from a random permutation, but what most modes really want is to be hard to distinguish from a random transformation, PRF. And the modes have actually a high complexity because the block cipher is fixed length and the messages are variable length. So let's take a look at what we can do about it and there's 2 directions. But first I need to look at what looks block cipher how it's structured. Basically it's an N-bit permutation, parameterized by a side input key. So you can actually depict it like this. You get this block cipher in the middle, the data path and this is where the key comes in. And the encryption data path is just iterating a simple round function and each round typically takes a key or a key is injected every few rounds and that comes from a key schedule. So how could we make it turn this into something more useful? Well one way of doing it is by adding a side input. So we extend the block cipher to a so-called tweakable block cipher and then we get this image. So in comes the key, the data in data out key tweak. And that gives you a permutation parameterized by the joint key and tweak. And this tweak is very useful because it allows you to simplify mode. So if you would do ECB, you could just use a different tweak for each block and the ping-ring would be invisible because you basically encrypt each block with a different permutation. And also making this tweak unique per call avoids the birthday box. So that kind of solves the issue. But of course it makes your block cipher also a more complex function. The other direction is trimming the block cipher. So we dump the side parameters which means we dump the key, we dump the tweak. Well it wasn't there on the block cipher in the first place. And it gives us a B bit permutation that you get this no side input just straight ahead. So this moves your birthday bound to 2 to the power B over 2. You can say well if B is N you don't win anything but you can make actually B larger than N for the birthday box. And you have to deal with the key one layer up. So I want to thank Bart Menning for coming up with this idea of traffic science. So what does permutation-based crypto look like? Well at least for keyed constructions. Now the two-layer approach of block cipher-based crypto is replaced by a three-layer approach. First we build the permutation, just a simple wrong function that we iterate. And then we have a new kind of primitive which I will for the moment call FK on top of it. And this new kind of primitive has arbitrary length input and output. And so more properties. And then you try to build it in such a way that distinguishing it from random oracle is hard. So it has a very small advantage. And the assurance is again built on public scrutiny. So on crypto analysis. So the crypto analysis in this case is not applied to the permutation. It's applied to the construction taking a particular permutation. And then we build a mode on top of a random oracle. And often these modes are so simple that the bounds for the proof becomes trivial. And finally the security we get is just again the sum of the two epsilon. So now as Seth will explain how we can use this kind of function to build useful modes and then she will explain how to build such a function. So what is this new mysterious kind of primitive that Yone was referring to? We call this a deck function. Deck function stands for doubly extendable cryptographic keyed function. Deck function accepts as input a sequence of one or more variable length bit strings and returns as output a variable length bit string. Now this output string has the property being a pseudo random function of all the input strings. In other words it behaves like a random oracle. And as far as notation and terminology goes we say that we input strings X1 through XM into the deck function requesting n bits of output starting from offset Q. Deck functions are incremental. This means that if you calculate a deck function for string X and the later over string X strings X and Y you can reuse the contribution of string X. You need not pay for X again you just have to pay for string Y. You say pick up or you're left off essentially. This applies to the output as well. So if you request n one bits from offset zero and then from that point forward request n two additional bits you don't need to pay for those n one bits from before you just pay for the additional bits again picking up or you're left off. We believe that the deck function abstraction is the ideal abstraction for building a very wide range of keyed symmetric crypto modes. And this seems like a bold claim. How do we go about doing this? Well let's start simple. So stream cipher for example. So we can see here we simply take the non-string input it into the deck function and request as many key stream bits as needed to encrypt the plain text and obtain the cipher text. Pretty simple. How about a message authentication code? In this example we simply take the message plain text input it into the deck function and request as output the t-bit authentication tag t. So these modes were simple to implement on top of deck functions thanks to the fact that they support variable length input and variable length output. But what about something more complicated such as an authenticated encryption mode? This takes us to deck scene. Scene stands for session authentication non-spaced encryption. The central idea behind this mode is to exchange a sequence of messages between a sender and a receiver calculating an authentication tag after each message. Each authentication tag actually authenticates all of the messages up to that point in the session. And so if any message is dropped, reordered, duplicated or tampered with in any way, the authentication tag won't match. You can detect this and then drop the session immediately. In addition we support the notion of a startup tag t0. This tag authenticates the key non-spare that was used to initialize a session. And so the nice thing about this is that if, for example, an adversary tries to initiate a session with a server, the adversary hopefully doesn't know the secret key and therefore cannot calculate the tag correctly. The server can then terminate the session immediately before any data is encrypted, thereby saving precious server resources. But how do we actually implement a mode like this on top of deck functions? So diving into it, we initialize a session by taking the nonce n inputting it into the deck function and requesting a t-bit startup tag t0. To encipher a message, we first start by requesting key stream bits from the deck function immediately following the tag from the previous message encrypting the plain text and obtaining ciphertext c1. We then authenticate the metadata and ciphertext strings by inputting them into the deck function and then request a t-bit authentication tag t1. Now I'd like to note here that thanks to the incrementality property of deck functions, we're able to actually reuse the contribution of all the past messages into the deck function which at this point is just the nonce, so we don't have to pay for that string input again, we just reuse it. And this is really what makes the session mode work. So to encipher another message, we again request key stream bits immediately following the tag of the previous message encrypting the plain text and obtaining ciphertext c2. And then we authenticate the metadata and ciphertext strings by inputting them into the deck function and requesting the authentication tag as output. Again, we can see that we get to reuse the contribution of all the previous messages for free here. One thing to note about this mode is that it is a nonce based mode. So this means if you reuse a nonce, then key stream gets reused, which leaks information about the plain text, so obviously don't reuse a nonce, but this begs the question, is it possible to design an authenticated encryption mode that is robust against nonce reuse? And the answer is yes. That takes me to the next mode, which is deck stance. This mode stands for session authentication synthetic nonce encryption. To encipher a message in this mode, we start by authenticating the metadata and plain text strings by inputting them into the deck function and requesting tbit authentication tag t1. And then we calculate the key stream as a function of the metadata and the authentication tag. And then we're encrypting the plain text and obtaining Cypher text c1. So again, I'd like to note here that thanks to the incrementality property, we need to only calculate the contribution of metadata string a1 once in the authentication tag step, and then we can reuse that contribution in the key stream step. This benefit will become apparent in the next message. So to encipher the next message, we again authenticate the metadata and plain text strings, obtaining as a function of the metadata and the authentication tag, obtaining Cypher text c2. So the important thing to note here is that the authentication tag material and the key stream material are actually functions of not only the current message, but all of the messages up to this point in the session. And one benefit of this is that even if you have a pair of tags that collide, but if you do have a pair of tags that collide between sessions, then as long as the histories are unique, then the key stream will be unique as well. So it's kind of like an additional diversification of an extra layer of security. And then we repeat this process as many times as needed for as many messages as we wish to exchange. So one thing important to note about SIV-based modes or SIV-like modes in general is that they don't give you optimal expansion. So for T-bits of security, you'll generally need to use a 2-T-bit tag. And in addition, neither this mode nor the previous mode are robust against the release of unverified plain text from the decipher oracle. So meaning your decipher oracle absolutely needs to verify the authenticity before releasing any plain text. It can't leak any information out about the plain text. So this begs the question, is it possible to design an authenticated encryption mode that is robust to non-free use, robust to release of unverified plain text from the decipher oracle and offers optimal expansion? And of course the answer is yes. This takes me to the final mode, DECWBC. So this is a tweakable wide block cipher built on top of DEC functions and a FISETIL network configuration. And one of the nice things about this mode is that the first and last rounds need not be full-blown pseudo-rented functions. They need to only be differential uniform. In addition, they need to only output a single block. So as a whole, this mode performs two read passes and one write pass over the data, making it pretty efficient for what it gives you. I mean, this is great because it gives us a variable with block cipher, but how do we build an authenticated encryption mode on top of this? So the sender takes the message plain text, appends some kind of verifiable redundancy to it, runs this through the wide block cipher, obtaining the cryptogram. The receiver takes the cryptogram, runs it through the reverse direction of the wide block cipher, obtaining the plain text with the redundancy attached to it. And then the receiver validates that the zero bits are intact. And if so, the message is authentic. And we handle the metadata by plugging that into the tweak input of the block cipher. So if metadata is tampered with, the mapping of the block cipher changes, and inevitably the redundancy is damaged. This mode gives us robustness against nonce reuse, robustness against release of unverified plain text from the decipher worker, and it gives us optimal expansion. So this means that for t-bits of redundancy, you'll get t-bits of authenticity in general. Not only this, but we can actually take advantage of redundancy that may already be present in the plain text. So if you're in ciphering network packets, for example, you may have a 16-bit checksum available to you, in which case, as long as you validate that checksum in the decipher worker, you've just achieved 16 bits of authenticity. So this mode is very powerful, very robust. And now, Gilles, we'll talk about how to build deck functions. So I will briefly explain two ways to build a deck function. Both ways are based on permutations. The first one is more serial approach, and the other one is a parallelizable approach. So for the serial approach, we base ourselves on the keyed duplex construction. And so as a refresher, we start from the sponge construction, which is used in Ketchak industry. And then the duplex construction is kind of a dual of a sponge construction. It's graphically equivalent to sponge, but we add incrementality. So we can add input blocks and get output blocks all the way. Then part of the input can be a key, and then we move to the keyed version. So concretely, the key duplex object looks like this. We have a state that has the same size as the permutation, and it's initialized with the secret key. So between the application of the permutation, we can get a block of output, and we can absorb a block of input, and we can repeat that as many times as we want. So as such, it doesn't give us a deck function because of the restrictions on the input and output sizes, but we can easily put a thin layer on top of this and then expand it into a full-blown deck function. One example is a stroke framework by Mike Hamburg. As soon as you initialize it, then it can implement a deck function, and the same goes for our submission to the next slide with crypto competition called Zodiac. Another way is the parallelizable approach, and for this we rely on a farfale construction. So the farfale construction looks like this. I'm not going to go into the details. I just wish to point out that it has a secret key input and an input made of blocks, and all these blocks will be treated by the permutation in a way that they can be vectorized. All these permutations are computed at the same time, so you can have a significant speedup by having a vectorized implementation. And the same goes for the output. You can also compute all these permutations at the same time. So we instantiated the farfale construction with two concrete deck functions. The first one is called Kravate, which is take the farfale and plug in the Ketchak permutation. Just we reduced it to six rounds. This gives us a deck function for which we target a security of at least 128 bits, and that includes also adversaries equipped with a quantum computer. I will give some performance figures for Kravate, so it's quite fast, but one of the disadvantage of Kravate is that it has a block size of 200 bytes, which is quite big. So we wanted to reduce this block size, and we designed, sorry, the Zoodoo permutation. So the Zoodoo permutation is a 384 bit permutation. It can be represented as 12 words of 32 bits, so that fits nicely in, for instance, the registers of an arm processor. So it's the size of the Gimli permutation, but with the design philosophy of Ketchak. And Zoof is the deck function built on top of Zoodoo. So we, again, target 128 bits of security for Zoof, as far as adversaries, I don't know many of them, but for those adversaries who have a quantum computer, in that case we target at least 96 bits of security because it's a smaller permutation. So I promise to give some performance figures, so Kravate on the Skylake processors. On the Skylake processor, Kravate is slightly faster than the AS in counter mode. Bear in mind that this processor has the AS-NI permutation, so it has a hardware implementation of the AS, whereas Kravate uses only general purpose vector instructions. Zoof has a smaller granularity, so 40 bytes of block size. Another advantage of Zoof is that it fits nicely on different platforms, so it has good performances from small to big platforms. So I start with the small ARM Cortex-M0 processor, and you can see that it's about four to five times faster than the AS in counter mode. The same goes for the Cortex-M3. On Skylake, it's slightly slower than the AS, but as soon as you have access to the AVX 512 instruction set, then it again becomes faster than the AS. So that's it for the presentation to conclude. So we presented a way to maybe refactor symmetric crypto, at least for the keyed operations. And we do that by proposing a new API, a new kind of interface called the deck function. And we think that this way of working puts the safety margin at the right place, meaning that we can from there build things that are quite efficient. We show the performance of Kravate and Zoof as showcases. Something I didn't mention, but we believe that Kravate and Zoof have actually conservative safety margins. And the only thing I wanted to mention is that besides the good performance in software, they have high potential when it comes to hardware implementations. And to finish, if you are interested in presentation-based crypto, we actually have a workshop with your code presentation-based crypto. Thank you very much. Thank you. Any questions? Serge. I'd like to know what is the security notion for deck function? It's PRF. So with variable length input output under a given key. So it's like PRP, but then PRF. So you have a benchmark measurement. But you used AVX too for your deck construction. And that I think reduces the clock speed of the CPU. So do you have benchmarks? Or does this also outperform AES in just absolute time? At least we disabled it. So this means that this should be actual cycles. Now, it's true that I heard that there is some kind of decrease of the overall speed when you use that feature. Yeah, these aspects I don't actually know. My point is more this really has potential when you have such vector instructions. That's really the point we're trying to make. Thank you. Still on the subject of ZOOF, you compared to AES 128 on Cortex M0. I would have been interested to see the numbers with respect to, for example, Chacha 20 or Sasa 20, which are actually extremely quick on those platforms. Yes, we don't have figures for Chacha. We are aware that, of course, Chacha is quite performant as well. I think when it comes to hardware presentations, ZOOF has actually much more potential than Chacha. Thank you. Perhaps I missed it, but in the deck presentation, you're working with stream of messages such that if one message was lost, the receiver will not be able to do the decryption. But then when you got to Cratchick and ZOO, it seemed like you switched now to a block that was not available, such that such risks were not operational situations not apparent. Is that correct that, though, the underlying deck is a session stream, but what you're building on top of it is a block and this can be used in an environment where lost messages is not an issue? So the deck function abstraction is really an important part of the process. The concept is kind of implemented on top of that. So the fact that DexSane and DexSense had that built into the mode, that was kind of a mode-specific design requirement, so we could do the same thing here with deckWBC simply by placing a chaining value into the tweak. You could take a truncation of plain text plus ciphertext, so that you can build a session mode various different ways. And not use a session mode when it's not appropriate. Correct. Good. Thank you. So I have a related question about these funky new modes that you're building, these kind of like online streaming modes. Have you done or what can you say about the security analysis you've done of these modes? So you start with something that's a PRF or a PRP, reordered by the adversary or dropped messages by the adversary. So have you done all the analysis of that? And what models did you use? All this is just based on the deck function behaving like a PRF. So I mean, as long as the domain separation is correct, so you can see this is why I use frame bits in this mode. So I'm putting a zero bit after the metadata and then I'm putting a zero one after the plain text. So that kind of domain separates all these strings, so that if the adversary tried to take two separate languages and combine them into one or whatever then it wouldn't work because the frame bits would prevent that. So that's kind of how we went about designing these modes. But do you have, I mean are you using like a stateful authenticated encryption security notion and you're proving that it meets that or something like that or there's like streaming modes, there's different models that you could use to prove security of this thing as a secure channel? Sure, I guess you can say we're just using the fact that like in this case the authentication takes a function of all the previous messages and this message, so it's just, it'd be as if we input all these strings in when we deciphered this message, but we're just reusing those contributions from the previous message, so. Okay, I guess we'll take a offline. Okay, there's no more questions. I've got a question. Sorry. You talked at the, right at the start of the talk about relying on crypt analysis by the community to give you assurance of certain things and the previous talk showed that that didn't work very well for a while and then suddenly did work very well, so aside from, you know, obvious things like making sure papers are widely available, do you have any thoughts on best practices for getting that assurance of from the cryptographic community? That's a good question of course. I think we need to do is to specify clear security claim and then try to provoke people in trying to prove that's wrong. That's, yeah, that's the only thing we can do and to make the things as attractive to attack as possible. So proposing reduced round versions and so on. Okay, so I think we're now done, so let's thank both speakers of the session. Thank you. Let's see if we have our slides. Fantastic, we're on. All right, so now we're going to switch gears and switch to the celebratory part of the event and we're going to be awarding our annual real world left-gen prize awards. Actually, before I do that, just a quick announcement, somebody lost a bracelet, so if anybody is missing a bracelet, it'll be right here and you can pick it up during the break. Otherwise, if anybody wants a bracelet there's one here. Okay, so I'll leave it right here. Okay, so let's get started. So, like I said, this is a fun part of the event, awarding the Levchin prize awards for real world crypto. So this prize honors basically major innovations in the field of cryptography that have had a significant real world impact and we really mean real world impact here. So the award is funded by Max Levchin, maybe you've probably heard of Max Levchin, he's the founder of PayPal and has done lots of other things, he's been a very strong supporter of cryptography throughout his life. Back in 2016 or maybe even 2015, we approached him about creating a new prize. We told him that we'd like to award $10,000 annually for work on real world cryptography. Max immediately said, yes, I'll support it. So we said, you have to support it for at least 20 years and he said, yes, I'll support it. So then we said, well, we want to give two awards per year and he said, yes, I'll support that too. So that's why we're able to give two awards every year. Let's see, so just the previous award winners since 2016, as you can see, these are all very prestigious members of our community, so I'm very happy that we're able to recognize their phenomenal contributions, you can kind of read their names for yourself, but I think you'd all agree these are amazing, amazing results. I was very happy that last year we were able to recognize all the work that went into TLS 1.3 as we heard earlier today that had enormous impact on the world. Okay, so with that, I guess I should just say that the prize itself comes with a $10,000 check. I have two checks here and it comes also with a trophy. The trophy itself is a cryptex, so the award winner has to figure out the secret password to open up the cryptex and then they can hide things inside of their cryptex for future generations to find. Okay. So, with that, let's award the 2020 Love Chin Prize. So, the first award drumroll, the first award, thank you, thank you, the first award goes to someone who is world renowned and very, very well recognized in his community, and the award goes to Ralph Merkle. So Ralph, I'm going to ask you to please come up, come up on stage. So the award recognizes Ralph's amazing contributions to the development of public key cryptography, to hash algorithms, to things we call Merkle trees now, and of course to digital signatures Ralph, of course made enormous contributions to hash based signatures. Before I hand it over to Ralph to say a few words, there's one thing that I wanted to show you. So this is Ralph's project proposal as an undergraduate student, undergraduate student back in 1974. This is an amazing thing to read. I often use this as an example showing that undergraduate students can do absolutely amazing and stunning, can have amazing and stunning ideas. Let's just read this quickly. It says the project that he proposed as part of this course is establishing secure communications between separate secure sites over insecure communication lines. This is back in 1974. No prior arrangements have been made between the two sites and it is assumed that any information known at either site is known to the enemy. The sites however are now secure and any further information will not be divulged. You can pretty much see the makings of public key cryptography in this project proposal. Again, it's amazing. This is back in 1974 before anyone had any inclination about any of this work. So it just goes to show that undergraduate students can do amazing things. And by the way it's interesting to hear the professor's comments. So the professor wrote up there well this is project number one, but your project number two actually seems much more reasonable. And maybe, well maybe I'll skip the rest of it, but basically saying maybe you should work on something else. This is maybe not going to go anywhere. Fortunately, Ralph didn't listen and we now have public key crypto as a result. So congratulations Ralph. First of all the stage is yours. Thank you very much. Well thank you very much for a very kind introduction and this brings back nostalgic memories of my CS244 that was a quarter project. I recall proposing a quarter project and being disappointed that I was not able to work on public key cryptography for my quarter project. Of course, we didn't have the word back then. So I had to describe what it was I was working on and of course it was regarded as well, not not exactly something that anyone would be able to do. I did drop the course because the professor was not supportive of the work at that point in time but I did go on and try to submit it for publication in the communications of the ACM and as I recall when I submitted it for publication two of the three referees seemed to think it was okay the third referee who the editor said was very, very well versed in cryptography and a very senior person in the field described it as not in keeping with current cryptographic thinking and so it was rejected for quite some time I persisted of course because if a senior person in the field rejected it and thought it was not in keeping with current cryptographic thinking that meant it was a new idea so that meant I was on the right track and it also meant that because I had submitted it if I eventually got it published they'd have to publish it with the original submission date and so I figured I'd just hang in there and eventually they'd recognize it and realize that it was a good paper and that's how it turned out it turned out I had to hang in there until after New Directions was published at which point suddenly the responses from the referees became things like oh yeah this is a good idea you should publish it but it did require three years as I recall before it eventually got published so I have a question how many of you have noticed that when you submit things to committee-based review in particular when you submit new ideas to committee-based reviews sometimes one member of the committee doesn't understand this have people noticed this problem? I hear laughter I take it that people have understood this so if I might point out this might be something where some reform would be helpful so if some better process than committee-based review for new ideas was developed and I have a horrible proposal and the horrible proposal is why don't we submit concepts for something better than committee-based review to the committee-based review process and then inch our way upwards because we have a process in place for evaluating new ideas an imperfect process but we can use that imperfect process to develop better ways of dealing with new ideas and given that what we have in place for reviewing new ideas is both imperfect but we've got it in place then we use that process to develop something better if I can make that modest proposal then perhaps that would be helpful across the whole range of areas where we are looking at new ideas with the committee-based process and I think there are a lot of areas where that takes place and this is based not only on my experience but I think on the experience of a lot of other people who dealt with this particular problem so that's one thing the other thing is how many people have heard of Merkel trees? yeah, okay how many people have heard of Merkel puzzles? oh, that's rather surprising a fair number of you have heard of Merkel puzzles so Merkel puzzles were the first public key crypto system invented back in 1974 as you've just heard and Merkel trees actually were developed a little later when I was working on my PhD thesis and seemed to be somewhat robust and I think they're robust because they're based on hash functions and hash functions are resistant to attack by quantum computers so I just thought I'd put in a brief plug for, you know, things that are resistant to quantum computers are a good idea because the quantum computers are coming and we need to be prepared for that and right now NIST is running some very nice competitions and we actually have in place some quantum resistant digital signatures and I mention that because I did work on that in my PhD thesis many years ago so that area is actually looking pretty good so if some of you want to work on quantum resistant systems for digital signatures and for authentication that area is a good one to start work on the public key distribution is still in process but I gather that the issue now is exactly when should we agree on the public key quantum resistant systems should we do it in, you know, the next year or two or the next three or four years how fast should we go ahead and do that so that seems like it's on track so that's basically all I wanted to say was the quantum computers are coming so we need to prepare for that and thank you very much for this very very nice award and the recognition of work that was done on public key cryptography actually a fairly long time ago at this point so thank you very much for this very kind recognition of work in this area thank you very much congratulations Ralph and thank you for all your work alright so like I said we always have two awards to give out and so the second award this year is gonna go actually in the area of hash functions to Xiyun Wang and Mark Stevens, Mark can you please come on stage please so Professor Wang actually couldn't be here because of visa issues but Mark is here to accept the award on behalf of both of the winners so this is recognizing work on groundbreaking contributions to the security of collision resistant hash functions and I'm sure you've all heard of this amazing result that actually showed that this hash function that was used for many many years actually decades, Xiaowan is now broken and should never be used again well that's all thanks to the work of of starting from the work of Professor Wang going all the way to the work of Mark Stevens and others as well so congratulations again Mark and looking forward to your remarks I just have a few words of course I want to thank the committee for selecting both of us for this award on a hash function from Cryptanalysis and I also want to thank Max Levchin for making this award available of course also congratulations to Ralph Merkel for also winning this award and actually I was really surprised to be a winner but I'm very proud to be one and I'm also very proud to win it together with Xeryong Wang which unfortunately could not be here today but she started really everything she started in 2004 and 2005 with the first collision attacks on MD5 and Xiaowan and that really created a lot of interest and research into hash functions and also a hash function Cryptanalysis in particular and there was a very large area so our work is shattered that builds on a long line of work and our works do not really stand alone and I want to thank all the people that have contributed for me personally my involvement started a slightly bit later than an undergraduate project I started my master thesis looking at the brand new MD5 collision and just trying to learn a bit more but that went a whole lot further than that in the end I mean it really has started my career in real world Cryptanalysis I would like to call it Cryptanalysis with a direct impact and there has been a long line of research in generating developing newer and better attacks and more importantly also demonstrating real world threat scenarios I mean there has been a real demand for such demonstrations to get MD5 and Xiaowan actually deprecated in applications so far as we consider that successful and of course it started with the first MD5 collision already then that was very costly was generated on a supercomputer and it was only a meaningless collision just two message blocks and so there was a immediate call for like yeah but how threatening is this it's just meaningless it's very costly so this really started the research my research into faster and better attacks and producing meaningful collisions and this led to the first chosen prefix collision attack on MD5 and demonstrating colliding certificates although even then the demonstration was not enough and we had to provide more demonstrations because this danger was not fully appreciated and some certificate authorities still continue to use MD5 so two years later on this led to the Rogue CA project well we first needed to build a better attack that really worked within the constraints to deploy this attack in the real world and then we had to demonstrate it by actually creating the Rogue CA using a bunch of PlayStation 3s but that finally really made the impact and we got certificates authorities to stop using MD5 and there is actually a very similar story for SHA-1 of course the main work went into improving attacks on the could it be run practically in 2017 there was the first practical attack but already in 2005 we had the first theoretical attack it took 12 years to finally make it run practical and tomorrow we will even see the first practical SHA-1 collision attack chosen prefix collision attack for SHA-1 the main downside still remains the cost so the main threat either has to be a high value target or collisions have to be reusable meaning that we can amortize the cost of these very costly SHA-1 attacks over many targets and I think we already did this with the shattered attack we created prefixes for PDF files and now you can just with a snap of a finger generate arbitrary colliding PDFs with different contents and further than that we have really been done for SHA-1 but luckily we have many examples for MD-5 and hopefully this grows also for SHA-1 and really to end I really want to say that we need more efforts in real world crypt analysis and in particular demonstrating real world threats and spending quite a bit of effort in there because there is a real demand for that to really make some change so I think the work still continues as long as SHA-1 is still used and I basically want to end with it so I want to thank everyone I really appreciate being given this award and I want to thank everyone Mark you forgot the most important thing yes so thank you for your work this is obviously a very impactful work so thank you for doing it so just to conclude I want to mention that we are always looking for good nominations for the award winners for next year if you go to the award site it's off of the real world crypto website there's a very simple nomination process all you have to do is just type in the nominee your name and a brief description of why you think they deserve the award and we'll take your nomination into consideration so please nominate people this really helps us in choosing the winners so I'll end here and we'll do this again next year and I guess now we have a lunch break so enjoy the conference everyone thank you