 hash function. I'm going to start with the timeline and I have some old hash function like snafru, md2, md4 up to recent functions or more recent functions like SHA1 and SHA2. And I want to make a point here, I took this timeline from these websites so if you want to know exactly what's going on here you can check the website of Valerie Aurora. But I want to make a point here that if we look at the past hash functions in the previous years we've seen a pattern. And the pattern is that we usually see some green and at the end we usually see some red. So the green usually means that it's considered strong for a number of years. People use those hash functions and the red usually means that it's broken. So broken here usually means that we find a collision. Collision meaning that for example you took two different words, the word mother, the word father. You hash them with the same hash function maybe md5 and you get the same output. So collision is very very bad. You usually don't want to find that on a cryptographically secure hash function. And as soon as you find one collision you usually say that the hash function is broken. So this is what happened here and you might have heard of the SHA1 collision, right? Ellie talked about that at Black Hat if you were there a few days ago. And pretty much a lot of people think that because of that we cannot build cryptography that can withstand the test of time. So this is not quite true and this is kind of a pattern that you see not even not only on hash functions but also SSL and TLS. Those things have gotten broken, broken over the years. And this is mostly because we didn't really know how to build these. Especially if you look at SSL and TLS the involvement of the cryptographic community was almost in existence. So this is something that is changing and in TLS 1.3 there's a huge involvement from the cryptographic community and this is kind of unheard of and this is pretty good. So here another thing that kind of came out of that is that when you look at SHA2 it's still considered strong nowadays. But a lot of people thought what if it breaks? So SHA2 is based on the same miracle dam guard construction which is also the core construction of SHA1, SHA0, MD5, MD4, etc. And all those hash functions have been broken, right? So we might wonder what if SHA2 also followed the same fate? Also if SHA2 breaks one day, well everything used SHA2. SHA2 is used all over the place as the hash function. So with that in mind, the NIST, an American organization decided to come up with a competition for SHA3, the next standard for hash function that could be used as a replacement in case SHA2 would come to bad points. So the SHA3 competition lasted five years. It was started in 2007. Had 64 candidates from all over the world. So previously SHA2 and SHA1 were not competitions so SHA3 was, that was new. Three rounds and the winner was Ketchak. So Ketchak finally won in 2012. Other candidates that didn't win but made it to the third round, the last round were Blake, Grustle, J.H. and Skyn. I'm not sure how to pronounce them but it wasn't that they were not secure. It's mostly because we only had one spot and Ketchak was quite different and quite supported so it won. But remember Blake because I'll be talking about that hash function after. So I'll use the next slide to kind of explain to you how Ketchak works. Ketchak is a sponge construction. So SHA3 is a sponge construction. And the sponge, sponges were invented as part of the competition, SHA3. At its core it used a permutation. So we'll say it's a permutation based cryptography. If you don't know what a permutation is, you can think of AES with a fixed key. It takes all the possible inputs of 128 bits and it gives you all the possible output of 128 bits. Right? So you have one plain text, one cipher text. There is a map. There is a mapping. So that's a permutation and the same thing here. You have an input of, for SHA3, 1600 bits and an output of 1600 bits. So here we'll start by having zeros for the inputs. You can think of that as an initialization vector. And we'll separate the inputs into two parts. The first part is called the rate. I'll call the public part of the input. And the second part is called the capacity. I'll call the secret part of the input. And it's kind of an arbitrary division. You can place it wherever you want and you'll see that in SHA3. You have different parameters where the secret part is larger or smaller. And the output is divided into two parts, the same two parts. So I'm calling that the public parts above and the secret parts on the bottom. And this is for a reason. We usually only touch the public part and the secret part we don't really want to touch. So we're hashing a message, right? So what we do is that we take our message and we XOR it with our state, which is the public part of the sponge. If our message is bigger than this public part, which is maybe like 1300 bits, something like that, then you take the next part of the message and you XOR it after you permute that state, you XOR it with the public part. And if your message is a bit longer, you permute again and you XOR it with the public part again. I'm not talking about padding, but it's basically like block ciphers or any of that. You usually have a padding so that you can reach the block size or the size of the public part. So, and you permute. So this is how you get the message into this sponge construction. And it's called absorbing. Makes sense, right? It's a sponge. So you absorb the message and once you want an output, once you want your digest, your hash, what you do is that you take the public part, right? It's public. So you really don't touch the secret part, but you can just use the public part which might be 1300 bits or so for Shafri. And if it's not enough, you permute and you continue using the public part and you append that to your digest. If it's not enough, you permute and so on. And this is called the squeezing part. Makes sense, right? You absorb your message and after when you need the output, you just squeeze it. So the K-Track team gave a paper proof of this. So basically this is secure as long as the underlying permutation is secure. How can we prove that the underlying permutation is secure? Well, we don't really know. We don't have good ways of doing that. The only way we know how to do that is to try to break it. So for five years, pretty much the Shafri competition was just cryptanalysis after cryptanalysis, trying to break this permutation. So in Shafri, this permutation is secure. So again, you can think of it like an AES kind of thing where AES has like what, 10 rounds for one of its variants. So Shafri has 24 rounds of a bunch of steps that you apply on the input, on the state. So Shafri or K-Track receive the huge amount of cryptanalysis. So this is a page they have where they list the amount of cryptanalysis that they have. And it's a lot. So that's mostly why K-Track was chosen as the new Shafri. Why did it receive so much cryptanalysis where maybe you have a clue in the list of its inventors? So inventors of K-Track are Guido Bertoni, Johan Damon, Michael Peters and Jill Van Ash. I'm not too sure how to pronounce their name but those are Italian and Belgian people. One of them, Johan Damon, is the author of AES. So that might be why so many people were really interested into trying to break it. Anyway, let's look at the timeline. So this is the Shafri competition, right? From 2007 to 2012. At the end, K-Track becomes the winner but it's not standardized yet, just nominated as the winner. And at this time also, Blake, which was one of the non-winner of the last round, decides to come up with a new hash function called Blake2. And pretty much what they did is that they looked at the cryptanalysis that they received during the competition and they said, well, we have a number of rounds, like K-Track, like AES, blah, blah, blah. And the security margin that we have is actually pretty big. So we're going to reduce the number of rounds we have to make it faster. They made a number of changes but this was the biggest change and it actually made Blake2 very, very fast. So they have this diagram on their website and you can see that Blake2 is faster than Sha1, then MD5, then Sha2, and a bunch of other hash functions and actually Shafri. And I'll come back on this slide after. But basically Blake2 was really, really fast. And people liked that. It looked secure because during the competition it received a substantial amount of cryptanalysis and people started using it. So this is a list, a non-exhaustive list of different projects that use Blake2. In them you can see WireGuard, which is kind of the next generation VPN that use Blake2 at its core. WireGuard also used Noise, which is a protocol framework that you can use to build something like TLS. So I didn't introduce myself but I'm a security consultant at NCC Group and I see a lot of custom made TLS protocols proprietary TLS thingies and usually they're looking for trouble and that's what the recommendation is usually to use Noise. If you really don't want to use TLS because it's cumbersome, because it's too big, because it's not secure, whatever your good or bad reason is, Noise is usually the answer. So Noise at its center, at its core use Blake2 as one of its hash functions. Argon2, if you don't know how to store passwords, we have a state-of-the-art password hashing function which is called Argon2, which came out of the password hashing competition that ended up last year, I believe, and it uses Blake2 at its core. Last but not least, Libsodium is the crypto library we usually recommend. It's based on salts and it pretty much has very good APIs and that's why we recommend it. It's very hard to make a mistake when you use it and for if you want to hash something, there is something called hash. It doesn't tell you what it is, it's just called hash and basically it's Blake2. Alright, so a lot of things use Blake2. Let's go back to Shafri. So Shafri finally was standardized three years after the end of the competition in 2015 in these documents called FIPS 202. So you don't have to remember the name if you want to see the standard, just Google. Shafri standard, that's enough. So it came out in 2015 and in that time, right, in three years Blake2 had the time to take over the market. Nonetheless, they came out with a reference implementation. If you want to use Shafri, this is the Kechak code package. I'll have that slide again at the end but this is the reference implementation in C and it's pretty good. There is another implementation that I want to tell you about. It's a Twitter implementation and it's basically if you go on the Twitter accounts, there are nine tweets I believe and if you concatenate those nine tweets, you get an implementation in C of Shafri. I'm not telling you to use it but it's pretty interesting how small the final implementation is and it could lead you to believe it's easy to implement. It's not easy to implement but they still did it in nine tweets. Anyway, let's look at this diagram from Blake2. Remember Blake2 is blazing fast and you can see at the end that Shafri is kind of slow. So Shafri was chosen, one of the reasons it was chosen was because it was the fastest of the hash functions in hardware but not in software. This doesn't mean it's slow but it means that if you really care about speed, if you're a big player, somebody like Google, Facebook, Cloudflare, you really want to optimize your speed, this might be an issue. So fast in hardware but not so much in software. And you might think that, well, Intel will one day implement it or support it in hardware. You might be right but if you look at the past support of Intel for hash functions and cryptographic functions, it usually takes a lot of time so don't hold your breath. And also we've seen that speed drives adoption. This is clearly true for Blake2 but this is true for, for example, elliptic curves with the curve 25519. This is true for authenticated ciphers, for example, Shasha 20, Poly 1305, which is very fast in software, which is the replacement for ASGCM and which will be Intel S1.3 as one of the new cipher. And if right now you have an Android phone and you use it to connect to Google, that's what you use. You use Shasha 20, Poly 1305, just because it's fast in software. Another one of these last example is if you look at TLS 1.3, if you look at Quick, if you look at these kind of modern protocols that kind of look like TLS 1.3, you have this new feature called zero RTT, which stands for zero round trip. And it basically allows you to encrypt data. So in TLS right you have the handshake and then you can encrypt your data. But this zero RTT thing allows you to encrypt your data in the very first message as part of your handshake. And it allows you to be very, very fast and that's why big players like it. But the security of it is kind of shaky, which made it the most controversial, I believe, feature of TLS 1.3. So if you look at the mailing list, there's a lot of discussions around that. And I believe if the big players didn't really want to optimize and didn't want this big speed, we wouldn't have this feature in TLS 1.3. All right, so in the next couple of slides, I'm going to explain to you why Shafri is slow, slowish. So let's talk about bit security. What is the bit security of AES 128? Well, it's pretty easy. It's around 128 bits. That means that if you want to break AES, approximately you have to do two to the 128 operations. So that would be two to the 128 encryption of AES. Now, what is the bit security of AES 256? Well, it's 256 bits. And this is usually the kind of security you want. It's either 128, which is what most people use. Or if you're really paranoid, if you really care too much, or if you want to market your application as military grade encryption, you usually choose the latest one, the latter. Now, what about SHA-256? If we look at the bit security of SHA-256 against pre-image attacks, pre-image attacks are not collision attacks, right? We're not trying to find a collision. But rather we see the hash of something. So you can imagine a dump of hash password. Maybe they hash the password with MD5 or something like that. And you're trying to find the original passwords out of the hashes. So that's a pre-image attack. So the security for this kind of attacks for SHA-256 is actually 256 bits, which is already very large. Now, if you look at the bit security of SHA-512, you can guess it's 512 bits of security against that kind of attack, which is absurd. It's a very big number. And nobody really needs that kind of security. Now, SHA-2 has that kind of security, not because they made bad decisions, but it's mostly because of how it's designed. It's just a nice property, I guess, of SHA-2. The way it's designed brings you that amount of security. Now, the NIST wanted something with SHA-3 that was something secure and something you could use as a drop-in replacement for SHA-2. So they decided to have the same kind of security. And SHA-3-512 actually provides 512-bit of security, which again is absurd. And here, it doesn't really make sense because they could have had less and could have mirrored the security of AES with 128-bit security and 256-bit security. But it chose not to do it. So this was kind of a weird decision. And it led SHA-3 to be slow. Basically, the explanation, if you remember, SHA-3 has these public parts. The sponge has a public part and a secret part. And to attend this kind of security, they made the secret parts larger. What does it mean? It means that you can store less message in your public parts because it's smaller. And also, when you get the outputs, you can use less because this part is smaller. So you have to use more permutations in the end to hash the message. So yeah, another reason might be that a lot of people have lost their trust in the NIST organization mostly because of backdoors and duality and that kind of stuff. And so they might have wanted to show people that they were not going to mess around with SHA-3 and actually make something that was very secure. And if you look at it, they actually increased the number of rounds. Kitchak was not 24 rounds in the beginning. And they increased it to 24 to make it even more secure, which made it even more slow. Anyway, this is the explanation. Now, we can ask the question, where is SHA-3 being used? Well, I give you some hints. You have to think of crypto-friendly kind of companies. You have to think of modern or recent kind of bleeding edge companies. And if you haven't picked up the answer yet, the answer is blockchain, cryptocurrencies, Bitcoin, and that kind of stuff. Usually, a new one come up every day, so they can afford to use the last hash functions. And this is what it is. Actually, I've looked at their forums, some cryptocurrencies forums, and I've seen that some of the people there market their last cryptocurrencies, their new cryptocurrencies by saying, oh, it uses SHA-3. Look at it. It's shiny. It's beautiful, et cetera. So just one problem I'll mention is that they say they use SHA-3. Some of them will use, well, I think some of them don't use SHA-3, but derive function from SHA-3. And also, some of them started using SHA-3 before it was standardized. And so they use a different number of rounds, which is not a problem by itself. But if they try to interact one day, it will be a problem. All right, so let's go back to the FIPS publication, which has SHA-3 inside of it. And I kind of didn't tell you the whole story. This standardized SHA-3, but it also standardized something new called SHAKE. SHAKE is exof. It's an extensible output function. It's something new. And basically, I have this picture, so like that, when you'll try to think about what David talked about today, you'll try to think about that picture. You can also think about me shaking. And what is exof? Well, exof is an extensible output function. It's basically a hash, which has an infinite output. So pretty much you can decide what length your output is. You can decide for your output to be a very, very long length, or it could be one byte. Well, don't do that because it's not secure, but theoretically, you could choose it to be one byte. It also has better parameters. So it has a 128-bits version of SHAKE and a SHAKE 256, which provides 256-bit of security, which make it faster than SHA-3. So that's one of the recommendation I'll make today. If you want to use SHA-3, I think it's a better choice to use SHAKE. It's exactly the same construction, except that it has center parameters and it's faster. Although I'll still say that SHA-3 is a standard. It's a rock solid, and it's good for people who don't really know what hash functions they can use. They can just Google the standard, and the standard is here. So this is really interesting. And if you're a developer, or if you're a consultant, or if you look one day at something like that and you want to use it, and if you're wondering what kind of output you should get, you can check this page, which is called the Tune Page of K-Chack. And pretty much, it tells you what kind of length, what kind of output length you can use for what kind of security. If you ever have to look for it, just look for tuning K-Chack or tuning SHAKE, and you'll find it. And it's pretty handy page. Now, SHAKE was so useful and so cool, actually, that Denise decided to release another document called Spatial Publication for SP, or SP for Spatial Publication, 800, 185. Again, you don't have to remember that, just Google derived SHAFRI functions or something like that. It's not really SHAFRI derived functions, it's rather SHAKE derived functions. So a year after the standard of SHAFRI, and it basically had a bunch of functions, three functions, K-MAC, tuple hash, and parallel hash, it also had a customizable version of SHAKE, but I won't be talking about that here because it's not too useful, but maybe if you want to use SHAKE in your product and you want to customize it with a string saying, it's my SHAKE, it's my protocol, it's for me, you can use SHAKE, which is a customizable SHAKE. And actually, these functions are derived from SHAKE. But you don't have to remember what I just said, it's a detail. So this document had a lot of these, and you think of SHAFRI, you have to think of SHAFRI, SHAKE, K-MAC, tuple hash, and parallel hash. It can be kind of confusing, and this is kind of why I'm here today. I'll tell you about all these functions and what you can use them for. So K-MAC, to explain K-MAC, I'll start with a very simple example. Imagine you want to send a message to Alice, you don't want to encrypt it, you don't care about encrypting it, you just want to send this message across the wire, and you want to make sure nobody in the middle can modify it. So what you do is that you send a message and you open, I don't know, SHA256 of the message next to it. I hope everybody in this room is aware that you shouldn't do that, right? Anybody in the middle can just take that hash, modify the message, and recompute the hash on the message, right? It's trivial. Now what if I do this? What if I add a key to the message? Actually, who thinks here in this room, who thinks that is secure? Show of hands. The what? So is this thing secure? It is putting a key next to your message, allowing you to protect the integrity of your message. So if you send that across the wire, does that mean that nobody can modify this message? And the receiver, the recipient, do you think it's secure? The what? Well, the recipient has the key. Well, not necessarily. You can keep the same key for every message. It basically looks like a net Mac, if you think about it. It's a message code authentication, and it looks like it should work. That's what we use usually when we authenticate messages. The problem is that you cannot do that with SHA256. You cannot do that with a lot of Miracle Damguard-based construction, actually. And the problem is that when SHA256 gives you the output of a hash, it gives you the output of the states. So basically, it hashes the key opponent to the message, and it gives you the states. Well, there is some padding to it. So like every hash functions, or most of them, and like AES, and like actually Shafri, you have a padding, right? And here you get key opponent to the message, opponent to the padding. But this is the states of the function, as the attacker, if you get that, you can pretend that it hasn't finished hashing. And you can continue to hash like it's not the end of the message. And basically what it allows you to do is to get the hash of key opponent to the message, opponent to some padding, and opponent to anything you want, without knowing the key. This attack might allow you to do some weird things, might allow you to exploit some applications that use SHA-256 or SHA-512 that way. It's not always the case. It's kind of a, because of the padding, because of that kind of thing. But it might be a problem. And it shouldn't be a problem. A hash function, if it behaves like a random oracle, should allow you to do that kind of thing. And actually Shafri or any Shafri contestants like Black2 and all the others allow you to do that kind of thing without being a security issue. So here, if you use Shafri or just check, it works. And this is basically what K-Mac is. I omitted a few details, but this is basically what K-Mac does. It takes check, opens a key to the message, and it allows you to create a Mac out of it. Kind of like H-Mac. Topple hash. So let me talk about the following problem. Imagine I'm using one of these secure messaging app. I have end to an encryption. And I'm using RSS public key to encrypt messages to Alice. And Alice's public key is an RSS public key, so if you don't know what an RSS public key is, it's basically a small number E and a big number N. And to make sure I'm really talking to Alice, I take a fingerprint of that key, which will be shot to 56, a hash of that key, the small part, appended to the big parts. And Alice will do the same thing on her phone and will compare that in real life or out of band. Now, you can imagine that basically I'm doing this. E is a small number in bits, and N is a very large number, something like 2048 bits, probably. Is that thing secure? Again, who thinks this is fine? And if I make a fingerprint, if I compute a fingerprint out of Alice's public key and she does the same with her public key, we can compare that and I can make sure that I'm really using her public key. So maybe show of hands who thinks this is secure. Who thinks this is not secure? All right, not so many people. So the answer is that you can create a different public key that will have the same fingerprint. How do you do that? Well, what if I do that? What if I choose a larger E? It's the same E, but it steals bits from the modulus N. And then N is kind of the rest of the bits. It's a different public key, right? But it hashes to the same value, the same fingerprint. It's the exact same sequence of bits. So, and here again, the modulus might be small enough that it's weak and you might be able to crack it, reverse it, use the private key to use that public key. So really here the problem is that you're not, you're hashing something in an ambiguous way. So what you should do is to hash the length of the first value, then the first value, then the length of the second value, then the second value. And you can even go further and have the type of the first value, the length of the first value, and the value, the type of the second value, and so on. This is actually called a TLV for tag length value. And this is what is used in smart cards. So I believe there are no real standards on how to do that correctly. And tuple hash is actually pretty much hashing the length of the first tuple, of the first object of your tuple, then the first value, then the second length, then the second value, the third length, the third value, to hash something in a non-ambiguous way. So if you're wondering how to do that, if one day you need to hash something in a non-ambiguous way, tuple hash is one of the answer. And actually I believe it's the only answer. If somebody knows something better, you can tell me. Parallel hash, the last one. And kind of like with the others, you can kind of guess what it is from the name. If we look at this sponge construction, remember we absorb the message and then we squeeze it. And we might wonder how we could optimize this thing. Can we parallelize this computation? So now if I want to compute this permutation here, I need the output of this permutation first. And to compute this permutation, I need the output of this permutation first. So it's not very parallelizable, it's very serial, and this is a problem for big inputs. So parallel hash is basically using what they call a tree hashing construction, and they divide the inputs into large blocks. They hash those large blocks individually, obtaining a smaller input, a smaller output. And then finally they have a hash of all these outputs. It's a pretty simple construction, right? Yeah, it actually allows you to hash big inputs, large files, very quickly. So I believe a block is around 4,000 bytes, something like that. The problem here, if you have something smaller than 4,000 bytes, basically you'll hash it and then you'll hash it again. So you have kind of a penalty, so it doesn't work that well with small inputs, but if what you do is only hashing large inputs, then this is a very good thing to use. And it's actually very, very fast. So again, timeline, kind of a recap. Black 2, one of the very fast hash function, which is an alternative to Shaffery. Shaffery, the standard, rock solid. If you want something more flexible and faster than Shaffery, you have Sheck. If you have different usages, you have tuple hash, parallel hash, and Kmac. All right. Here, something I didn't mention, I believe Black 2 also has something like parallel hash, something like Sheck, and so on. If you want to know more about that, you can go on the Black 2 website, but my talk is mostly focused on Shaffery. All right, so different things for different usage. Now, I want to mention Kayak and Keche. Those are two things based on Kechak as well, from the Kechak team. And those are candidates to the Caesar competition. So the Caesar competition is a non-going competition for authenticated encryption. So think of ASGCM. So it's still going on, and those are some of the candidates. I don't know when this is going to finish. Nobody knows, it's been taking a very long time. But one day, maybe you'll be using not ASGCM, but maybe you'll be using one of the sponge construction even when you encrypt and authenticate your messages. Who knows? So I'm not going to explain these things, I just wanted to mention them. In 2016, I believe end of 2016, the Kechak team kind of concedes in the war of speed. So they see that Black 2 is being used all over the place. They don't really like that. And they end up constructing something that will be faster than Shaffery, but based on Shaffery. And the solution they came up with is called Kangaroo 12 and Marsupilami 14. If you don't know Marsupilami, it's a French comic, some kind of beast with a, I should have had a picture of that. Just Google it, it's a kind of an animal, fictive animal with a yellow animal with like black dots. It's very funny, you should read it. Anyway, it's very fast. The what? Astro, some new place? Oh, anyway, all right, can't tell me again. Basically, it's what Black 2 is to Black. Does that mean something? Anyway, they reduced the number of rounds of Shaffery to obtain something that was way faster and still practically secure. So the theoretical security is lower because they reduced the number of rounds of that permutation. It's not 24 anymore, it's 12. It's quite a drastic reduction, but the practical security is still here. We believe we still have a margin of security that is significant enough. Marsupilami, Kangaroo 12 is blazing fast. It's faster than parallel hash, it's faster than Sha-1, Sha-2, Shaffery and all these constructions. I don't know if it's faster than Black 2, I believe it plays in the same ballpark, but it's not very important. At this point, it's so fast that your hash function is not really the bottleneck of your application anyway. And one very cool thing about Kangaroo 12 is that it has tree hashing by default. So Sha-3 doesn't have that, Kangaroo 12 has that. So it's kind of the mature hash function that we deserve. So it has this tree hashing that allows you to hash large inputs very quickly, like parallel hash, but it doesn't have this penalty for small inputs. So for small inputs, it doesn't do the double hashing thing that parallel hash does. So it's fast for large inputs, it's fast for small inputs. So yeah, very exciting hash function. And if you care about speed, my recommendation will be to use either Black 2 or Kangaroo 12. Again, if you want to use any of the shake functions, any of Kangaroo 12, Sha-3, shake, et cetera, all of these can be obtained from the K-Chack code package that you have on this page. And this is all I have to say about Sha-3 and derived functions from Sha-3. I have a Part 2 on Strobe, it's a bit more involved and it's quite different. So I'll start with that. Strobe is a protocol framework, kind of like noise, but it focus on the symmetric parts of your protocol. And it's very sexy in the way that it only use K-Chack, only use shake. So you can think of it as, you can use it to create protocols. So not the handshake parts, but rather the symmetric part of your protocol. And you can use it pretty much to do any symmetric crypto. So you can use it to encrypt, authenticate, generate random numbers, derive keys, you can use it to hash. You can use it pretty much for anything and also create your protocols. And it's only one primitive, only this shake at the center. The good thing is that if you look at the code, it's tiny. It only has a very, very small code base and it's easy to audit. It's pretty straightforward to understand. So how does it work? Well, if you look at the sponge construction, the thing we had earlier, you absorb messages and then you squeeze messages, right? And you might wonder, why can't you, after squeezing your message, why can't you just continue and absorb another message and then squeeze it again? And then absorb again and then squeeze it again. And actually this is a valid question and K-Chack came with an answer. Yes, it's possible. And this is not called the sponge construction but it's called the duplex construction. It basically allows you to absorb, squeeze, absorb, squeeze, on and on. The point of that kind of construction is that if you look at the third one, when you absorb and you squeeze, the result you get actually depends on what happened previously, on everything that was absorbed previously. So this is a very nice property to have in protocols where you want every messages you send or something like that to depend on every messages that happened previously. This is what we call consistency of the protocol. It means that nothing is going to work if someone reordered your messages, replayed some of them or dropped some of them in the middle. So you always depend on what happened previously. So this is what's at the heart, the core of Strobe. You can build protocols that have this nice property. So I'll give you a very simple example before I explain to you how Strobe works. Imagine that you're on the client side but since it's symmetric, you would do pretty much the same on the server side. You instantiate your instance of the Strobe protocol with some custom string. So the custom string could be mywebsite.com if your protocol is called mywebsite.com. It could be anything you want but it basically describe your protocol and it has to be the same on the other side, on the server side. Now you can key your protocol. You can insert some key. It could be a pre-shared secret, right? It could be a shared secret coming out of a key exchange. So you could do a noise key exchange actually and use the shared secret that you obtained from the D-filment key exchange inside of this. So on the server, you would use the same one. And now you can do some fun stuff. So if you want to encrypt the request to the server, while you use what they call the send-encrypt call on Strobe on the request gets the roots of the domain. For example, if it's some sort of a web protocol. And you append that to the buffer. Now before sending the buffer, you also want to authenticate your encryption, right? So you use the send-mack call on Strobe with a length of 16 bytes. That's usually enough for an authentication tag. You append that to your buffer. You send it, right? Pretty straightforward and the server receives that. And the server on the other side would do something similar but the inverse of those functions. Now you receive an answer from the server and this is the inverse of the function. You would do the receive encryption. And you would keep the last 16 bytes as the tag. So you would use the receive-mack on the last 16 bytes. And you would make sure that the Mac is okay. And if it's not, I don't know, you reset the connection. You crash. That's not a good idea, but you could do a different kind of things. So that's a very basic example just to tell you how you can call these functions that Strobe defines in the specification. Actually, there are a bunch of functions that Strobe defines. Those are all the function you can use and you can use combinations of that. If you want to re-key your protocol at some point in time, you can use key. If you want to have forward secrecy in your protocol, you can use ratchets. You can send some non-uncryptom messages with send clear and receive clear and so on. What it does every time is that it absorbs those operations so that every following operations depend on these operations. Before I explain to you how it exactly works, I'm going to talk to you about the internal of Strobe. This is really detailed. So bear with me, but basically you don't have to understand this part. This is very, it's really, if you're curious. So you have a default internal operation and this is what happens every time you use some kind of operation. Or this is the default that happens when you use some of the Strobe operation. The default is to basically absorb your inputs inside the sponge, right? Or inside the duplex construction. So how do you absorb? Remember you XOR your inputs, your message, who is the states? Remember that's the absorbing phase. So usually you'll do that. Now sometimes you want to replace the state with your inputs. That might be when you want forward secrecy or when you want to key your protocol, you replace the bits of your state with your inputs. Like that, if you leak the states, nobody can guess what the previous state was without knowing the previous bits that were erased by this operation. One last operation, it's called the see after. And basically you do the same thing. You absorb your input with the states. That becomes the states. But you might have wondered, does that look like a one time pad or a stream cipher? And basically you can think of the states as a key stream, your input as your plain text and that could be the cipher text. So if you retrieve that outputs, you can say that it's the cipher text and that's how you encrypt in strobe. And I believe this is how KAC and KCHE does the authentication cipher work also. One last one, it's called forceF and this is to force the permutation to happen before you do anything. And this is basically when you really want your operation to rely on what happened previously. So every time you encrypt, for example, you really want your encryption operation to be dependent on maybe a key that you inserted in your states. So you're gonna force the permutation before doing anything. So very quickly, an example. Here is your state, right? It has the public part and the secret part. I'm saying it comes from somewhere, maybe you did something previously. And here I'm gonna key the states. So before I do it, I'm going to absorb the operation I'm doing. Strobe is very verbose. And so I'm going to absorb the key operation. I mean, I'm simplifying here, there is some padding, et cetera, but basically this is what we do. We first absorb the operation. Now we permute because we're keying and we want to have this forward secrecy property. We want to erase the bits of the states with our key. And this is pretty much how the key operation works on this duplex construction. Now if I want to send some encryption, I will first absorb the operation, right? I permute because I want to depend on the key that was absorbed or that was replaced in the state. And then I absorb the state with my plaintext and I get it out, I get out the ciphertext. I have a bunch of examples like that. For example, the AD for authenticating more data, you don't need to permute, right? Because you're not sending anything right now, so you don't permute the thing. That means that you can have several operation in the same block before permuting. And then before sending the MAC, you really want the MAC, the authentication tag to depend on that data that you want to authenticate so you permute and then you get the output which will be the authentication tag. Again, you don't have to understand all of this. If you're really wondering how it works and one day you look at the specification, you can look at my slides and they can kind of help you to understand the specification and how it works. But this is really to arouse your curiosity. I said that you can use Strobe to do other things than protocol. For example, if you want to use the code base of Strobe to just hash, what you will do is that you just initiate your Strobe instance like you're initiating a protocol but you just initiate a hash function so you can call that hash or anything you want, my hash, my hash David Wong, something like that. Then you add what you want to hash, you absorb what you want to hash and then you squeeze it with the PRF function. And you can use this thing also to generate random numbers and so on. The specification kind of tells you every time you want to do something, how you can combine those operations. Key derivation function, again an example where you can use different calls to derive a key out of a key itself. I'm not going over all the details here but if you want to know more about this cool Strobe protocol framework, you can check the specification on this page. It basically helps you to implement it. There is an implementation in C, I have an implementation in Go which is more of a readable implementation to help you understand how it works. I don't have an optimized implementation yet but it's coming. I don't have a part three yet but it's coming. I'm doing some research currently on Disco. Disco is basically a noise which is this protocol framework but basically focused on the handshake part of protocols and Strobe which is focused on the symmetric parts. And together I believe that it can be more efficient, easier to implement and you can get rid of all the symmetric implementations just by having Strobe and this is called Disco. There is a draft of the extension on this page. If you want to find it, you can check my blog or check my Twitter. I usually talk about it. So read my blog, follow me on Twitter and this is basically the end. I don't know if I have time for questions. Do I have time? One minute for questions. Yes. No more developer. All right, that's a good question. My recommendation is that if you already used Shattu and HMAC, there are no real reasons to move. If you're trying to choose hash functions and authentication, it's something like message authentication codes and so on, you have no reason to choose Shattu since we have those new modern hash functions and all of that where you can use only one construction to do all your symmetric crypto. Unless you're using Shattu to do this weird Mac thing where you have the key and the message, then you might have a problem here. But if you're using Shattu correctly, I don't see any reason to move right now. Yes? Yeah, yeah, basically you can abuse it to use it as a stream cipher. I think some people are already using that as a stream cipher. And I mean, basically their proposition in the Caesar competition looks like a stream cipher and strobe is kind of like a stream cipher as well. Yeah? It looks like a stream cipher. I mean, you can use it to pretty much generate random numbers like a stream cipher and explore that with your plaintext. Right, so this is what strobe does. What's your question? Yeah, we're moving away from stream ciphers, but it's mostly for bad reasons that was because RC4 was kind of broken. And also, I think we realized that block ciphers were easier to implement in hardware, which was a good reason at the time, but no software is very fast. So if you look at the last cipher in a TLS 1.3, it's actually a Shasha 20 Poly 1305 is actually a stream cipher. Correct me if I'm wrong, but. Yeah, yeah, so ASGCM is also kind of a stream cipher based on the block cipher is true, but. So I don't believe people can screw up stream ciphers more easily than, I don't believe this is too correct, but I'd be happy to be wrong if you have a good argument for that. Do I have to stop here or? All right, all right. Another question? Yeah? So have I compared strobe to edge KDEF or other key derivation functions? I have not, but it has the same properties. So yeah, so the reason to use strobe instead of edge KDEF would be that you're using strobe to do all the stuff. So if you already have strobe to do all the different stuff, there is no reason to add edge KDEF to add another implementation on top of that. When you could be smaller and you already have the implementation for a key derivation and so on. So who uses strobe? Yeah, so it's rather a consequence of using KTAC at the core is that you can do so many things with it that you only need one primitive, one implementation. So it's, yeah, that's a consequence of using that is that you can use all these. So as a consequence, it does reduce the cut size tremendously. Yeah. Oh, I can repeat the question, I guess, but I'm not sure I understood it. So you're saying you have to verify the mark and it's like separated. It's not like. Okay. Okay, so the API of strobe is not too developer friendly. Strobe is still very experimental at the moment. And this is the kind of thing we're discussing right now. The last discussion is to make send encrypts, to rename it to send a non-authenticated, I cannot say this word, non-authenticated encrypts. Like that it might make developers understand that this is not authenticated. Another one would be to have just a send authenticated encryption, which would combine send encrypt and send MAC. So yeah, we're still like trying to see how this could be made more, less dangerous to use, let's say. So this is very experimental. This is, if you know what you're doing, this is a good idea, but if you don't know what you're doing, this is kind of edgy. So you're saying that there are so many derived functions from that. Is there like an easier way to use them? Or an easy API? I don't believe so. I think my talk is kind of the easiest way to understand all of these constructions. I don't think there is really any work in there to make it easy for developers to understand what are all these dysfunctions. I'd say they're not, KMAC is not a hash, right? It's really like a message authentication code for the rest. I'd say just use kangaroo 12 because it pretty much is the mature construction that derives from a shake. It's an extendable output function. It derives from parallel hash. You can parallelize it. And it derives from a chaffery. You can hash anything. So kangaroo 12 is kind of the easy API to use. Yeah, all right, thank you.