 So, hello. Good morning. I know it's four, but I still feel like it's morning. I have a luncheon now. So, I'm very happy to be here in Hamburg at CCC to talk about crypto again. So, talk about a project called CSAR. This project initiated by DJB about finding new crypto algorithms. I don't know how many of you have heard about CSAR, the competition. Yeah, quite a few. How many of you have heard about Norx? That's good. So, the thing is, Norx may or may not be the future of authenticated encryption. But anyway, CSAR will develop, will select the future of authenticated encryption. And we're also here to convince you, because we hear a lot about encryption at CCC, about how important it is to protect your privacy and so on. So, we hope to convince you maybe to just stop using encryption and to use authenticated encryption instead of basic encryption. So, Philipp, we'll start with an introduction. Very basic, no many questions, no math, we promise. And then we'll give all the details about these two guys. Okay, so, who are we? We are a team of three people. You've already met Jean-Philippe. My name is Philippe. And there is a third guy who unfortunately cannot be here. He's not here today, Samuel, but I'm sure he's watching the stream. So, hi, Samuel. So, and I want to start the talk with a quote from a cryptographer, Matthew Green, and he said, nearly all of the symmetric encryption modes you learned about in school, textbooks and Wikipedia are potentially insecure. So, this is a quote from one of his blog posts about choosing authenticated encryption modes. But before we are going to dive into authenticated encryption, we will see what he meant with this quote. So, question to the audience. What should not miss in any talk about symmetric crypto? Yes, I heard it, right? The ECB penguin. So, most of you have already heard about it. What is the problem here with the ECB mode? ECB is a block cipher mode where you plug in a block cipher and you can use it to encrypt multiple blocks that are then composed to a message. But ECB mode, it does it blockwise. So, you take the first block, put it through your block cipher, the next block and so on and so forth. So, the problem here is when you give the two same blocks to the block cipher, you will get the same ciphertexts. And what that results to in, you can see here very well, you can still see the shape of the penguin. At this point, I also want to thank Ange Albertini for doing all these great pictures. He's also somewhere here in the audience. So, but he did not only do this picture, but also the next one. This is the CBC mode, which is also widely used today. And the problem here with CBC mode is that it takes in an so-called IV, an initialization vector. But the thing here is when you encrypt your message or two messages with the same IV, then you might also run into problems that you can see here. For example, the left penguin here is missing one, the left eye and the other, the right eye. And when you encrypt both of them, you get perfectly fine ciphertexts. But when you extra them together, you see that the first, so the head of the penguin, where no differences are encrypted to the same ciphertext again. So, what's really important for CBC is that your IV is random. And this especially means that it cannot be a counter. So, as soon as your IV is predictable, you also run into problems. The next mode here is CTR mode or counter mode. It also uses a nonce. This is something quite similar to an initialization vector. But a nonce, it has to be just unique. Nonce means number used once. So, you can use a simple counter. But again, when you use the same counter and key pair to encrypt two different messages, you also run into problems because you get two ciphertexts and you extra them together and you suddenly end up with getting information about your plaintext. You can also see it here again with the penguin on the bottom. So, when you extra them, you don't see anything, but then you can again see the shape in some sense of the penguin. So, these block cipher modes, they were designed in the 70s. And they were meant to be used with the back then brand new DES algorithm. So, there were a bunch of those block cipher modes. It was ECB, CBC, CFB, OFB and CTR. And the goals with these block cipher modes, they were in some sense a little bit different from what we expect now from cryptography. So, a famous quote from Bruce Schneier in his book Applied Cryptography from 1996 is a third consideration is false tolerance. Some applications need to parallelize encryption or decryption, while others need to be able to pre-process as much as possible. And still others, it is important that the decryption process is able to recover from bit errors in the ciphertext stream or dropped or added bits. So, the concern of the time was error propagation and also how to recover from those error propagations. This is something that you don't expect from a crypto algorithm, right? So, a thing that people somehow don't had on their radar was a term called malleability or in German, Formbarkeit. This means that an attacker that is intercepting ciphertext messages can somehow modify these and then also modifies the plaintext in some predictable way. We already saw this for the ECB penguin, where you can basically, the order of how the blocks are encrypted is not a part of the encryption process itself. So, you can rearrange or even replay blocks. Or you can also replace entire blocks without the communication partners. So, the true communication partners will ever notice. The same problem is also with CTRO of B mode, which in some sense generate the ciphertext in a stream cipher fashion. And you can do bitwise modifications to also change the plaintext at the same positions. Also, the CBC mode that we were already talking about has some problems because in decryption when you change one ciphertext, you can predictably change the next plaintext, which is also bad. So, again, the two communication partners, they have no way to detect if somebody fiddled with the ciphertext on the transportation way. Then there are other problems like chosen boundary attacks. They also apply to some of these modes like ECB, CBC or CFB, which can be used to decrypt messages byte by byte. For example, there is a paper called, here come the XOR Ninjas, which shows how to decrypt encrypted cookies that were encrypted with ASCBC. And this is also the issue because of these partial chosen plaintext control. So, what you really want to have is authenticated encryption. We already saw two days ago a very nice introduction about ECC. Unfortunately, I don't have a clock example here, but I will try to do my best to convince you or to explain authenticated encryption to you. So, what is it? Imagine you have an algorithm that is an authenticated encryption scheme and it takes as input a key, a nonce and a message. And it uses the key and the nonce to encrypt the message to a ciphertext and an authentication text. And the ciphertext, it protects the confidentiality and the authentication tag, it protects the integrity and authenticity. So, authenticated encryption is basically the, when you, as JP already said, when we are talking about encryption these days, we usually mean authenticated encryption. Because once you send data out over an unprotected line, you want to also make sure that the data is not modified along the way. So, and this is what authenticated encryption is needed for. And it is used in many, many protocols, IPsec, SSH, GLS, and so on and so forth. And then there is a second variant, which is called authenticated encryption with additional data, where you take a message, but now you also have some additional data as an input, which is here symbolized as the H. And this data, again, goes through the, through the AAD scheme and a ciphertext and attack is produced. But now the tag not only protects the cipher, the message, but also the header. But the header is communicated in clear over the line. So, this is, for example, important when you want to protect some parts of your datagram that needs to remain in clear, for example, some routing information in IP packets. There are a bunch of ways how you can realize authenticated encryption. The first is so-called generic composition. And what you do here is you take a symmetric cipher, like a block cipher, in a certain mode and you use a Mac with a message authentication code. And you combine these two to form an AE or AAD construction. And there are three ways to do it. It is the three are encrypt and Mac, Mac then encrypt and encrypt then Mac. Encrypt and Mac is basically you encrypt your plaintext and you Mac your plaintext and then you send both along the way. Mac then encrypt is you first Mac your plaintext and then you encrypt the Mac and the plaintext to form the ciphertext. So, the Mac, the tag is a part of the ciphertext, which leads also to some problems. And the third one is encrypt then Mac where you first encrypt your plaintext to the ciphertext and then you compute the Mac over the ciphertext. And over the years it was shown time and again that the first two options are not good. So, don't use them in your applications. Use encrypt then Mac when you have to use generic composition. And examples of such constructions are, for example, A is 128 CBC, plus H makes 256 and charge a 20 plus poly 1305. Another way to construct AAD schemes are dedicated methods. So, we already saw block cipher modes that enable you to encrypt multiple blocks with a block cipher. And there are also block cipher modes that transform your block cipher into an authenticated mode. So, you don't need a separate Mac for it. And four well-known variants are CCM, GCM, OCB and EX. The first two CCM and GCM are those that were standardized by NIST. And GCM is the one that is mostly used these days, but both of them have minor issues. JP will later tell you a little bit about that. OCB is another block authenticated encryption block cipher mode, which is very nice. But unfortunately, it is patented. And in recent years, the patents were somehow weakened a little bit. So, I think for open source software, you can use them without problems. You know, military can use it, essentially for free. Yeah, as long as you don't use it for military and I don't know what. And the fourth one is EX. Then there are other possibilities where you basically have just one primitive. So, it's some kind of mixture also of... Usually, it's a mixture of a stream cipher plus a Mac. And four variants are Grain 128A, which was for... Grain 128 was a finalist of the second last crypto competition, the eStream project. Then there is Helix and Felix and Hummingbird 1 or 2. But the last one is... The last two are broken. And a very new way to construct AEAD schemes are sponge functions. We will also see later what this means. So, but also using authenticated encryption modes is not without risks. So, you have to nevertheless be really careful what you do with your scheme because otherwise you run into problems. So, for example, in the case where you have this generic composition where you combine a symmetric cipher and a Mac, it's not so easy to get the interaction between those two primitives right. So, for example, for the Mac then encrypt option, there was time and again... It's the variant that is used in TLS. And there was time and again there were problems due to this Mac then encrypt option that was used. For example, if they would have used encrypt and Mac then probably most of the problems that we saw in the last years would have never been a real problem. So, another thing is that we already saw that CCM and GCM are the only two real standards out there that were standardized by NIST. And if those two variants do not fit your, for example, for your product or something, then often people invent their own schemes and ciphers, which is obviously also not the best idea. Then there is another thing which is called misuse. We also saw that in the very beginning when you, for example, use twice the same nonce to encrypt your data. Then you can all run in these problems that you showed you in the beginning, for example, with CTR mode. And then there are also bad parameter choices which, for example, also apply to GCM. JP will also tell you about that in a few moments. And this led to all kinds of problems which you all, I'm sure, have heard about. So, what are those problems? Let's have a look. I probably don't have to say much about that. It's the padding oracle attacks. It was invented by Serge Vaudenay in 2002 and it targeted the Mac than encrypt mode. Remember this is the bad mode that I explained earlier from the generic composition and especially when it is used together with CBC mode. Because you have some weird interaction between the cipher, the authentication tag and the padding that is used to fill up blocks that are not the same size as the block size of your block cipher. And in 2002, people thought, yeah, okay, this is a theoretical attack and we cannot use this really to mount it against anything that is in production. But in 12 years from 2002 to 2014, it was repeatedly exploited, for example, to mount attacks on TLS. You've all heard about Beast and Lucky 13 and the latest variant is also depicted here. It's Poodle, the padding oracle on downgrade legacy encryption where you can attack SSL V3 and TLS, basically. I guess about this you also have already heard a lot. It's an attack on the VEP standard, which was used to protect your Wi-Fi connection. And in 2007, some researchers presented a key recovery attack where you can within minutes really decrypt the entire key stream by reconstructing the secret key. And it exploits biases in the RC4 stream cipher that is used there. And then after a while, there was a tool which is called AircrackNG and everybody can download that and crack their own Wi-Fi connection. So try this at home. Then another attack in 2013 also targeted RC4 where so-called biases were detected in the ciphertext stream. I mean, it was already known that RC4 is not the best stream cipher out there. But there in 2013, they really showed, yeah, you can really use these biases. So these are the spikes here in this graph to partially decrypt a stream that is, for example, encrypt was used in TLS to decrypt your data. So another attack on RC4 was just from this year where Kenny Patterson from the University of London tweeted, folks really need to stop using RC4. We just broke another RC4-dependent system which is called Hive from next week's CCS. So Hive is a hidden volume encryption system. And it was, in some sense, perfectly fine-designed and also came along with a security proof. But the problem was that they were using for their pseudo-random number generator, the RC4 stream cipher. And that enabled the people around Kenny Patterson to mount an attack on this Hive system. Yeah, so, but who cares about security when RC4 is fast and swift, right? So this is from this year's keynote from Apple where they showed, yeah, swift is the best and fastest language when you use it with RC4 encryption. So, and now we will see a bunch of things what the crypto community came up with to somehow get rid of all these problems that I was talking about earlier. All right, so I think it's pretty clear that we need better ciphers. And some people started to do something about it. It's called CISAR. So CISAR is a crypto competition, it stands for competition for authenticated encryption, security, applicability and robustness. First of all, what is a crypto competition? You may have heard about AES in the 2000, Shastri in 2010 around this time. The concept is pretty simple. So you are an organization, you want to find a new cipher, a new hash function, a new block cipher, and you don't have much time, you're not a crypto expert, so you will ask people all over the world, you guys are the experts, and you will work for free for us. You will create your own cipher, you will submit it to us. Typically, we as NIST in the case of AES and Shastri. So academics, people from industry, people from government, they work maybe one year or two, several teams of people, they create a new cipher from scratch, specification, analysis, like 100 pages document, they do this for free for the organizers, and then NIST publishes the designs, and now everyone tries to break the other guys' candidates, because your incentive is to win, so you need to break the others, like a demolition derby, and at the end of the competition, before the organizers, they maybe do some short list, some rounds of selection, it's like we have 50 candidates, let's short list down to 30, and then down to 20, and then 10, and then we pick one. So that's the idea, that's how AES was selected, that's how Shastri was selected, and it works very well, because it's completely transparent. Everyone can contribute security analysis, implementations, and this is much better than obscure things like some other countries are doing. So that's the thing with CISAR. So typically, the goal is to replace some old standard. AES was replacing this, Shastri was replacing and CISAR is about replacing or doing better than AES GCM. So AES GCM is essentially the single authentication encryption standard that we have. So AES GCM stands for Galois Counter-Mode, it's a mode where you do essentially an AES AES counter-press, and in parallel to this, you do some polynomial multiplications over a characteristic to fill, and you compute an authentication tag that depends on all the blocks that you have processed. So I'll come back to this and why we want to do better in GCM. Some details on CISAR, so it started in 2014 in March, well actually for some meters it started one year before because they published the call for submissions 2013, but the submissions were published this year. You can look them up online on this web page, and it's expected to finish in 2017. So before that, there would have been several rounds of selection. I think the next one is officially due 15th of January. So it's initiated by Daniel Bersin, with a committee of 22 cryptographers, and it's sponsored by NIST, but NIST is not controlling the things, NIST is just giving the money. So the winner will not necessarily be a NIST standard, so NIST might care about what's going on, but it's not a US government competition. That's the main thing. Alright, so ASGCM, so like I said, it's easy to use everywhere, it's in the suitby of NSA, you may have heard about NSA recently, and the use of AES, it's one of the cypher specifying in this special publication, it's used in some IATF standards for IPsec, TALS and SSH, in a few IATF standards as well. So it's actually has the monopoly of authenticated encryption. So what's wrong with GCM? One thing is that, from point of view of cryptographers, it's unnecessarily complex. It does that operation and use some polynomial multiplication, and you can do the same thing, the same functionality without using this relatively complex mathematics. Also it's fast if you have AES native instructions, if you have your Intel or AMD chips, you have this AES, and I think that make AES considerably faster than a normal implementation, but if you don't have hardware accelerators, and it's much, much slower. So another thing is performance. And also another issue is, like I said, side channel and timing leaks, because if you don't have hardware support, you want to have a fast AES, and typically what you will do, you will create huge table look-ups, but instead of doing the textbook AES, you will make a run by doing essentially a few table look-ups. And as you may know, this may lead to timing leaks, and eventually to cubicle rate depending on your attack model, on your attackers capability. Another thing is, so Philippe talked about misuse, what happens if you reuse the nonce that you're not supposed to reuse. So what happens in AGCM is that you can recover the authentication key. So the secret thing that is used to authenticate your message. So if you find this guy, then you can forge tags and you can compromise authentication completely, in some cases. All right, so what's wrong? I talked about GCM, I didn't talk about AES. You may have heard yesterday people saying, NSA is compromising AES, and you've seen this small screenshot. As far as I understood, I don't have access to the Snowden stack, but my understanding is that this is an undergrad project proposed to some summary interns at NSA about applying some very old statistical techniques to AES, but it's not a billion-dollar project aiming to break AES. Actually, well, it's no surprise that NSA is trying to understand how to break an AES. It's part of the job, and I expect them as well to try to break Shastri to understand how secure it is. They're not the only ones to do this. Academic researchers, every year they publish very sophisticated research where we get new insight about how AES is working. What we get out of this is that we better understand why AES is secure. The bottom line is, don't worry, AES is not broken. Implementations may be broken, but the algorithm, it probably can't be broken, but that's my personal opinion. Let's go back to CSER. There's been exactly 57 submissions. It's less than Shastri that received 63 or 64 submissions, but many more than AES where there were only 15. So, one of the submissions there is ACORN++AE, AEGAS, AESCMTC, AESCOBRA, AESCOPPA, AESCPFB, AESJAMBU, AESRTR, AESRTMASCON, Avalanche Calico, CBSC, BIMCLOG, DOCSIS, and so on and so forth. You might have heard the word AES in several submissions. This means that a couple of those are based on the AES block cipher and they're just a submission of a mod of operation that they propose to insensiate with the cipher AES. In some cases, they do some modifications to AES, but it's also AES-based. So, the motivation, obviously, here is to take advantage of the high speed of AES in mainstream CPUs. I think I counted yesterday there's approximately 25 submissions that use AES or some variant of AES in CSER. Towards the others, I don't know, MacMambo, KT, Julius, I don't know how they're working, but they're either a new block cipher created from scratch or some stream cipher that has this authentication feature or something based on the sponge function. That's what Philip mentioned before. I'll present the sponge function in the next slides. So, how secure are they? Some people have already tried to break them. We counted 13 that have been meaningfully compromised and 5 for which imperfections or a little bit more imperfections have been found. And 39 for which no flow has been published. So, it doesn't mean there is no flow at all, but that nobody published it. So, you see that there's this guy in Norx in blue. So, fortunately for us, it's not been broken yet. I'll try to convince you that it's secure. So, before designing Norx, I created with some other people a hash function called Blake. It was one of the finalists in Chastry. And every time I presented Blake or talked about it, people had only one very single question. It was, why the name Blake? And it was quite clueless because there was no really good reason. But here I'm happy to have some explanation behind the name Norx. It actually comes from not ARX. So, what is ARX? It stands for addition, rotate, XOR. It's a type of cryptographic algorithm where we just use those two operations. So, integer addition, rotation of course and XOR. And that's sufficient to make something that isn't breakable. In terms of complexity, it's universal. So, you can implement any functionality, any computable functionality using those three operations. Why did we choose to not be ARX? So, we removed the A, removed the addition. So, we use rotation with XOR and only bitwise operations. So, logical N and logical R. The reason it's not that it's intrinsically more secure is that it's just easier to analyze. It's easier to find mathematical results, for example, bounds on the security, quantitative bounds on the security of the cipher. It's also much simpler to implement in low-end CPUs if you have like eight or 16-bit registers. You don't have to care about the carries and it's much simpler to implement in hardware. You don't have to use others to choose the right type of others. It's much more simpler in terms of implementation. Alright, so, what were our design goals for like in every engineering project before starting doing things, we think about what we'll be doing, what's the objective. So, we wanted cipher to be secure obviously, the most important criterion, to be fast in all platforms. So, we didn't optimize specifically for this model of chip or for this specific FPGA. We want to be constantly fast across all platforms because we don't know how to be used by any user. Simplicity. So, people are sometimes impressed when it's complex, you have a lot of equations and great letters and stuff. We want to make things as simple as possible, be the specification or the code. And we want people who are not experts in cryptography, who are not crypto PhDs to take the spec and to implement it in maybe one afternoon. Simplicity also means some notions of symmetry in the sense that if you look at the NOx encryption and the decryption is almost the same function, you have just small tweaks, but you don't have to implement something completely different if you want to decrypt or encrypt. It's online, one pass, so you have your data, you process it once, you don't have to process it once for encryption and one for authentication. A single pass or a data. Scalability in terms of parallelism, so horizontal scalability and unrolling. Key agility. It means that, unlike, yes, we don't have a slow key schedule, we don't waste cycles expanding the key and then storing the expanded key and so on. We just inject the key very simply and we try to minimize side channel leaks. So we can only do so much at the algorithm level, but we try to make something that is easy to implement in constant time, for example. All right. So NOx is not a single cypher. It's actually a family of cyphers with a few parameters, a few dimensions, and you can tune those parameters to find the instance that best suits your application. So the first parameter is the world size, the machine world size. It's either 32 or 64. 32 typically means that you will make 32-bit rotation, 32-bit exhaust, but obviously you can use a 32-bit version on a 64-bit CPU and the other way around. Like many in-may cyphers, you can choose a number of rounds. The degree of parallelism, so how many cores do you have available for NOx? In order to take advantage of your CPU, we can create a tag size. So there's a huge design space for NOx, but for the sake of Cesar, we only submitted a few, so exactly five proposals. We have NOx 64-bit, also 32-bit with four rounds or six rounds and one D equal one. So when the parallelism degree is one, it means that it's completely serial. And you might ask the question, why did you choose to have four rounds and six rounds? Well, I have no simple answer to this, but let's say that we try to break NOx, we try to break one round to round and essentially a trade-off between security margin, between security and efficiency. All right. So we have version with 128-bit key or 256-bit key. So the mode is essentially what we call a domain extender. In other words, a combination of the core function to process inputs of variable size from something that takes input of fixed size. So here we have this function f that takes something of fixed size and we combine it, we iterate it in such a way that we can process messages of any reasonable size. So it's derived from the sponge function of Ketchak, which is now SHA-3, and more specifically what they call the monkey duplex. So don't ask me why it chose this name, but the idea is to take a hash function mode and modify a bit so that you can make an authenticated cipher out of this hash function mode. So it's extremely simple. You have this function f, which is a permutation. So it takes an input, it transform it in some complicated way and it creates something of the same size. And since it's a permutation, you can invert it. It sounds a bit contradictory because in Krypton, you don't want to invert things, but here that's really what we need. So you see a bunch of examples. What we're doing, we're injecting the message and injecting parameters. So the message injection is very simple. You just exhort a message, so here it's p, for example. You just exhort p to the state and then you transform the state. At some point, we exhort h, which is the header, for example. So something that's not encrypted. We inject it to the state, it will modify the state, then it will get a different state. So all this is about modifying the state in such a way that you get something less secure for some definition of security. So I don't give all the details, you can look up in the paper. In the parallel mode, it's essentially the same. So you exhort your messages to the state, you get a cypher text out, but here the difference is that you have two branches in parallel that are completely independent. So if you have two CPU cores, you can run one branch on the first core and the other one on the second core, and if you have 16 cores, you can make 16 branches in parallel and then optimize the efficiency. So Nox is really about transforming a state using a permutation. So a state is just a string of bits. And this string of bits is seen as 16 words of either 32 or 64 bits. And we view this area of words as, say, a matrix of 4 times 4, 4 times 4 words. So it might remind you AS, it might also remind you Sasa 20 or Chacha or Blake or Blake 2. And we have two different types of words. So the words where we'll inject the message, which are the blue words here, which we call the rate words, and in green, the capacity words, which we never touch. So if you're an adversary, you can't control, to some extent, the blue words by choosing your message words, but you can't control the green words. And that's where the security comes from. To simplify things, the more green words you have, the more capacity words you have, the more secure, in theory, is the algorithm. So we didn't make those words operate in capacities standard terminology from the sponge function literature. So for two versions, the state is of size either 512 bits or 1K. And you see the rate is adapted accordingly. So now Philipp will explain you how we transform this state to encrypt messages and to authenticate messages. Okay, so we already met this guy. And what you haven't seen yet is that there are, I mean, JP, he mentioned it, but there are a couple of different faces, how the algorithm works. And now we will have a look at the different faces. The first one is initialization, and it's in the red square over there. So let's see how this works. So at some point you have to do something with your secret key, right? Because we have here a symmetric key algorithm. And how it works is you take your 4x4 matrix and you load your key in the yellow part here. Okay, that's all. The number used once that you need to increase with every message that you encrypt is loaded into the green part. And the blue part, these are just constants. Nothing else. So and what else do you do after you've loaded those basic elements is you integrate somehow your parameters into the initial state because you want to make sure that you already saw that Norx is a huge family of cyphers and you want to make sure that each instance of the family produces a unique key stream. And for this we use the parameters to integrate them into the first state because afterwards when we transform the state we ensure this way that the key stream that is produced afterwards is really unique. And the final step in the initialization is just you apply the round permutation f to the power of r. This means just apply the function f r times. This is the notation for that. To the initial state and you get a new updated state here s again. So and this was the first version of initialization but you see here this parameter integration is a little bit kind of a mess. So we decided we make it much more easier and now we integrate the parameters just on the lower row of the matrix. So this is basically the same but the parameters now get integrated into the initial state in another way. And again the final step is also here apply the round permutation. So and that's it. That's initialization. The next part is absorbing header or trailer data. Usually authenticated encryption schemes they support additional data and additional data here means usually they support header data. So which you usually process before you process your plain text sorry. But in some protocols it's also useful to have also a trailer which you can somehow process after your plain text. And nor has here these two phases first for the header and then for the trailer again in the red squares which basically work exactly identical. Except for a small constant which is called the domain separation constant. So the domain separation constant which is here 0 1 or 0 4 in hex just says OK now I produce. Now I absorb header data which is the 0 1 4 or I absorb trailer data which is the 0 4 4. So after you have absorbed the domain separation constant you again apply your round permutation. This is the middle part. And then finally you take your header or trailer block. This is here the yellow part and X or it on the blue part. And what you get is the orange part. And here you already see the important thing is that the green part is not touched by the data processing. And that's it for header and trailer. How to encrypt payload is the in the middle here. This is basically again very similar to absorbing header and trailer data. But now the domain separation constant changes to 0 2. Then you apply again the round permutation absorb your data. Again here the message is now the yellow part. But what you also do is now you extract your data which is now the red part. And you set this red part as the new ciphertext block and that's it. And the final step in your data processing is to generate the authentication tag. This is here the last phase. And again you X or in a domain separation constant then you apply the round permutation twice. And extract a part of your state which is again in this red part or in the blue part that I showed you before. And set this as tag. Here we usually use the first four words of our state to set as tag. So what I now you somehow got a feeling how the the mode itself works. But what I haven't said yet is how does the permutation work the F to the power of R. And this basically transforms the state. So one application of F transforms the state into steps first a column step. This is here on the left and where you apply a function G onto the columns. And then you use the same function G afterwards to apply to the to the diagonals. So the G function is the real core of our algorithm. And it just as we said before it's an not arcs construction where you use logical bitwise operations. And you see here the eight steps that are done in one application of G. And you see the age is in some sense the the nonlinear function. Then the green one the ROTR is a rotation right. You can see it here on the bottom where you just use your rotate your word to the right by a constant R0. Then you do again the nonlinear operation a rotation a nonlinear operation rotation and so on and so forth. And the only thing that differs here is that you use four different rotation operation four different rotation offsets. Okay this is hard here the red ones and depending on the word size they also differ. So for 32 bit it's 8 11 16 31 and for 64 bit it's 8 19 40 63. And that's it basically and here the the H function this is the function that replaces integer addition. Okay just to be clear here. So as we also already mentioned the properties of these permutations they were inspired by Blake to and the judge of stream cipher. And as I also said the age replaces integer addition and in fact it's almost an integer addition. So a funny story here is when we designed this permutation this core permutation we went along and we already knew we wanted to somehow replace integer addition but we we didn't know what to use. Okay so we used really really many bitwise logical operations and tried them out on their cryptographic properties. And at some point we were frustrated because we couldn't find anything that was really good for our for our purpose. Until I think it was Samuel he came up with this age function which is basically an approximation of integer addition. So what he what he did is he found in an old Knut book he found this equation for integer addition. And you see it's x x or y plus is here again integer addition and then this part here the non-linear part. And all that we did in our age function is just replace this plus by an x or and suddenly this also had very nice cryptographic properties. And so we went with this. The nice thing is as already said it is only bitwise operations you have you don't have to worry about carries. You also don't have to worry about lookups in S boxes. It's easier to get constant time operations out of this. It's very hardware friendly and it's also software friendly because of these the layout of their functions. If you remember you have four parallel applications of G to the columns and then to the diagonals which is very good for software. So the great question of course is is nor secure. And here the main threat is technique called differential crypt analysis. I won't go into the details here. But it's basically the first type of attack every cryptographic primitive has to somehow be resistant against. And we did a lot of experiments in our evaluation of the cryptographic security of Norx. And we found here that for one round there are characteristics which you somehow can it's an analogy for these biases. Remember this RC four picture where you have these spikes. And basically a characteristic is in some sense one of those spikes. And in one round of Norx only there are those biases appear with a probability of greater than two to the power of minus 64. And in the 32 bit version and with a probability of greater than two to the power of minus 53 in the 64 bit version. So there are no characteristics that have a higher probability than this. And in four rounds we found characteristics that are even more insane which have a probability of two to the power of minus 584. And in the 32 bit version and a probability of two to the power of minus 800 something which is really you cannot exploit that. And what I also want to mention here is that in order to find the attack on Norx you somehow have to get through the initialization. And the initialization here uses at least eight rounds. And we already saw that for already for four rounds there are the probabilities of those biases are really really low. So we are somewhat confident that it's really hard to find good characteristics or differentials in the initialization. And also kind of recent results there are where we found out that the parameter choices that we had were very conservative. And we even could trade some of those capacity words the security words to get to some rate words to get a 16 percent speed up. So this is also included in the security margin of Norx. All right. So less than 10 minutes left to be for concluding. My thought must have been very boring. I see my daughter is asleep. I'm sorry I must have bought everyone in the room. That's amazing. All right. So very quickly on performance on the next 86 and 64 bit more CPU as fast as five hundred ninety three maybe bytes per second. One one one gigabyte per second. You have the clock cycle figures here is for the optimized implementations which means the one that use either AVX or AVX to instruction extensions or Intel chips. What is great with Norx is that the reference code. So the simple portable easy to read code is not much slower than the optimized one. On the first case on the left side it's about 50 percent slower and about 80 percent slower on the AVX to on the on the Haswell machine. It should take a yes it's very different. So an arm platform. So in the eight which is an arm V seven architecture CPU. It's about one hundred maybe bytes. So the frequencies are just one gig. It uses the neon same extension. What is surprising here is you look at the the A seven from Apple from the iPad is now V eight architecture. The faster code is not the neon code. It's the reference code. Why because they have four parallel integer arithmetic units and this makes the code a little bit faster than the neon code. So how does Norx compare to the other Caesar? So each column here is a machine a different CPU. And the colored boxes are nox instances. So you see that in many cases nox on the top in a couple of cases nox is in the in the low middle. So these are the machines that have AS native instructions and why the AS based candidates are much faster than us. But so Norx is not only very fast compared to the others where you don't have AS instructions. It's also the fastest sponge base game. It's even faster than the submissions based on Ketzak in most in most cases. And like I said the reference code is about as fast as the optimized one. If you compare to AS GCM that I mentioned before AS GCM reference code versus optimized code and nox reference code versus optimized code. So in some cases our reference code is even faster than the optimized AS GCM. We took the open cell version something similar on on platforms from different reasons. So you see that for AS you have to work hard, write assembly, use hardware accelerators. In Norx you can take the portable, easy to read code and you get competitive speed. We have an hardware implementation. So not on not just a simulation and software but an actual chip that was made by our friends from ETH. So thank you from Ketzak and to his students. It's been done on UMC 180 nanometers chip and nox it goes at about 125 megahertz. And the DRA is approximately 60K, 60K gates, which is good. And with this preference figures it reaches a throughput of 10 gigabits per second. Which is much more than you need in any application. It's time to conclude. So first maybe if you've said for all the talks you may want to remember that CZAR is a new crypto competition that started this year. Really till 2017. It's about auto ticket encryption, auto ticket ciphers and there's been 57 submissions. So in a few weeks they will submit, they will publish the second round section. So I don't know how many will be selected but it will be interesting. You can go to the official web page, to the non-official web pages and some personal plug. There is another competition called PHC about password lashing. Put the URL here. Finally the nox. So it's a candidate in the CZAR competition I mentioned before. The main point about nox is it's quite innovative. It's used in a different way. It's parallelizable, was dissimilar ciphers were not parallelizable. We try to minimize sectional leaks. We don't need you to have a yes instructions. Obviously if you don't trust NSA, if you think NSA has backdoor a yes in some way then we don't use a yes. It's straightforward to implement. I think the other day I asked Philippe, we need a Python implementation and in a couple of hours they got a Python implementation working. We have a website now.io. We have code available in cc++, go Python Rust. It's completely free to use. I don't recommend you to use it, but if you want to use it, it's free. There is no pattern, no pattern application. Our reference code is under cc0 license, which essentially means do whatever you want with it. One very last thing. Maybe we convinced you that nox is a great cipher on Earth, but we won't recommend you to use it because we only published it this year. It takes time to gain confidence in a cipher. Maybe it will be broken next week, I don't know. We're pretty confident, but really we need to wait a couple of months or years before nox has been used in resensitive applications. At least for now. Thank you very much. Happy dancing. Thanks so far for our two speakers. We have a few maybe five minutes left for questions. If you have a question, just quickly line up at one of the microphones and please be precise and short. We'll just start with you at microphone over three. Yeah, I go. Is it working? I was just looking at your ABX versus ABX2 difference there. Sorry to interrupt. If you're leaving the room, please be quiet and maybe just stay for the last four remaining minutes so we can have a quiet Q&A session, please. Yes, I was just looking at your ABX versus ABX2 implementation and I was the other day I was struggling with I think the same problem that you were having that the integer is not in ABX, which is completely dumb as we all know. But so I was doing a bit slicing of a cipher that shall remain unmentioned, but I realized that actually ABX, originally ABX1 has X or not and so basically everything I need. And I wondering why you don't have that. So basically ABX2 is like ABX1 if you all you need is X or not at end and or. We knew that ABX2 would eventually come out and when, well, if NOx happens to be selected, most in the CPUs will have ABX2 on top of ABX. So it didn't make much sense to optimize for a VX which hasn't much restricted. I mean, I actually it's just a header file and basically just use ABX1 as if it was ABX2. Okay, so we'll do a quick question from the IRC if we have one because they can't ask a person. Do you just go ahead? No question. Yeah, it's on. We'll be happy to take questions offline anyway, so you can also send us emails or wire Twitter or wherever you want. Yeah, the microphone is working. Okay, first question from the internet. Put it a little bit closer to your mouth, please. How many researchers outside your team have analyzed NOx for vulnerabilities? How many? Well, we only know the ones who published something. We don't know the ones who did not find anything, but there's been... There was one work that we also did together with some people from Leuven and where we basically showed what I meant before that the parameters are chosen very... So that you can get a 16% speed up by trading this capacity versus rate words. And this was basically done with some people from Leuven. So where we showed also security proofs for the mode and so on and so forth. I mean, targeted crypt analysis was not done yet, but at least not that we know of. Maybe there's coming something out in the next weeks. So basically the results that we showed until now were our own. Yeah, that's it basically. Just microphone 2. My question is what's the failure mode of NOx if you reuse key and IV? So if you encrypt the same different plain texts with the same key and IV? Well, if you reuse the same IV, you don't recover the key. But if you have two different messages with the same prefix, then you will be able to figure out that you have the same prefix. So it's a big security issue. It doesn't completely compromise the cipher. We try to minimize the compromise. So what you basically get is you can exor the cipher text blocks then and you get basically the exor of the plain text blocks. That's what's happening when you reuse key and IV for two different messages. So the failure mode is almost the same as in the counter modes? Yeah. For confidentiality. How is this better than GCM? Oh, not exactly, but I think we'll discuss the details offline. Okay, so we're just one minute over time, so we'll have to just stop the Q&A session here. The two guys are going to stick around and are reachable via email. So if you have remaining questions, just let them know. Thanks so much for attending. Please take your empty bottles with you.