Hash function. I'm going to start with the timeline. And I have some old hash function
like Sneferu, MD2, MD4, up to recent functions or more recent functions like SHA-1 and SHA-2.
And I want to make a point here. I took this timeline from this website. 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 found 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 a 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 SHA-1 collision. 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 only
on hash functions, but also SSL and TLS. These things have gotten 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 inexistent.
So this is something that is changing. And in TLS, we're going to have to do something
like 1.3. There is 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 SHA-2,
it's still considered strong nowadays. But a lot of people thought, what if it breaks?
So SHA-2 is based on the same Merkle-Damgaard construction, which is also the core construction
of SHA-1, SHA-0, MD5, MD4, MD5, MD5, MD5, MD5, MD5, MD5, MD5, MD5, MD5, MD5, MD5, MD5, MD5, MD5,
etc. And all those hash functions have been broken, right? So we might wonder, what if
SHA-2 also follows the same fate? Also, if SHA-2 breaks one day, well, everything uses
SHA-2. SHA-2 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 SHA-3,
the next standard for a hash function.
That could be used as a replacement in case SHA-2 would come to a bad point.
So the SHA-3 competition lasted five years. It was started in 2007. It had 64 candidates
from all over the world. So previously, SHA-2 and SHA-1 were not competitions, so SHA-3
was new. Three rounds, and the winner was Ketchak.
Okay.
So Ketchak finally won in 2012. Other candidates that didn't win but made it to the third
round, the last round, were Blake, Grostel, JH, 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 SHA-3 is a sponge construction, and the sponges were invented as part of the
competition, SHA-3. At its core, it uses a permutation, so we'll say that 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 bytes.
And it gives you all the possible outputs of 128 bits, right? So you have one plaintext,
one ciphertext. There is a map. There is a mapping. So that's a permutation, and the
same thing here. You have an input of, for SHA-3, 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.
We'll separate the inputs into two parts. The first part, called the rate, I'll call
the public part of the inputs. And the second part, called the capacity, I'll call the secret
part of the inputs. And it's kind of an arbitrary division. You can place it wherever you want,
and you'll see that in SHA-3, 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 going to show you how to do that.
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 parts and the secret parts 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 go and you have the public part. Well,
and you XOR it with, 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 1,300 bits or so for Chaffery.
And if it's not enough,
you permute.
And you continue using the public part
and you append that to your digest.
And 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 Kitschak 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 Chaffery competition was just cryptanalysis
after cryptanalysis trying to break this permutation.
So in Chaffery, this permutation is just, 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 Chaffery has 24 rounds of a bunch of steps
that you apply on the input, on the state.
So Chaffery or Kitschak received
a 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 Kitschak
was chosen as the new Chaffery.
Why did it receive so much cryptanalysis?
Why did it receive so much cryptanalysis?
Maybe you have a clue in the list of its inventors.
So inventors of Ketchak are Guido Bertoni,
Johan Daman, Michael Peters, and Gilles Van Asch.
I'm not too sure how to pronounce their name,
but those are Italian and Belgian people.
One of them, Johan Daman, 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.
It's a hash-free competition, right, from 2007 to 2012.
At the end, Ketchak 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 Ketchak, like AES, blah, blah, blah.
And the security margin that we have is actually pretty big,
so we're gonna 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 SHA-1,
than MD5, than SHA-2, and a bunch of other hash functions,
and actually, SHA-free.
And I'll come back.
I'll talk about 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-existent list
of different projects that use Blake2.
In them, you can see WireGuard,
which is kind of the next generation VPN
that used Blake2 at its core.
WireGuard also used Noise, which is a program
and 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,
used Blake2 as one of its hash function.
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 Salt, 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 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.
All right, so a lot of things use Blake2.
Let's go back to Chaffery.
So Chaffery finally was standardized three years after,
at the end of the competition, in 2015,
in this document called FIPS 202.
So you don't have to remember the name.
If you want to see the standard,
just Google Chaffery 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 Chaffery, this is the Ketchak code package.
I'll have that slide again, as well.
At the end, but this is a reference implementation in C,
and it's pretty good.
There's another implementation that I want to tell you about.
It's a Twitter implementation,
and it's basically, if you go on the Twitter account,
there are nine tweets, I believe,
and if you concatenate those nine tweets,
you get an implementation in C of Chaffery.
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,
and they 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 Chaffery is kind of slow.
So Chaffery 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 the hardware, but not so much in software.
And you might think that, well,
Intel will one day implement it
or support it in the hardware,
and 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,
and this is true for BLEG-2,
but this is true for, for example,
elliptic curves with the curve 25519.
This is true for authenticated ciphers,
for example, Chacha 20, Poly 1305,
which is very fast in software,
which is the replacement for AES-GCM,
and which will be in TLS 1.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 Chacha 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 QUIC,
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 Roundtrip,
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 is 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 Chaffery is 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 2 to the 128 operations.
So that would be 2 to the 128.
OK.
That's the 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.
OK.
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 bits of security.
OK.
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 a 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.
Kitschak 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, what's this?
Where is SHA-3 being used?
Well, I'll give you some hints.
You have to think of crypto-friendly companies.
You have to think of modern or recent 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 comes up every day,
so they can afford to use the less 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.
Some of them will use, well, I think some of them
don't use SHA-3, but a derived 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 standard standardized SHA-3,
but it also standardized something new called SHAKE.
SHAKE is XOF.
It's an extendable 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 XOF?
Well, XOF is an extendable output function.
It's basically a hash, which has a new name.
It's 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-bit version of SHAKE and a SHAKE 256,
which provides 256 bit of security, which
make it faster than SHA-3.
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 standard parameters, and it's faster.
Although, I'll still say that SHA-3 is a standard.
It's rock solid, and it's good for people
who don't really know what hash functions they can use.
They can choose 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 Ketchak.
And pretty much, it tells you 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 Ketchak
or tuning SHAKE, and you'll find it.
And it's pretty handy.
It's a 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 SHA-3 functions,
or something like that.
It's not really SHA-3 derived functions.
It's rather SHAKE derived functions.
So a year after the standard of SHA-3.
And it basically had a bunch of functions, three functions,
KMAC, 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 C-SHAKE.
Which is a customizable SHAKE.
And actually, these functions are derived from C-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 SHA-3, you have to think of SHA-3, SHAKE, KMAC,
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 KMAC.
To explain KMAC, I'll start with a very simple one.
A 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 append,
I don't know, SHA-256 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?
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, this message, and the receiver, the recipient?
But what about the question, do we think it's secure?
Do you think it's secure?
The key is the key of the same key.
The what?
The key is the key of the same key.
Well, the, the recipient has the key.
No, I mean, we have to change the key for every message.
Well, not necessarily.
You can, you can keep the same key for, for every message.
What is the key?
It's, it basically looks like an HMAC.
If you think about it, it's a message code authentication.
And it looks like it should work.
That, that's what we use usually when we authenticate messages.
The problem is that you cannot do that with SHA-256.
You cannot do that with a lot of, uh,
Merkle-Damgaard-based construction, actually.
And the problem is that, uh, when SHA-256 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 state.
Well, there is some, some padding to it, uh, so, like every hash function, or, or most
of them, and like AES, and like, uh, actually Shafri, you have a padding, right?
And here you get key opponent to the message, opponent to the padding.
But this is the state of the function, and as, 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 ha, to, to, to, to, to, to, to, to, 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, to do some weird things, might allow you to exploit
some applications, uh, 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, of that kind of thing.
But it might be a problem.
And it shouldn't be a, a problem.
A hash function, if it believes, if it believes, if it believes, if it believes, if it believes,
if it behaves like a random oracle, should allow you to do that kind of thing.
And actually, SHA-3 or any SHA-3 contestant, like Blake2 and, and all the others, allow
you to do that kind of thing, without, uh, being a security issue.
So here, if you use SHA-3 or just SHAKE, it works.
And this is basically what KMAC is.
Uh, I omitted a few details, but this is basically what KMAC does.
It takes SHAKE, opens a key to the message, and it allows you to, to create a MAC out
of it.
Kind of like HMAC.
Uh, tuple hash.
So let me talk about the following problem.
Imagine I'm using one of these, uh, secure messaging app.
I have end-to-end encryption.
Um, and I'm using Alice's public key to encrypt messages to Alice.
And Alice, uh, Alice's public key is an RSA public key, so if you don't know what an RSA
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 SHA-256, uh, a hash of that key, uh, the
small part, append it to the big parts, and, uh, 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, uh, basically I'm doing this.
E is a small number in bits, and N is a very large number, something like 2,048 bits, probably.
Is that thing secure?
Again, who thinks, uh, 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, not so many people.
So the answer is that you can create a different public key that will have the same number
and 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, the modulus might be the same.
It 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, 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, the length
of the first value, and the value.
Okay.
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, 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, you, 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.
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, 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, smaller outputs.
And then finally they have a hash of all these outputs.
Yeah, it's a pretty simple construction, right?
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.
BLEG 2, one of the very fast hash functions, which is an alternative to Chaffery.
Chaffery is the standard, rock solid.
If you want something more flexible and faster than Chaffery, you have Sheck.
If you want something faster than Sheck, you have Sheck.
If you have different usages, you have TupleHash, ParallelHash, and KMAC, all right?
Here, something I didn't mention, I believe BLEG 2 also has something like ParallelHash,
something like Sheck, and so on.
If you want to know more about that, you can go on the BLEG 2 website, but my talk is
mostly focused on Chaffery.
All right.
So different things for different usage.
Now, I want to mention...
Keyak and Ketier, those are two things based on Ketchak as well, from the Ketchak team.
And those are candidates to the Caesar competition.
So the Caesar competition is an ongoing competition for authenticated encryption.
So think of AES GCM.
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 AES GCM, but maybe you'll be using one of the sponge constructions, 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 Ketchak team kind of concedes in the war of speed.
So they see that BLEG 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 Chafri, but based on Chafri.
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 kind of an animal, fictive animal, a yellow animal with like black dots.
It's very funny.
You should read it.
Anyway, it's very fast.
It's very fast.
It's very fast.
The what?
The one with Asterix and Newplace.
Asterix and Newplace?
The French comic.
The French cartoon.
The French cartoon.
Anyway, you can tell me at the end.
Basically, it's what BLEG 2 is to BLEG.
Does that mean something?
Anyway, they reduced the number of rounds of Chafri to obtain something that was way
faster and still practically secure.
So the theoretical security is...
It's 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.
Kangaroo 12 is blazing fast.
It's faster than Parallel Hash.
It's faster than SHA-1, SHA-2, Chafri, and all these constructions.
I don't know if it's faster than BLEG 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 Chafri 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 BLEG 2 or Kangaroo 12.
Again, if you want to use any of the SHAKE functions, any of Kangaroo 12, Chafri, SHAKE, etc.,
all of these can be obtained from the Ketchhack code package that you have on this page.
And this is all I have to say about Chafri and derived functions from Chafri.
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 focuses on the symmetric parts of your protocol.
And it's very sexy in the way that it only uses Ketchhack, only uses 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.
And 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 Kitschak 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 results 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.
It's 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 basically describe your protocol.
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.
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 defilment 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 a request to the server,
well, you use what they call the sendEncrypt 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 sendMac 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 these 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 receiveMac on the last 16 bytes.
And you would make sure that the Mac is OK.
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 functions you can use.
And you can use combinations of that.
If you want to rekey 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-encrypted 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 operation depends on these operations.
Before I explain to you how it 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.
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, with 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 state.
But you might have wondered,
does that look like a one-time pad or a stream cipher?
And basically, you can think of the state as a key stream,
your input as your plaintext,
and that could be the ciphertext.
So if you retrieve that output,
you can say that it's the ciphertext,
and that's how you encrypt in Strobe.
And I believe this is how Kayak and Ketier
do 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 state.
So that's how you do it.
So you're going to 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 going to key the state.
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'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 state 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.
I permute because I want to depend on the key that was absorbed,
or that was replaced in the state.
And then I XOR 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 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 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,
myhash,
myhashdavidwong,
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 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 they 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 question.
Yes?
Yeah, so this is sort of a normal,
normal developer.
Good hash function and good match.
I already have with SHA-2 and HMAC
in my standard library.
What's the most compelling reason
I should choose SHA-2
going forward over SHA-2 and HMAC?
All right, that's a good question.
My recommendation is that
if you already use SHA-2 and HMAC,
there are no real reasons to move.
If you're using,
if you're trying to choose hash functions
and authentication type,
something like MAC,
message authentication codes and so on,
you have no reason to choose SHA-2
since we have these 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 SHA-2
to do this weird MAC thing
where you have the key and the message,
then you have,
you might have a problem here.
But if you're using SHA-2 correctly,
I don't see any reason to move right now.
Yes?
It seems like there's a lot of randomness
that we can squeeze out of this
that depends on a key.
Does that mean that we can use it
as a stream cipher as well as a hash?
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, like,
pretty much generate random numbers
like a stream cipher
and then export that with your plaintext.
Right.
So this is what strobe does.
What was 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 TLS 1.3,
it's actually Shasha 20.1305
is actually a stream cipher.
Correct me if I'm wrong, but...
I mean, GCF is...
I guess what I was trying to say is
I thought people were moving away from stream ciphers
because it's so easy to screw up the protocol.
I don't know.
AES-GCM is a stream cipher.
Yeah.
So AES-GCM is also kind of a stream cipher
based on the block cipher, it's true, but...
So I don't believe people can screw up stream ciphers
more easily than...
I don't believe this is...
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...?
The next speaker isn't here yet,
so go on.
All right, all right.
Another question?
So you have a strobe
that could be used for 3D iteration.
Yeah.
How do you compare it with existing
like GPDF would be good for 3D?
So have I compared strobe to edge-cading?
HKDF or other key-derivation functions?
I have not, but it has the same properties, so...
Is there any reason
how it would go with strobe
Yeah, so the reason to use strobe
instead of edge-cading 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-cading
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.
Yeah?
I was curious to see
the advantage of using strobe.
Is that to reduce implementation errors
from verification
as it's ordered by a spot strobe?
So who uses strobe?
I'm saying what's the advantage
of compounding these functions together?
Is that to reduce the implementation errors
on the verification side?
Yeah, so it's rather a consequence
of using k-check at the core,
but it's also a consequence
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.
But that's the one advantage.
You don't see any other advantage
in terms of if you ordered it
in a certain way,
you can't have any...
You have to check the tag
as the first thing
as part of the reversing of that protocol, right?
Sorry?
Sorry, could you go up to the mic
when you're asking a question
so we have them recorded?
Oh, I can repeat the question, I guess.
But I'm not sure I understood it.
So...
So you're saying you have to verify the MAC
and it's, like, separated?
It's not like...
I'm saying there's definitely
less implementation issues
within crypto for...
Okay.
And I was saying,
does it have any orders
that it's going to use?
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 an unauthenticated...
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 to send authenticated encrypts
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, right?
So you mentioned lots of different hash functions
derived from Chalk3 or Shape
that can be used for different purposes.
Is there some kind of abstraction
like lib-sodium that sort of abstracts away
the particular cipher or hash that's being used
to just call it an encrypted hash?
Is there some analogous API
for all the different hash functions
that sort of composes
the different derived hash functions
in a way that's easier to use and understand?
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 functions.
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 Shake.
It's an extendable output function.
It derives from parallel hash.
You can parallelize it.
And it derives from Chaffery.
You can hash anything.
So Kangaroo 12 is kind of the easy API to use.
I need to drag you off-stage.
I'm sorry.
Thank you.