1
00:00:00,000 --> 00:00:05,760
Hash function. I'm going to start with the timeline. And I have some old hash function

2
00:00:05,760 --> 00:00:12,560
like Sneferu, MD2, MD4, up to recent functions or more recent functions like SHA-1 and SHA-2.

3
00:00:13,380 --> 00:00:17,680
And I want to make a point here. I took this timeline from this website. So if you want

4
00:00:17,680 --> 00:00:23,880
to know exactly what's going on here, you can check the website of Valerie Aurora. But

5
00:00:23,880 --> 00:00:28,860
I want to make a point here that if we look at the past hash functions in the previous

6
00:00:28,860 --> 00:00:34,740
years, we've seen a pattern. And the pattern is that we usually see some green. And at

7
00:00:34,740 --> 00:00:39,680
the end, we usually see some red. So the green usually means that it's considered strong

8
00:00:39,680 --> 00:00:44,940
for a number of years. People use those hash functions. And the red usually means that

9
00:00:44,940 --> 00:00:51,640
it's broken. So broken here usually means that we found a collision. Collision meaning

10
00:00:51,640 --> 00:00:56,680
that, for example, you took two different words, the word mother, the word father. You

11
00:00:56,680 --> 00:00:58,680
hash them with the same hash function, maybe.

12
00:00:58,860 --> 00:01:06,600
MD5. And you get the same output. So a collision is very, very bad. You usually don't want

13
00:01:06,600 --> 00:01:10,960
to find that on a cryptographically secure hash function. And as soon as you find one

14
00:01:10,960 --> 00:01:14,700
collision, you usually say that the hash function is broken.

15
00:01:15,840 --> 00:01:20,760
So this is what happened here. And you might have heard of the SHA-1 collision. Ellie talked

16
00:01:20,760 --> 00:01:28,660
about that at Black Hat if you were there a few days ago. And pretty much a lot of people

17
00:01:28,860 --> 00:01:32,940
think that because of that, we cannot build cryptography that can withstand the test of

18
00:01:32,940 --> 00:01:38,440
time. So this is not quite true. And this is kind of a pattern that you see not only

19
00:01:39,480 --> 00:01:46,220
on hash functions, but also SSL and TLS. These things have gotten broken over the years.

20
00:01:46,880 --> 00:01:50,940
And this is mostly because we didn't really know how to build these. Especially if you

21
00:01:50,940 --> 00:01:56,060
look at SSL and TLS, the involvement of the cryptographic community was almost inexistent.

22
00:01:56,220 --> 00:01:58,840
So this is something that is changing. And in TLS, we're going to have to do something

23
00:01:58,840 --> 00:02:04,680
like 1.3. There is a huge involvement from the cryptographic community. And this is

24
00:02:04,680 --> 00:02:06,920
kind of unheard of. And this is pretty good.

25
00:02:08,780 --> 00:02:12,600
So here, another thing that kind of came out of that is that when you look at SHA-2,

26
00:02:13,140 --> 00:02:18,460
it's still considered strong nowadays. But a lot of people thought, what if it breaks?

27
00:02:19,240 --> 00:02:26,020
So SHA-2 is based on the same Merkle-Damgaard construction, which is also the core construction

28
00:02:26,020 --> 00:02:28,820
of SHA-1, SHA-0, MD5, MD4, MD5, MD5, MD5, MD5, MD5, MD5, MD5, MD5, MD5, MD5, MD5, MD5, MD5, MD5,

29
00:02:28,820 --> 00:02:35,220
etc. And all those hash functions have been broken, right? So we might wonder, what if

30
00:02:35,220 --> 00:02:42,680
SHA-2 also follows the same fate? Also, if SHA-2 breaks one day, well, everything uses

31
00:02:42,680 --> 00:02:49,720
SHA-2. SHA-2 is used all over the place as the hash function. So with that in mind,

32
00:02:50,280 --> 00:02:55,480
the NIST, an American organization, decided to come up with a competition for SHA-3,

33
00:02:55,600 --> 00:02:58,020
the next standard for a hash function.

34
00:02:58,020 --> 00:03:05,060
That could be used as a replacement in case SHA-2 would come to a bad point.

35
00:03:06,360 --> 00:03:13,440
So the SHA-3 competition lasted five years. It was started in 2007. It had 64 candidates

36
00:03:13,440 --> 00:03:20,680
from all over the world. So previously, SHA-2 and SHA-1 were not competitions, so SHA-3

37
00:03:20,680 --> 00:03:26,840
was new. Three rounds, and the winner was Ketchak.

38
00:03:26,920 --> 00:03:27,220
Okay.

39
00:03:27,860 --> 00:03:35,420
So Ketchak finally won in 2012. Other candidates that didn't win but made it to the third

40
00:03:35,420 --> 00:03:40,860
round, the last round, were Blake, Grostel, JH, and Skyn. I'm not sure how to pronounce

41
00:03:40,860 --> 00:03:46,160
them, but it wasn't that they were not secure. It's mostly because we only had one spot,

42
00:03:46,340 --> 00:03:52,740
and Ketchak was quite different and quite supported, so it won. But remember Blake because

43
00:03:52,740 --> 00:03:55,200
I'll be talking about that hash function after.

44
00:03:57,220 --> 00:04:03,940
So I'll use the next slide to kind of explain to you how Ketchak works. Ketchak is a sponge

45
00:04:03,940 --> 00:04:10,140
construction, so SHA-3 is a sponge construction, and the sponges were invented as part of the

46
00:04:10,140 --> 00:04:15,900
competition, SHA-3. At its core, it uses a permutation, so we'll say that it's a permutation-based

47
00:04:15,900 --> 00:04:16,560
cryptography.

48
00:04:17,420 --> 00:04:23,300
If you don't know what a permutation is, you can think of AES with a fixed key. It takes

49
00:04:23,300 --> 00:04:27,200
all the possible inputs of 128 bytes.

50
00:04:27,220 --> 00:04:33,220
And it gives you all the possible outputs of 128 bits, right? So you have one plaintext,

51
00:04:33,300 --> 00:04:37,900
one ciphertext. There is a map. There is a mapping. So that's a permutation, and the

52
00:04:37,900 --> 00:04:44,940
same thing here. You have an input of, for SHA-3, 1600 bits, and an output of 1600 bits.

53
00:04:47,140 --> 00:04:54,580
So here we'll start by having zeros for the inputs. You can think of that as an initialization

54
00:04:54,580 --> 00:04:54,960
vector.

55
00:04:55,500 --> 00:04:57,120
And we'll separate the inputs.

56
00:04:57,120 --> 00:05:01,240
We'll separate the inputs into two parts. The first part, called the rate, I'll call

57
00:05:01,240 --> 00:05:08,180
the public part of the inputs. And the second part, called the capacity, I'll call the secret

58
00:05:08,180 --> 00:05:14,860
part of the inputs. And it's kind of an arbitrary division. You can place it wherever you want,

59
00:05:14,940 --> 00:05:20,260
and you'll see that in SHA-3, you have different parameters where the secret part is larger

60
00:05:20,260 --> 00:05:24,660
or smaller. And the output is divided into two parts, the same two parts.

61
00:05:26,220 --> 00:05:27,100
So I'm going to show you how to do that.

62
00:05:27,100 --> 00:05:31,020
I'm calling that the public parts above and the secret parts on the bottom, and this is

63
00:05:31,020 --> 00:05:35,100
for a reason. We usually only touch the public parts and the secret parts we don't really

64
00:05:35,100 --> 00:05:35,840
want to touch.

65
00:05:37,720 --> 00:05:41,140
So we're hashing a message, right? So what we do is that we take our message

66
00:05:41,640 --> 00:05:49,520
and we XOR it with our state, which is the public part of the sponge. If our message

67
00:05:49,520 --> 00:05:53,720
is bigger than this public part, which is maybe, like, 1300 bits, something like that,

68
00:05:54,840 --> 00:05:57,080
then you take the next part of the message and you go and you have the public part. Well,

69
00:05:57,100 --> 00:06:01,340
and you XOR it with, after you permute that state,

70
00:06:01,960 --> 00:06:03,440
you XOR it with the public part.

71
00:06:03,760 --> 00:06:05,340
And if your message is a bit longer,

72
00:06:05,500 --> 00:06:07,920
you permute again and you XOR it

73
00:06:08,560 --> 00:06:10,420
with the public part again.

74
00:06:10,940 --> 00:06:12,180
I'm not talking about padding,

75
00:06:12,300 --> 00:06:14,840
but it's basically like block ciphers or any of that.

76
00:06:14,960 --> 00:06:17,000
You usually have a padding so that you can reach

77
00:06:17,000 --> 00:06:20,380
the block size or the size of the public part.

78
00:06:22,380 --> 00:06:23,720
So, and you permute.

79
00:06:23,720 --> 00:06:26,380
So this is how you get the message

80
00:06:26,380 --> 00:06:27,980
into this sponge construction.

81
00:06:29,180 --> 00:06:30,500
And it's called absorbing.

82
00:06:30,980 --> 00:06:31,820
Makes sense, right?

83
00:06:31,880 --> 00:06:32,340
It's a sponge.

84
00:06:32,520 --> 00:06:33,640
So you absorb the message.

85
00:06:34,660 --> 00:06:36,660
And once you want an output,

86
00:06:36,820 --> 00:06:38,560
once you want your digest, your hash,

87
00:06:38,740 --> 00:06:41,940
what you do is that you take the public part, right?

88
00:06:41,980 --> 00:06:42,320
It's public.

89
00:06:42,600 --> 00:06:44,360
So you really don't touch the secret part,

90
00:06:44,460 --> 00:06:47,120
but you can just use the public part,

91
00:06:47,200 --> 00:06:50,060
which might be 1,300 bits or so for Chaffery.

92
00:06:51,600 --> 00:06:53,400
And if it's not enough,

93
00:06:53,460 --> 00:06:53,700
you permute.

94
00:06:53,700 --> 00:06:56,340
And you continue using the public part

95
00:06:56,340 --> 00:06:58,280
and you append that to your digest.

96
00:06:58,940 --> 00:07:01,420
And if it's not enough, you permute and so on.

97
00:07:01,760 --> 00:07:03,620
And this is called the squeezing part.

98
00:07:04,080 --> 00:07:04,980
Makes sense, right?

99
00:07:05,040 --> 00:07:07,540
You absorb your message and after when you need the output,

100
00:07:07,620 --> 00:07:08,260
you just squeeze it.

101
00:07:11,540 --> 00:07:15,160
So the Kitschak team gave a paper proof of this.

102
00:07:15,320 --> 00:07:17,080
So basically this is secure

103
00:07:17,800 --> 00:07:21,480
as long as the underlying permutation is secure.

104
00:07:23,700 --> 00:07:26,500
How can we prove that the underlying permutation is secure?

105
00:07:26,680 --> 00:07:27,580
Well, we don't really know.

106
00:07:27,700 --> 00:07:30,420
We don't have good ways of doing that.

107
00:07:30,480 --> 00:07:32,940
The only way we know how to do that is to try to break it.

108
00:07:33,580 --> 00:07:35,260
So for five years, pretty much,

109
00:07:35,320 --> 00:07:37,400
the Chaffery competition was just cryptanalysis

110
00:07:37,400 --> 00:07:40,420
after cryptanalysis trying to break this permutation.

111
00:07:41,780 --> 00:07:45,220
So in Chaffery, this permutation is just, again,

112
00:07:45,300 --> 00:07:48,800
you can think of it like an AES kind of thing

113
00:07:48,800 --> 00:07:52,700
where AES has like, what, 10 rounds for one of its variants.

114
00:07:52,700 --> 00:07:56,580
So Chaffery has 24 rounds of a bunch of steps

115
00:07:56,580 --> 00:08:00,820
that you apply on the input, on the state.

116
00:08:03,040 --> 00:08:05,380
So Chaffery or Kitschak received

117
00:08:05,380 --> 00:08:07,740
a huge amount of cryptanalysis.

118
00:08:07,920 --> 00:08:09,560
So this is a page they have where they list

119
00:08:10,060 --> 00:08:11,980
the amount of cryptanalysis that they have

120
00:08:12,620 --> 00:08:16,300
and it's a lot, so that's mostly why Kitschak

121
00:08:16,300 --> 00:08:18,720
was chosen as the new Chaffery.

122
00:08:19,660 --> 00:08:22,060
Why did it receive so much cryptanalysis?

123
00:08:22,100 --> 00:08:22,680
Why did it receive so much cryptanalysis?

124
00:08:22,680 --> 00:08:26,500
Maybe you have a clue in the list of its inventors.

125
00:08:26,700 --> 00:08:29,320
So inventors of Ketchak are Guido Bertoni,

126
00:08:29,500 --> 00:08:32,520
Johan Daman, Michael Peters, and Gilles Van Asch.

127
00:08:32,860 --> 00:08:34,620
I'm not too sure how to pronounce their name,

128
00:08:34,760 --> 00:08:38,200
but those are Italian and Belgian people.

129
00:08:40,600 --> 00:08:43,940
One of them, Johan Daman, is the author of AES.

130
00:08:44,320 --> 00:08:46,320
So that might be why so many people

131
00:08:46,320 --> 00:08:48,280
were really interested into trying to break it.

132
00:08:50,000 --> 00:08:51,700
Anyway, let's look at the timeline.

133
00:08:52,680 --> 00:08:55,860
It's a hash-free competition, right, from 2007 to 2012.

134
00:08:56,860 --> 00:08:59,100
At the end, Ketchak becomes the winner,

135
00:08:59,640 --> 00:09:01,120
but it's not standardized yet,

136
00:09:01,280 --> 00:09:03,300
just nominated as the winner.

137
00:09:04,760 --> 00:09:06,620
And at this time also, Blake,

138
00:09:06,840 --> 00:09:09,240
which was one of the non-winner of the last round,

139
00:09:09,400 --> 00:09:12,520
decides to come up with a new hash function called Blake2.

140
00:09:13,420 --> 00:09:14,920
And pretty much what they did is that

141
00:09:14,920 --> 00:09:16,800
they looked at the cryptanalysis that they received

142
00:09:16,800 --> 00:09:19,900
during the competition, and they said,

143
00:09:20,020 --> 00:09:21,860
well, we have a number of rounds,

144
00:09:21,860 --> 00:09:24,160
like Ketchak, like AES, blah, blah, blah.

145
00:09:25,300 --> 00:09:28,420
And the security margin that we have is actually pretty big,

146
00:09:28,480 --> 00:09:30,480
so we're gonna reduce the number of rounds we have

147
00:09:30,480 --> 00:09:31,360
to make it faster.

148
00:09:32,080 --> 00:09:33,600
They made a number of changes,

149
00:09:33,740 --> 00:09:34,980
but this was the biggest change,

150
00:09:35,600 --> 00:09:37,980
and it actually made Blake2 very, very fast.

151
00:09:39,040 --> 00:09:40,820
So they have this diagram on their website,

152
00:09:41,440 --> 00:09:44,040
and you can see that Blake2 is faster than SHA-1,

153
00:09:44,640 --> 00:09:48,560
than MD5, than SHA-2, and a bunch of other hash functions,

154
00:09:48,740 --> 00:09:49,720
and actually, SHA-free.

155
00:09:49,820 --> 00:09:50,620
And I'll come back.

156
00:09:51,860 --> 00:09:52,380
I'll talk about this slide after.

157
00:09:52,600 --> 00:09:54,840
But basically, Blake2 was really, really fast.

158
00:09:55,540 --> 00:09:56,580
And people liked that.

159
00:09:57,220 --> 00:09:59,720
It looked secure because during the competition,

160
00:09:59,860 --> 00:10:02,180
it received a substantial amount of cryptanalysis,

161
00:10:02,940 --> 00:10:04,500
and people started using it.

162
00:10:04,680 --> 00:10:07,100
So this is a list, a non-existent list

163
00:10:07,100 --> 00:10:09,960
of different projects that use Blake2.

164
00:10:11,080 --> 00:10:12,680
In them, you can see WireGuard,

165
00:10:12,740 --> 00:10:14,740
which is kind of the next generation VPN

166
00:10:15,700 --> 00:10:17,400
that used Blake2 at its core.

167
00:10:18,940 --> 00:10:21,840
WireGuard also used Noise, which is a program

168
00:10:21,840 --> 00:10:23,340
and protocol framework that you can use

169
00:10:23,340 --> 00:10:24,780
to build something like TLS.

170
00:10:26,760 --> 00:10:28,580
So I didn't introduce myself,

171
00:10:28,800 --> 00:10:31,040
but I'm a security consultant at NCC Group,

172
00:10:31,180 --> 00:10:33,840
and I see a lot of custom-made TLS protocols,

173
00:10:34,140 --> 00:10:36,320
proprietary TLS thingies,

174
00:10:36,480 --> 00:10:38,240
and usually they're looking for trouble,

175
00:10:38,400 --> 00:10:42,820
and that's what the recommendation is usually to use Noise.

176
00:10:42,940 --> 00:10:44,520
If you really don't want to use TLS

177
00:10:45,100 --> 00:10:46,980
because it's cumbersome, because it's too big,

178
00:10:47,040 --> 00:10:50,220
because it's not secure, whatever your good or bad reason is,

179
00:10:50,880 --> 00:10:51,820
Noise is usually the answer.

180
00:10:51,840 --> 00:10:56,240
So Noise, at its center, at its core,

181
00:10:56,340 --> 00:10:58,120
used Blake2 as one of its hash function.

182
00:11:00,360 --> 00:11:03,000
Argon2, if you don't know how to store passwords,

183
00:11:03,320 --> 00:11:05,740
we have a state-of-the-art password-hashing function,

184
00:11:06,580 --> 00:11:07,720
which is called Argon2,

185
00:11:07,880 --> 00:11:09,900
which came out of the password-hashing competition

186
00:11:09,900 --> 00:11:12,660
that ended up last year, I believe,

187
00:11:13,540 --> 00:11:15,800
and it uses Blake2 at its core.

188
00:11:17,180 --> 00:11:20,740
Last but not least, Libsodium is the crypto library

189
00:11:20,740 --> 00:11:22,080
we usually recommend.

190
00:11:22,700 --> 00:11:27,160
It's based on Salt, and it pretty much has very good APIs,

191
00:11:27,320 --> 00:11:28,520
and that's why we recommend it.

192
00:11:28,920 --> 00:11:31,980
It's very hard to make a mistake when you use it,

193
00:11:32,540 --> 00:11:34,760
and if you want to hash something,

194
00:11:35,400 --> 00:11:36,580
there is something called hash.

195
00:11:36,820 --> 00:11:38,720
It doesn't tell you what it is, it's just called hash,

196
00:11:39,300 --> 00:11:40,540
and basically it's Blake2.

197
00:11:42,000 --> 00:11:43,820
All right, so a lot of things use Blake2.

198
00:11:44,040 --> 00:11:45,200
Let's go back to Chaffery.

199
00:11:46,160 --> 00:11:50,100
So Chaffery finally was standardized three years after,

200
00:11:50,780 --> 00:11:53,160
at the end of the competition, in 2015,

201
00:11:53,560 --> 00:11:55,940
in this document called FIPS 202.

202
00:11:56,340 --> 00:11:57,700
So you don't have to remember the name.

203
00:11:57,760 --> 00:11:59,020
If you want to see the standard,

204
00:11:59,080 --> 00:12:01,660
just Google Chaffery standard, that's enough.

205
00:12:03,500 --> 00:12:07,140
So it came out in 2015, and in that time, right,

206
00:12:07,180 --> 00:12:10,200
in three years, Blake2 had the time to take over the market.

207
00:12:12,140 --> 00:12:15,440
Nonetheless, they came out with a reference implementation.

208
00:12:15,560 --> 00:12:18,700
If you want to use Chaffery, this is the Ketchak code package.

209
00:12:19,460 --> 00:12:20,720
I'll have that slide again, as well.

210
00:12:20,720 --> 00:12:23,080
At the end, but this is a reference implementation in C,

211
00:12:23,180 --> 00:12:23,720
and it's pretty good.

212
00:12:24,720 --> 00:12:26,900
There's another implementation that I want to tell you about.

213
00:12:27,200 --> 00:12:28,260
It's a Twitter implementation,

214
00:12:28,820 --> 00:12:30,720
and it's basically, if you go on the Twitter account,

215
00:12:31,440 --> 00:12:33,080
there are nine tweets, I believe,

216
00:12:33,240 --> 00:12:35,240
and if you concatenate those nine tweets,

217
00:12:35,360 --> 00:12:37,700
you get an implementation in C of Chaffery.

218
00:12:39,540 --> 00:12:40,800
I'm not telling you to use it,

219
00:12:40,860 --> 00:12:42,620
but it's pretty interesting how small

220
00:12:43,500 --> 00:12:44,960
the final implementation is,

221
00:12:45,880 --> 00:12:47,980
and it could lead you to believe it's easy to implement.

222
00:12:48,260 --> 00:12:49,300
It's not easy to implement,

223
00:12:49,500 --> 00:12:50,600
but they still did it,

224
00:12:50,600 --> 00:12:51,160
and they did it in nine tweets.

225
00:12:52,960 --> 00:12:55,240
Anyway, let's look at this diagram from Blake2.

226
00:12:55,320 --> 00:12:56,640
Remember, Blake2 is blazing fast,

227
00:12:57,220 --> 00:13:00,200
and you can see at the end that Chaffery is kind of slow.

228
00:13:01,040 --> 00:13:02,760
So Chaffery was chosen,

229
00:13:03,780 --> 00:13:05,380
one of the reasons it was chosen was

230
00:13:05,860 --> 00:13:08,080
because it was the fastest of the hash functions

231
00:13:08,500 --> 00:13:10,940
in hardware, but not in software.

232
00:13:11,620 --> 00:13:12,760
This doesn't mean it's slow,

233
00:13:12,900 --> 00:13:14,800
but it means that if you really care about speed,

234
00:13:15,020 --> 00:13:16,480
if you're a big player,

235
00:13:17,060 --> 00:13:19,260
somebody like Google, Facebook, CloudFlare,

236
00:13:19,260 --> 00:13:21,380
you really want to optimize your speed,

237
00:13:21,620 --> 00:13:22,920
this might be an issue.

238
00:13:24,660 --> 00:13:27,400
So fast in the hardware, but not so much in software.

239
00:13:27,680 --> 00:13:29,260
And you might think that, well,

240
00:13:29,360 --> 00:13:31,580
Intel will one day implement it

241
00:13:31,580 --> 00:13:33,040
or support it in the hardware,

242
00:13:33,540 --> 00:13:34,540
and you might be right,

243
00:13:34,620 --> 00:13:37,360
but if you look at the past support of Intel

244
00:13:37,360 --> 00:13:39,900
for hash functions and cryptographic functions,

245
00:13:40,540 --> 00:13:42,800
it usually takes a lot of time,

246
00:13:42,880 --> 00:13:43,880
so don't hold your breath.

247
00:13:44,700 --> 00:13:46,860
And also, we've seen that speed drives adoption.

248
00:13:47,020 --> 00:13:49,240
This is clearly true,

249
00:13:49,260 --> 00:13:50,020
and this is true for BLEG-2,

250
00:13:50,820 --> 00:13:52,600
but this is true for, for example,

251
00:13:52,660 --> 00:13:54,760
elliptic curves with the curve 25519.

252
00:13:55,620 --> 00:13:59,020
This is true for authenticated ciphers,

253
00:13:59,060 --> 00:14:01,660
for example, Chacha 20, Poly 1305,

254
00:14:02,320 --> 00:14:03,900
which is very fast in software,

255
00:14:04,560 --> 00:14:06,640
which is the replacement for AES-GCM,

256
00:14:06,660 --> 00:14:10,520
and which will be in TLS 1.3 as one of the new cipher.

257
00:14:11,220 --> 00:14:13,060
And if right now you have an Android phone

258
00:14:13,060 --> 00:14:14,520
and you use it to connect to Google,

259
00:14:14,660 --> 00:14:15,440
that's what you use.

260
00:14:15,480 --> 00:14:17,220
You use Chacha 20, Poly 1305,

261
00:14:17,880 --> 00:14:19,240
just because it's fast in software.

262
00:14:20,760 --> 00:14:22,720
Another one of these, last example,

263
00:14:22,900 --> 00:14:26,380
is if you look at TLS 1.3, if you look at QUIC,

264
00:14:26,540 --> 00:14:29,740
if you look at these kind of modern protocols

265
00:14:31,560 --> 00:14:33,300
that kind of look like TLS 1.3,

266
00:14:33,420 --> 00:14:36,140
you have this new feature called Zero RTT,

267
00:14:36,740 --> 00:14:38,620
which stands for Zero Roundtrip,

268
00:14:39,040 --> 00:14:41,420
and it basically allows you to encrypt data.

269
00:14:42,060 --> 00:14:43,940
So in TLS, right, you have the handshake,

270
00:14:44,060 --> 00:14:45,300
and then you can encrypt your data,

271
00:14:46,220 --> 00:14:48,980
but this Zero RTT thing allows you to encrypt your data

272
00:14:48,980 --> 00:14:51,800
in the very first message as part of your handshake.

273
00:14:52,280 --> 00:14:54,220
And it allows you to be very, very fast,

274
00:14:54,420 --> 00:14:55,860
and that's why big players like it.

275
00:14:56,480 --> 00:14:58,620
But the security of it is kind of shaky,

276
00:14:58,820 --> 00:15:01,720
which made it the most controversial, I believe,

277
00:15:01,780 --> 00:15:03,160
feature of TLS 1.3.

278
00:15:03,500 --> 00:15:04,940
So if you look at the mailing list,

279
00:15:05,080 --> 00:15:07,080
there is a lot of discussions around that.

280
00:15:07,600 --> 00:15:10,160
And I believe if the big players didn't really

281
00:15:10,160 --> 00:15:13,020
want to optimize and didn't want this big speed,

282
00:15:13,660 --> 00:15:16,280
we wouldn't have this feature in TLS 1.3.

283
00:15:18,980 --> 00:15:21,220
All right, so in the next couple of slides,

284
00:15:21,380 --> 00:15:26,440
I'm going to explain to you why Chaffery is slowish.

285
00:15:28,840 --> 00:15:30,140
So let's talk about bit security.

286
00:15:31,920 --> 00:15:35,060
What is the bit security of AES-128?

287
00:15:35,720 --> 00:15:36,700
Well, it's pretty easy.

288
00:15:36,820 --> 00:15:39,000
It's around 128 bits.

289
00:15:39,620 --> 00:15:41,620
That means that if you want to break AES,

290
00:15:42,520 --> 00:15:46,140
approximately you have to do 2 to the 128 operations.

291
00:15:46,600 --> 00:15:48,260
So that would be 2 to the 128.

292
00:15:48,560 --> 00:15:48,960
OK.

293
00:15:48,980 --> 00:15:50,280
That's the encryption of AES.

294
00:15:52,000 --> 00:15:55,580
Now, what is the bit security of AES-256?

295
00:15:55,820 --> 00:15:57,860
Well, it's 256 bits.

296
00:15:59,380 --> 00:16:02,320
And this is usually the kind of security you want.

297
00:16:02,480 --> 00:16:05,360
It's either 128, which is what most people use,

298
00:16:05,600 --> 00:16:10,440
or if you're really paranoid, if you really care too much,

299
00:16:10,520 --> 00:16:13,040
or if you want to market your application as military grade

300
00:16:13,040 --> 00:16:16,300
encryption, you usually choose the latest one, the latter.

301
00:16:18,320 --> 00:16:20,440
Now, what about SHA-256?

302
00:16:21,160 --> 00:16:24,800
If we look at the bit security of SHA-256

303
00:16:24,800 --> 00:16:28,360
against pre-image attacks, pre-image attacks

304
00:16:28,360 --> 00:16:29,820
are not collision attacks, right?

305
00:16:29,900 --> 00:16:31,080
We're not trying to find a collision.

306
00:16:31,680 --> 00:16:35,580
But rather, we see the hash of something.

307
00:16:35,800 --> 00:16:38,060
So you can imagine a dump of hash password.

308
00:16:38,560 --> 00:16:41,540
Maybe they hash the password with MD5 or something like that.

309
00:16:41,660 --> 00:16:44,560
And you're trying to find the original passwords out

310
00:16:44,560 --> 00:16:45,480
of the hashes.

311
00:16:45,800 --> 00:16:46,280
OK.

312
00:16:46,300 --> 00:16:47,300
So that's a pre-image attack.

313
00:16:48,300 --> 00:16:52,160
So the security for this kind of attacks for SHA-256

314
00:16:52,890 --> 00:16:57,200
is actually 256 bits, which is already very large.

315
00:16:58,200 --> 00:17:00,660
Now, if you look at the bit security of SHA-512,

316
00:17:00,980 --> 00:17:04,400
you can guess it's 512 bits of security

317
00:17:04,990 --> 00:17:06,820
against that kind of attack, which is absurd.

318
00:17:07,080 --> 00:17:09,480
It's a very big number, and nobody really

319
00:17:09,480 --> 00:17:10,640
needs that kind of security.

320
00:17:12,440 --> 00:17:15,600
Now, SHA-2 has that kind of security not

321
00:17:15,600 --> 00:17:17,480
because they made bad decisions,

322
00:17:17,740 --> 00:17:19,660
but it's mostly because of how it's designed.

323
00:17:20,640 --> 00:17:24,180
It's just a nice property, I guess, of SHA-2.

324
00:17:24,320 --> 00:17:26,700
The way it's designed brings you that amount of security.

325
00:17:28,380 --> 00:17:30,900
Now, the NIST wanted something with SHA-3

326
00:17:30,900 --> 00:17:33,620
that was something secure and something

327
00:17:33,620 --> 00:17:36,200
you could use as a drop-in replacement for SHA-2.

328
00:17:36,720 --> 00:17:38,980
So they decided to have the same kind of security.

329
00:17:39,800 --> 00:17:44,860
And SHA-3 512 actually provides 512 bits of security.

330
00:17:45,100 --> 00:17:45,580
OK.

331
00:17:45,600 --> 00:17:46,480
Which, again, is absurd.

332
00:17:46,940 --> 00:17:49,560
And here, it doesn't really make sense, because they could

333
00:17:49,560 --> 00:17:53,760
have had less and could have mirrored the security of AES

334
00:17:53,760 --> 00:17:57,300
with 128-bit security and 256-bit security.

335
00:17:57,980 --> 00:17:59,540
But it chose not to do it.

336
00:18:01,200 --> 00:18:03,560
So this was kind of a weird decision,

337
00:18:03,800 --> 00:18:05,340
and it led SHA-3 to be slow.

338
00:18:07,000 --> 00:18:08,720
Basically, the explanation, if you remember,

339
00:18:09,000 --> 00:18:10,380
SHA-3 has these public parts.

340
00:18:10,480 --> 00:18:12,600
The sponge has a public part and a secret part.

341
00:18:13,600 --> 00:18:15,140
And to attend this kind of security,

342
00:18:15,140 --> 00:18:16,800
they made the secret parts larger.

343
00:18:17,780 --> 00:18:18,620
What does it mean?

344
00:18:18,760 --> 00:18:22,680
It means that you can store less message in your public parts,

345
00:18:22,740 --> 00:18:23,260
because it's smaller.

346
00:18:23,900 --> 00:18:25,320
And also, when you get the outputs,

347
00:18:25,560 --> 00:18:27,460
you can use less, because this part is smaller.

348
00:18:28,500 --> 00:18:32,600
So you have to use more permutations in the end

349
00:18:32,600 --> 00:18:33,360
to hash a message.

350
00:18:34,860 --> 00:18:35,740
So yeah.

351
00:18:36,400 --> 00:18:40,740
Another reason might be that a lot of people

352
00:18:40,740 --> 00:18:44,160
have lost their trust in the NIST organization, mostly

353
00:18:44,160 --> 00:18:46,580
because of backdoors and duality and that kind of stuff.

354
00:18:46,940 --> 00:18:48,980
And so they might have wanted to show people

355
00:18:48,980 --> 00:18:52,600
that they were not going to mess around with SHA-3

356
00:18:52,600 --> 00:18:54,860
and actually make something that was very secure.

357
00:18:55,640 --> 00:18:57,160
And if you look at it, they actually

358
00:18:57,160 --> 00:18:58,780
increased the number of rounds.

359
00:18:59,540 --> 00:19:01,560
Kitschak was not 24 rounds in the beginning,

360
00:19:01,700 --> 00:19:04,540
and they increased it to 24 to make it even more secure,

361
00:19:05,180 --> 00:19:07,200
which made it even more slow.

362
00:19:09,220 --> 00:19:11,000
Anyway, this is the explanation.

363
00:19:11,580 --> 00:19:14,140
Now, we can ask the question, what's this?

364
00:19:14,140 --> 00:19:15,420
Where is SHA-3 being used?

365
00:19:16,920 --> 00:19:18,180
Well, I'll give you some hints.

366
00:19:18,420 --> 00:19:20,900
You have to think of crypto-friendly companies.

367
00:19:21,840 --> 00:19:27,760
You have to think of modern or recent bleeding-edge companies.

368
00:19:28,580 --> 00:19:30,780
And if you haven't picked up the answer yet,

369
00:19:30,920 --> 00:19:34,120
the answer is blockchain, cryptocurrencies, Bitcoin,

370
00:19:34,400 --> 00:19:35,020
and that kind of stuff.

371
00:19:36,200 --> 00:19:38,440
Usually, a new one comes up every day,

372
00:19:38,520 --> 00:19:42,060
so they can afford to use the less hash functions.

373
00:19:43,980 --> 00:19:45,900
And this is what it is.

374
00:19:46,020 --> 00:19:50,720
Actually, I've looked at their forums, some cryptocurrencies

375
00:19:50,720 --> 00:19:52,940
forums, and I've seen that some of the people there

376
00:19:52,940 --> 00:19:55,260
market their last cryptocurrencies,

377
00:19:55,620 --> 00:19:59,140
their new cryptocurrencies, by saying, oh, it uses SHA-3.

378
00:19:59,260 --> 00:20:00,160
Look at it.

379
00:20:00,180 --> 00:20:00,560
It's shiny.

380
00:20:00,760 --> 00:20:03,060
It's beautiful, et cetera.

381
00:20:06,240 --> 00:20:09,300
So just one problem I'll mention is that they

382
00:20:09,300 --> 00:20:10,220
say they use SHA-3.

383
00:20:10,740 --> 00:20:11,860
Some of them will.

384
00:20:11,860 --> 00:20:15,040
Some of them will use, well, I think some of them

385
00:20:15,040 --> 00:20:17,420
don't use SHA-3, but a derived function from SHA-3.

386
00:20:17,520 --> 00:20:19,640
And also, some of them started using SHA-3

387
00:20:19,640 --> 00:20:20,860
before it was standardized.

388
00:20:21,220 --> 00:20:23,440
And so they use a different number of rounds,

389
00:20:25,020 --> 00:20:26,460
which is not a problem by itself.

390
00:20:26,620 --> 00:20:29,260
But if they try to interact one day, it will be a problem.

391
00:20:31,120 --> 00:20:34,940
All right, so let's go back to the FIPS publication, which

392
00:20:34,940 --> 00:20:36,380
has SHA-3 inside of it.

393
00:20:37,000 --> 00:20:40,680
And I kind of didn't tell you the whole story.

394
00:20:40,680 --> 00:20:43,340
This standard standardized SHA-3,

395
00:20:43,420 --> 00:20:46,640
but it also standardized something new called SHAKE.

396
00:20:48,480 --> 00:20:49,680
SHAKE is XOF.

397
00:20:50,080 --> 00:20:51,880
It's an extendable output function.

398
00:20:52,500 --> 00:20:53,360
It's something new.

399
00:20:53,940 --> 00:20:56,080
And basically, I have this picture, so like that.

400
00:20:56,720 --> 00:20:59,500
When you'll try to think about what David talked about today,

401
00:20:59,640 --> 00:21:00,820
you'll try to think about that picture.

402
00:21:01,000 --> 00:21:02,700
You can also think about me shaking.

403
00:21:04,000 --> 00:21:05,180
And what is XOF?

404
00:21:05,300 --> 00:21:07,460
Well, XOF is an extendable output function.

405
00:21:07,880 --> 00:21:10,660
It's basically a hash, which has a new name.

406
00:21:10,660 --> 00:21:11,400
It's an infinite output.

407
00:21:12,160 --> 00:21:15,420
So pretty much, you can decide what length your output is.

408
00:21:15,580 --> 00:21:19,580
You can decide for your output to be a very, very long length,

409
00:21:19,700 --> 00:21:21,040
or it could be one byte.

410
00:21:21,240 --> 00:21:22,880
Well, don't do that, because it's not secure.

411
00:21:23,080 --> 00:21:25,760
But theoretically, you could choose it to be one byte.

412
00:21:27,480 --> 00:21:29,220
It also has better parameters.

413
00:21:29,760 --> 00:21:33,740
So it has a 128-bit version of SHAKE and a SHAKE 256,

414
00:21:34,200 --> 00:21:37,540
which provides 256 bit of security, which

415
00:21:37,540 --> 00:21:38,880
make it faster than SHA-3.

416
00:21:40,660 --> 00:21:42,900
That's one of the recommendation I'll make today.

417
00:21:43,020 --> 00:21:46,580
If you want to use SHA-3, I think

418
00:21:46,580 --> 00:21:47,960
it's a better choice to use SHAKE.

419
00:21:48,260 --> 00:21:49,620
It's exactly the same construction,

420
00:21:49,860 --> 00:21:53,480
except that it has standard parameters, and it's faster.

421
00:21:55,580 --> 00:21:58,000
Although, I'll still say that SHA-3 is a standard.

422
00:21:58,160 --> 00:22:00,840
It's rock solid, and it's good for people

423
00:22:00,840 --> 00:22:03,800
who don't really know what hash functions they can use.

424
00:22:03,940 --> 00:22:06,040
They can choose Google the standard, and the standard

425
00:22:06,040 --> 00:22:06,560
is here.

426
00:22:08,560 --> 00:22:10,120
So this is really interesting.

427
00:22:10,120 --> 00:22:12,520
And if you're a developer, or if you're a consultant,

428
00:22:12,700 --> 00:22:15,140
or if you look one day at something like that,

429
00:22:15,180 --> 00:22:17,320
and you want to use it, and if you're

430
00:22:17,320 --> 00:22:18,920
wondering what kind of output you should get,

431
00:22:19,000 --> 00:22:22,840
you can check this page, which is called the tune page of Ketchak.

432
00:22:22,960 --> 00:22:26,940
And pretty much, it tells you what kind of output length

433
00:22:27,440 --> 00:22:29,620
you can use for what kind of security.

434
00:22:31,520 --> 00:22:34,720
If you ever have to look for it, just look for tuning Ketchak

435
00:22:34,720 --> 00:22:37,480
or tuning SHAKE, and you'll find it.

436
00:22:38,700 --> 00:22:40,100
And it's pretty handy.

437
00:22:40,120 --> 00:22:40,500
It's a handy page.

438
00:22:43,560 --> 00:22:46,820
Now, SHAKE was so useful and so cool, actually,

439
00:22:46,860 --> 00:22:50,700
that Denise decided to release another document called

440
00:22:51,300 --> 00:22:55,380
Spatial Publication for SP, or SP for Spatial Publication,

441
00:22:57,180 --> 00:22:58,300
800-185.

442
00:22:58,760 --> 00:23:00,300
Again, you don't have to remember that.

443
00:23:00,360 --> 00:23:02,720
Just Google derived SHA-3 functions,

444
00:23:02,960 --> 00:23:04,100
or something like that.

445
00:23:04,880 --> 00:23:06,840
It's not really SHA-3 derived functions.

446
00:23:06,940 --> 00:23:08,840
It's rather SHAKE derived functions.

447
00:23:10,340 --> 00:23:13,000
So a year after the standard of SHA-3.

448
00:23:13,640 --> 00:23:18,040
And it basically had a bunch of functions, three functions,

449
00:23:18,340 --> 00:23:20,380
KMAC, tuple hash, and parallel hash.

450
00:23:21,160 --> 00:23:24,260
It also had a customizable version of SHAKE,

451
00:23:24,960 --> 00:23:27,320
but I won't be talking about that here,

452
00:23:27,440 --> 00:23:29,220
because it's not too useful.

453
00:23:29,360 --> 00:23:32,400
But maybe if you want to use SHAKE in your product,

454
00:23:32,460 --> 00:23:35,040
and you want to customize it with a string saying,

455
00:23:35,740 --> 00:23:40,100
it's my SHAKE, it's my protocol, it's for me, you can use C-SHAKE.

456
00:23:40,120 --> 00:23:41,700
Which is a customizable SHAKE.

457
00:23:42,040 --> 00:23:44,960
And actually, these functions are derived from C-SHAKE.

458
00:23:45,620 --> 00:23:47,340
But you don't have to remember what I just said.

459
00:23:47,460 --> 00:23:48,560
It's a detail.

460
00:23:49,880 --> 00:23:52,640
So this document had a lot of these.

461
00:23:52,940 --> 00:23:56,700
And you think of SHA-3, you have to think of SHA-3, SHAKE, KMAC,

462
00:23:56,820 --> 00:23:58,280
tuple hash, and parallel hash.

463
00:23:58,800 --> 00:24:00,260
It can be kind of confusing.

464
00:24:00,360 --> 00:24:01,960
And this is kind of why I'm here today.

465
00:24:02,120 --> 00:24:03,540
I'll tell you about all these functions,

466
00:24:03,660 --> 00:24:05,320
and what you can use them for.

467
00:24:07,060 --> 00:24:07,820
So KMAC.

468
00:24:07,900 --> 00:24:10,100
To explain KMAC, I'll start with a very simple one.

469
00:24:10,100 --> 00:24:10,260
A simple example.

470
00:24:10,960 --> 00:24:12,700
Imagine you want to send a message to Alice.

471
00:24:13,280 --> 00:24:14,580
You don't want to encrypt it.

472
00:24:14,620 --> 00:24:15,880
You don't care about encrypting it.

473
00:24:16,080 --> 00:24:18,520
You just want to send this message across the wire.

474
00:24:19,360 --> 00:24:22,700
And you want to make sure nobody in the middle can modify it.

475
00:24:23,820 --> 00:24:26,120
So what you do is that you send a message, and you append,

476
00:24:26,360 --> 00:24:29,240
I don't know, SHA-256 of the message next to it.

477
00:24:30,120 --> 00:24:32,700
I hope everybody in this room is aware that you

478
00:24:32,700 --> 00:24:33,840
shouldn't do that, right?

479
00:24:34,720 --> 00:24:36,900
Anybody in the middle can just take that hash,

480
00:24:37,100 --> 00:24:38,700
modify the message, and recompute

481
00:24:38,700 --> 00:24:39,640
the hash on the message.

482
00:24:40,100 --> 00:24:40,180
Right?

483
00:24:40,860 --> 00:24:41,520
It's trivial.

484
00:24:42,240 --> 00:24:43,400
Now, what if I do this?

485
00:24:43,500 --> 00:24:45,760
What if I add a key to the message?

486
00:24:48,040 --> 00:24:50,500
Actually, who thinks here in this room,

487
00:24:50,580 --> 00:24:51,420
who thinks that is secure?

488
00:24:51,560 --> 00:24:52,120
Show of hands.

489
00:24:55,920 --> 00:24:56,720
The what?

490
00:24:58,740 --> 00:25:00,500
So is this thing secure?

491
00:25:00,660 --> 00:25:03,020
Is putting a key next to your message

492
00:25:03,020 --> 00:25:06,200
allowing you to protect the integrity of your message?

493
00:25:06,360 --> 00:25:07,760
So if you send that across the wire,

494
00:25:07,980 --> 00:25:09,660
does that mean that nobody can modify

495
00:25:09,660 --> 00:25:12,700
this, this message, and the receiver, the recipient?

496
00:25:13,120 --> 00:25:15,560
But what about the question, do we think it's secure?

497
00:25:15,720 --> 00:25:17,020
Do you think it's secure?

498
00:25:17,860 --> 00:25:20,020
The key is the key of the same key.

499
00:25:20,020 --> 00:25:20,540
The what?

500
00:25:20,920 --> 00:25:22,560
The key is the key of the same key.

501
00:25:22,740 --> 00:25:24,640
Well, the, the recipient has the key.

502
00:25:25,020 --> 00:25:27,600
No, I mean, we have to change the key for every message.

503
00:25:29,940 --> 00:25:31,220
Well, not necessarily.

504
00:25:31,320 --> 00:25:34,720
You can, you can keep the same key for, for every message.

505
00:25:35,460 --> 00:25:36,360
What is the key?

506
00:25:37,160 --> 00:25:39,020
It's, it basically looks like an HMAC.

507
00:25:39,020 --> 00:25:41,260
If you think about it, it's a message code authentication.

508
00:25:41,920 --> 00:25:43,380
And it looks like it should work.

509
00:25:43,860 --> 00:25:46,820
That, that's what we use usually when we authenticate messages.

510
00:25:47,460 --> 00:25:50,120
The problem is that you cannot do that with SHA-256.

511
00:25:50,680 --> 00:25:53,300
You cannot do that with a lot of, uh,

512
00:25:53,300 --> 00:25:55,320
Merkle-Damgaard-based construction, actually.

513
00:25:55,920 --> 00:25:59,420
And the problem is that, uh, when SHA-256 gives you

514
00:25:59,420 --> 00:26:03,180
the output of a hash, it gives you the output of the states.

515
00:26:04,000 --> 00:26:07,160
So basically, it hashes the key opponent to the message,

516
00:26:07,700 --> 00:26:08,940
and it gives you the state.

517
00:26:09,020 --> 00:26:14,460
Well, there is some, some padding to it, uh, so, like every hash function, or, or most

518
00:26:14,460 --> 00:26:19,500
of them, and like AES, and like, uh, actually Shafri, you have a padding, right?

519
00:26:20,500 --> 00:26:23,900
And here you get key opponent to the message, opponent to the padding.

520
00:26:24,080 --> 00:26:27,640
But this is the state of the function, and as, as the attacker, if you get that,

521
00:26:27,740 --> 00:26:31,560
you can pretend that it hasn't finished hashing.

522
00:26:31,880 --> 00:26:35,060
And you can continue to hash like it's not the end of the message.

523
00:26:36,500 --> 00:26:39,000
And basically, what it allows you to do is to ha, to, to, to, to, to, to, to, to, to,

524
00:26:39,000 --> 00:26:43,900
get the hash of key opponent to the message, opponent to some padding, and opponent to

525
00:26:43,900 --> 00:26:46,440
anything you want, without knowing the key.

526
00:26:47,560 --> 00:26:52,020
This attack might allow you to, to do some weird things, might allow you to exploit

527
00:26:52,020 --> 00:26:57,560
some applications, uh, that use SHA-256 or SHA-512 that way.

528
00:26:58,160 --> 00:26:59,240
It's not always the case.

529
00:26:59,360 --> 00:27:02,180
It's kind of a, because of the padding, because of, of that kind of thing.

530
00:27:02,880 --> 00:27:04,280
But it might be a problem.

531
00:27:05,200 --> 00:27:06,840
And it shouldn't be a, a problem.

532
00:27:06,980 --> 00:27:08,980
A hash function, if it believes, if it believes, if it believes, if it believes, if it believes,

533
00:27:09,000 --> 00:27:12,560
if it behaves like a random oracle, should allow you to do that kind of thing.

534
00:27:13,040 --> 00:27:19,160
And actually, SHA-3 or any SHA-3 contestant, like Blake2 and, and all the others, allow

535
00:27:19,160 --> 00:27:22,780
you to do that kind of thing, without, uh, being a security issue.

536
00:27:23,740 --> 00:27:27,160
So here, if you use SHA-3 or just SHAKE, it works.

537
00:27:27,600 --> 00:27:29,400
And this is basically what KMAC is.

538
00:27:29,580 --> 00:27:33,640
Uh, I omitted a few details, but this is basically what KMAC does.

539
00:27:34,200 --> 00:27:38,640
It takes SHAKE, opens a key to the message, and it allows you to, to create a MAC out

540
00:27:38,640 --> 00:27:38,920
of it.

541
00:27:39,020 --> 00:27:39,920
Kind of like HMAC.

542
00:27:41,720 --> 00:27:43,780
Uh, tuple hash.

543
00:27:44,820 --> 00:27:46,800
So let me talk about the following problem.

544
00:27:47,000 --> 00:27:49,480
Imagine I'm using one of these, uh, secure messaging app.

545
00:27:49,700 --> 00:27:50,820
I have end-to-end encryption.

546
00:27:51,980 --> 00:27:56,780
Um, and I'm using Alice's public key to encrypt messages to Alice.

547
00:27:57,420 --> 00:28:01,660
And Alice, uh, Alice's public key is an RSA public key, so if you don't know what an RSA

548
00:28:01,660 --> 00:28:07,360
public key is, it's basically a small number E and a big number N. And to make sure I'm

549
00:28:07,360 --> 00:28:08,300
really talking to Alice.

550
00:28:08,640 --> 00:28:15,560
I take a fingerprint of that key, which will be SHA-256, uh, a hash of that key, uh, the

551
00:28:15,560 --> 00:28:20,880
small part, append it to the big parts, and, uh, Alice will do the same thing on her phone

552
00:28:20,880 --> 00:28:23,780
and will compare that in real life, or out of band.

553
00:28:25,680 --> 00:28:28,620
Now you can imagine that, uh, basically I'm doing this.

554
00:28:28,920 --> 00:28:35,160
E is a small number in bits, and N is a very large number, something like 2,048 bits, probably.

555
00:28:36,780 --> 00:28:37,720
Is that thing secure?

556
00:28:37,720 --> 00:28:43,360
Again, who thinks, uh, this is fine, and if I make a fingerprint, if I compute a fingerprint

557
00:28:43,920 --> 00:28:47,960
out of Alice's public key and she does the same with her public key, we can compare that

558
00:28:47,960 --> 00:28:50,900
and I can make sure that I'm really using her public key.

559
00:28:51,560 --> 00:28:53,660
So maybe show of hands who thinks this is secure.

560
00:28:55,480 --> 00:28:56,800
Who thinks this is not secure?

561
00:28:58,280 --> 00:28:58,800
All right.

562
00:28:59,320 --> 00:29:00,500
Not so, not so many people.

563
00:29:02,540 --> 00:29:07,700
So the answer is that you can create a different public key that will have the same number

564
00:29:07,720 --> 00:29:08,420
and the same fingerprint.

565
00:29:09,760 --> 00:29:10,720
How do you do that?

566
00:29:11,020 --> 00:29:13,800
Well, what if I do that?

567
00:29:13,900 --> 00:29:20,040
What if I choose a larger E, it's the same E, but it steals bits from the modulus N.

568
00:29:20,960 --> 00:29:22,980
And then N is kind of the rest of the bits.

569
00:29:23,580 --> 00:29:25,140
It's a different public key, right?

570
00:29:25,820 --> 00:29:28,280
But it hashes to the same value, the same fingerprint.

571
00:29:29,980 --> 00:29:32,380
It's the exact same sequence of bits.

572
00:29:35,160 --> 00:29:37,700
So and here again, the, the modulus might be the same.

573
00:29:37,720 --> 00:29:41,540
It might be small enough that it's weak and you might be able to crack it, reverse it,

574
00:29:41,640 --> 00:29:44,000
use the private key to use that public key.

575
00:29:46,420 --> 00:29:50,560
So really here the problem is that you're not, you're, you're hashing something in

576
00:29:50,560 --> 00:29:51,920
an ambiguous way.

577
00:29:52,620 --> 00:29:57,700
So what you should do is to hash the length of the first value, then the first value,

578
00:29:58,200 --> 00:30:01,340
then the length of the second value, then the second value.

579
00:30:01,840 --> 00:30:05,980
And you can even go further and have the type of the first value, the, the length

580
00:30:05,980 --> 00:30:07,600
of the first value, and the value.

581
00:30:07,680 --> 00:30:07,700
Okay.

582
00:30:07,720 --> 00:30:10,020
The type of the second value, and so on.

583
00:30:10,100 --> 00:30:15,400
This is actually called a TLV for tag length value, and this is what is used in smart cards.

584
00:30:16,960 --> 00:30:20,620
So I believe there are no real standards on how to do that correctly.

585
00:30:21,100 --> 00:30:27,700
And tuple hash is actually pretty much hashing the length of the first tuple, of the first

586
00:30:27,700 --> 00:30:31,780
object of your tuple, then the, the first value, then the second length, then the second

587
00:30:31,780 --> 00:30:36,780
value, the third length, the third value, to hash something in a non-ambiguous way.

588
00:30:37,220 --> 00:30:40,920
So if you're wondering how to do that, if one day you, you, you need to hash something

589
00:30:41,460 --> 00:30:44,400
in a non-ambiguous way, tuple hash is one of the answer.

590
00:30:44,580 --> 00:30:46,100
And actually I believe it's the only answer.

591
00:30:46,280 --> 00:30:48,800
If somebody knows something better, you can tell me.

592
00:30:50,840 --> 00:30:52,200
Parallel hash, the last one.

593
00:30:53,240 --> 00:30:57,100
And kind of like with the others, you can kind of guess what it is from the name.

594
00:30:58,080 --> 00:31:02,900
If we look at this sponge construction, remember we absorb the message and then we squeeze

595
00:31:02,900 --> 00:31:03,060
it.

596
00:31:03,640 --> 00:31:06,760
And we might wonder how we could optimize this.

597
00:31:06,780 --> 00:31:09,300
Can we parallelize this computation?

598
00:31:10,140 --> 00:31:15,840
So now if I want to compute this permutation here, I need the output of this permutation

599
00:31:15,840 --> 00:31:16,280
first.

600
00:31:17,340 --> 00:31:21,260
And to compute this permutation, I need the output of this permutation first.

601
00:31:22,280 --> 00:31:25,220
So it's not very parallelizable, it's, it's very serial.

602
00:31:25,540 --> 00:31:27,960
And this is a problem for big inputs.

603
00:31:29,360 --> 00:31:33,700
So parallel hash is basically using what they call a tree hashing construction.

604
00:31:34,240 --> 00:31:36,040
And they divide the inputs.

605
00:31:36,780 --> 00:31:37,620
Into large blocks.

606
00:31:38,000 --> 00:31:42,960
They hash those large blocks individually, obtaining a smaller input, smaller outputs.

607
00:31:43,380 --> 00:31:47,020
And then finally they have a hash of all these outputs.

608
00:31:51,660 --> 00:31:53,920
Yeah, it's a pretty simple construction, right?

609
00:31:54,440 --> 00:32:01,640
It actually allows you to hash big inputs, large files, very quickly.

610
00:32:02,100 --> 00:32:06,840
So I believe a block is around 4,000 bytes, something like that.

611
00:32:07,320 --> 00:32:13,180
The problem here, if you have something smaller than 4,000 bytes, basically you'll hash it

612
00:32:13,180 --> 00:32:14,640
and then you'll hash it again.

613
00:32:14,800 --> 00:32:16,260
So you have kind of a penalty.

614
00:32:16,260 --> 00:32:19,280
So it doesn't work that well with small inputs.

615
00:32:19,700 --> 00:32:23,900
But if what you do is only hashing large inputs, then this is a very good thing to

616
00:32:23,900 --> 00:32:24,120
use.

617
00:32:24,280 --> 00:32:25,940
And it's actually very, very fast.

618
00:32:28,140 --> 00:32:30,360
So again, timeline, kind of a recap.

619
00:32:31,720 --> 00:32:36,400
BLEG 2, one of the very fast hash functions, which is an alternative to Chaffery.

620
00:32:38,200 --> 00:32:39,700
Chaffery is the standard, rock solid.

621
00:32:39,940 --> 00:32:44,180
If you want something more flexible and faster than Chaffery, you have Sheck.

622
00:32:45,360 --> 00:32:46,240
If you want something faster than Sheck, you have Sheck.

623
00:32:46,240 --> 00:32:51,040
If you have different usages, you have TupleHash, ParallelHash, and KMAC, all right?

624
00:32:52,980 --> 00:32:59,140
Here, something I didn't mention, I believe BLEG 2 also has something like ParallelHash,

625
00:32:59,320 --> 00:33:01,960
something like Sheck, and so on.

626
00:33:02,100 --> 00:33:06,720
If you want to know more about that, you can go on the BLEG 2 website, but my talk is

627
00:33:06,720 --> 00:33:08,140
mostly focused on Chaffery.

628
00:33:10,340 --> 00:33:11,020
All right.

629
00:33:11,060 --> 00:33:13,600
So different things for different usage.

630
00:33:14,480 --> 00:33:16,220
Now, I want to mention...

631
00:33:16,220 --> 00:33:21,040
Keyak and Ketier, those are two things based on Ketchak as well, from the Ketchak team.

632
00:33:21,580 --> 00:33:24,420
And those are candidates to the Caesar competition.

633
00:33:24,900 --> 00:33:30,160
So the Caesar competition is an ongoing competition for authenticated encryption.

634
00:33:30,500 --> 00:33:32,400
So think of AES GCM.

635
00:33:33,640 --> 00:33:37,320
So it's still going on, and those are some of the candidates.

636
00:33:37,900 --> 00:33:39,820
I don't know when this is going to finish.

637
00:33:40,000 --> 00:33:40,640
Nobody knows.

638
00:33:40,820 --> 00:33:42,540
It's been taking a very long time.

639
00:33:42,860 --> 00:33:43,840
But one day.

640
00:33:44,040 --> 00:33:45,860
Maybe you'll be using...

641
00:33:45,860 --> 00:33:51,280
Not AES GCM, but maybe you'll be using one of the sponge constructions, even when you

642
00:33:51,280 --> 00:33:53,020
encrypt and authenticate your messages.

643
00:33:53,480 --> 00:33:54,180
Who knows?

644
00:33:54,740 --> 00:33:58,160
So I'm not going to explain these things, I just wanted to mention them.

645
00:34:00,940 --> 00:34:09,740
In 2016, I believe end of 2016, the Ketchak team kind of concedes in the war of speed.

646
00:34:09,880 --> 00:34:13,040
So they see that BLEG 2 is being used all over the place.

647
00:34:13,660 --> 00:34:14,940
They don't really like that.

648
00:34:15,860 --> 00:34:20,860
And they end up constructing something that will be faster than Chafri, but based on Chafri.

649
00:34:21,560 --> 00:34:27,480
And the solution they came up with is called Kangaroo 12 and Marsupilami 14.

650
00:34:27,720 --> 00:34:32,600
If you don't know Marsupilami, it's a French comic, some kind of beast with a...

651
00:34:32,600 --> 00:34:34,140
I should have had a picture of that.

652
00:34:34,560 --> 00:34:35,460
Just Google it.

653
00:34:35,660 --> 00:34:39,800
It's kind of an animal, fictive animal, a yellow animal with like black dots.

654
00:34:40,180 --> 00:34:40,940
It's very funny.

655
00:34:40,980 --> 00:34:41,440
You should read it.

656
00:34:42,360 --> 00:34:43,740
Anyway, it's very fast.

657
00:34:44,440 --> 00:34:45,100
It's very fast.

658
00:34:45,540 --> 00:34:45,840
It's very fast.

659
00:34:45,860 --> 00:34:46,820
The what?

660
00:34:47,140 --> 00:34:48,500
The one with Asterix and Newplace.

661
00:34:48,860 --> 00:34:49,860
Asterix and Newplace?

662
00:34:50,100 --> 00:34:50,640
The French comic.

663
00:34:52,320 --> 00:34:53,720
The French cartoon.

664
00:34:53,920 --> 00:34:55,760
The French cartoon.

665
00:34:55,760 --> 00:34:57,380
Anyway, you can tell me at the end.

666
00:34:59,620 --> 00:35:02,280
Basically, it's what BLEG 2 is to BLEG.

667
00:35:03,920 --> 00:35:04,920
Does that mean something?

668
00:35:05,220 --> 00:35:10,540
Anyway, they reduced the number of rounds of Chafri to obtain something that was way

669
00:35:10,540 --> 00:35:13,700
faster and still practically secure.

670
00:35:13,940 --> 00:35:15,780
So the theoretical security is...

671
00:35:15,780 --> 00:35:18,540
It's lower because they reduced the number of rounds of that permutation.

672
00:35:18,900 --> 00:35:20,780
It's not 24 anymore, it's 12.

673
00:35:21,600 --> 00:35:22,980
It's quite a drastic reduction.

674
00:35:23,940 --> 00:35:26,340
But the practical security is still here.

675
00:35:26,860 --> 00:35:31,260
We believe we still have a margin of security that is significant enough.

676
00:35:33,520 --> 00:35:36,280
Kangaroo 12 is blazing fast.

677
00:35:36,720 --> 00:35:38,300
It's faster than Parallel Hash.

678
00:35:38,500 --> 00:35:43,140
It's faster than SHA-1, SHA-2, Chafri, and all these constructions.

679
00:35:43,780 --> 00:35:45,660
I don't know if it's faster than BLEG 2.

680
00:35:45,660 --> 00:35:51,300
I believe it plays in the same ballpark, but it's not very important at this point.

681
00:35:51,420 --> 00:35:56,640
It's so fast that your hash function is not really the bottleneck of your application

682
00:35:56,640 --> 00:35:57,200
anyway.

683
00:35:59,380 --> 00:36:05,980
And one very cool thing about Kangaroo 12 is that it has tree hashing by default.

684
00:36:06,360 --> 00:36:08,040
So Chafri doesn't have that.

685
00:36:08,560 --> 00:36:09,960
Kangaroo 12 has that.

686
00:36:10,020 --> 00:36:13,540
So it's kind of the mature hash function that we deserve.

687
00:36:14,240 --> 00:36:14,840
So...

688
00:36:15,660 --> 00:36:20,980
It has this tree hashing that allows you to hash large inputs very quickly, like Parallel Hash.

689
00:36:21,700 --> 00:36:24,940
But it doesn't have this penalty for small inputs.

690
00:36:25,340 --> 00:36:29,560
So for small inputs, it doesn't do the double hashing thing that Parallel Hash does.

691
00:36:30,040 --> 00:36:31,720
So it's fast for large inputs.

692
00:36:31,960 --> 00:36:33,520
It's fast for small inputs.

693
00:36:35,060 --> 00:36:36,900
So yeah, very exciting hash function.

694
00:36:37,600 --> 00:36:43,480
And if you care about speed, my recommendation will be to use either BLEG 2 or Kangaroo 12.

695
00:36:46,500 --> 00:36:54,660
Again, if you want to use any of the SHAKE functions, any of Kangaroo 12, Chafri, SHAKE, etc.,

696
00:36:54,660 --> 00:36:59,340
all of these can be obtained from the Ketchhack code package that you have on this page.

697
00:37:01,940 --> 00:37:07,880
And this is all I have to say about Chafri and derived functions from Chafri.

698
00:37:08,520 --> 00:37:10,540
I have a part 2 on strobe.

699
00:37:10,980 --> 00:37:12,300
It's a bit more involved.

700
00:37:13,540 --> 00:37:14,900
And it's quite different.

701
00:37:16,980 --> 00:37:18,520
So I'll start with that.

702
00:37:18,600 --> 00:37:22,140
Strobe is a protocol framework, kind of like noise.

703
00:37:22,840 --> 00:37:25,840
But it focuses on the symmetric parts of your protocol.

704
00:37:26,760 --> 00:37:32,060
And it's very sexy in the way that it only uses Ketchhack, only uses SHAKE.

705
00:37:32,980 --> 00:37:36,420
So you can think of it as you can use it to create protocols.

706
00:37:37,200 --> 00:37:41,060
So not the handshake parts, but rather the symmetric part of your protocol.

707
00:37:41,600 --> 00:37:44,580
And you can use it pretty much to do any symmetric crypto.

708
00:37:45,660 --> 00:37:52,920
So you can use it to encrypt, authenticate, generate random numbers, derive keys.

709
00:37:53,240 --> 00:37:54,240
You can use it to hash.

710
00:37:54,660 --> 00:37:56,420
You can use it pretty much for anything.

711
00:37:57,300 --> 00:37:58,940
And also create your protocols.

712
00:37:59,200 --> 00:38:00,920
And it's only one primitive.

713
00:38:01,120 --> 00:38:04,780
Only this SHAKE at the center.

714
00:38:06,160 --> 00:38:09,280
The good thing is that if you look at the code, it's tiny.

715
00:38:09,460 --> 00:38:11,600
It only has a very, very small code base.

716
00:38:12,060 --> 00:38:13,960
And it's easy to audit.

717
00:38:13,960 --> 00:38:16,600
And it's pretty straightforward to understand.

718
00:38:17,840 --> 00:38:18,940
So how does it work?

719
00:38:19,600 --> 00:38:23,060
Well, if you look at the sponge construction, the thing we had earlier,

720
00:38:23,340 --> 00:38:27,180
you absorb messages and then you squeeze messages, right?

721
00:38:28,380 --> 00:38:33,240
And you might wonder, why can't you, after squeezing your message,

722
00:38:33,380 --> 00:38:37,700
why can't you just continue and absorb another message and then squeeze it again?

723
00:38:37,840 --> 00:38:39,740
And then absorb again and then squeeze it again.

724
00:38:40,940 --> 00:38:42,760
And actually this is a valid question.

725
00:38:42,760 --> 00:38:44,600
And Kitschak came with an answer.

726
00:38:44,740 --> 00:38:45,520
Yes, it's possible.

727
00:38:46,260 --> 00:38:51,240
And this is not called the sponge construction, but it's called the duplex construction.

728
00:38:51,960 --> 00:38:55,920
It basically allows you to absorb, squeeze, absorb, squeeze, on and on.

729
00:38:57,940 --> 00:39:02,280
The point of that kind of construction is that if you look at the third one,

730
00:39:02,940 --> 00:39:09,620
when you absorb and you squeeze, the results you get actually depends on what happened previously.

731
00:39:09,960 --> 00:39:12,060
On everything that was absorbed previously.

732
00:39:12,900 --> 00:39:17,060
So this is a very nice property to have in protocols,

733
00:39:17,600 --> 00:39:20,440
where you want every messages you send or something like that

734
00:39:20,440 --> 00:39:23,400
to depend on every messages that happened previously.

735
00:39:23,960 --> 00:39:27,120
This is what we call consistency of the protocol.

736
00:39:27,420 --> 00:39:32,300
It means that nothing is going to work if someone reordered your messages,

737
00:39:32,600 --> 00:39:35,320
replayed some of them, or dropped some of them in the middle.

738
00:39:35,840 --> 00:39:38,820
So you always depend on what happened previously.

739
00:39:40,140 --> 00:39:42,620
So this is what's at the heart.

740
00:39:42,760 --> 00:39:44,380
It's the core of Strobe.

741
00:39:44,520 --> 00:39:47,840
You can build protocols that have this nice property.

742
00:39:49,000 --> 00:39:52,920
So I'll give you a very simple example before I explain to you how Strobe works.

743
00:39:54,620 --> 00:39:57,580
Imagine that you're on the client side, but since it's symmetric,

744
00:39:57,780 --> 00:40:00,220
you would do pretty much the same on the server side.

745
00:40:00,440 --> 00:40:06,120
You instantiate your instance of the Strobe protocol with some custom string.

746
00:40:06,660 --> 00:40:09,780
So the custom string could be mywebsite.com,

747
00:40:09,820 --> 00:40:12,540
if your protocol is called mywebsite.com.

748
00:40:12,760 --> 00:40:16,160
It could be anything you want, but basically describe your protocol.

749
00:40:16,360 --> 00:40:18,920
It has to be the same on the other side, on the server side.

750
00:40:21,080 --> 00:40:23,220
Now you can key your protocol.

751
00:40:23,300 --> 00:40:25,060
You can insert some key.

752
00:40:25,280 --> 00:40:26,920
It could be a pre-shared secret.

753
00:40:27,820 --> 00:40:31,660
It could be a shared secret coming out of a key exchange.

754
00:40:31,960 --> 00:40:34,720
So you could do a noise key exchange, actually,

755
00:40:35,220 --> 00:40:40,020
and use the shared secret that you obtained from the defilment key exchange inside of this.

756
00:40:40,160 --> 00:40:41,800
So on the server, you would use the same one.

757
00:40:42,760 --> 00:40:44,260
And now you can do some fun stuff.

758
00:40:44,740 --> 00:40:47,360
So if you want to encrypt a request to the server,

759
00:40:47,540 --> 00:40:52,700
well, you use what they call the sendEncrypt call on Strobe

760
00:40:53,400 --> 00:40:57,400
on the request gets the roots of the domain, for example,

761
00:40:57,560 --> 00:40:59,940
if it's some sort of a web protocol.

762
00:41:01,320 --> 00:41:02,960
And you append that to the buffer.

763
00:41:04,020 --> 00:41:08,400
Now, before sending the buffer, you also want to authenticate your encryption, right?

764
00:41:08,900 --> 00:41:12,120
So you use the sendMac call on Strobe,

765
00:41:12,120 --> 00:41:13,940
with a length of 16 bytes.

766
00:41:14,240 --> 00:41:18,020
That's usually enough for an authentication tag.

767
00:41:18,260 --> 00:41:19,500
You append that to your buffer.

768
00:41:19,640 --> 00:41:21,300
You send it, right?

769
00:41:21,340 --> 00:41:21,880
Pretty straightforward.

770
00:41:22,500 --> 00:41:23,900
And the server receives that.

771
00:41:24,840 --> 00:41:27,520
And the server on the other side would do something similar,

772
00:41:27,660 --> 00:41:29,240
but the inverse of these functions.

773
00:41:30,060 --> 00:41:32,020
Now you receive an answer from the server.

774
00:41:32,160 --> 00:41:34,160
And this is the inverse of the function.

775
00:41:34,300 --> 00:41:35,380
You would do the receive encryption.

776
00:41:36,600 --> 00:41:39,600
And you would keep the last 16 bytes as the tag.

777
00:41:39,760 --> 00:41:42,100
So you would use the receiveMac on the last 16 bytes.

778
00:41:42,100 --> 00:41:46,520
And you would make sure that the Mac is OK.

779
00:41:47,060 --> 00:41:49,260
And if it's not, I don't know, you reset the connection.

780
00:41:50,400 --> 00:41:51,160
You crash.

781
00:41:51,420 --> 00:41:52,280
That's not a good idea.

782
00:41:52,460 --> 00:41:54,960
But you could do a different kind of things.

783
00:41:55,700 --> 00:41:57,440
So that's a very basic example,

784
00:41:57,700 --> 00:42:00,260
just to tell you how you can call these functions

785
00:42:00,260 --> 00:42:03,200
that Strobe defines in the specification.

786
00:42:05,000 --> 00:42:08,300
Actually, there are a bunch of functions that Strobe defines.

787
00:42:08,500 --> 00:42:10,120
Those are all the functions you can use.

788
00:42:10,140 --> 00:42:11,980
And you can use combinations of that.

789
00:42:13,540 --> 00:42:17,000
If you want to rekey your protocol at some point in time,

790
00:42:17,060 --> 00:42:18,180
you can use key.

791
00:42:18,700 --> 00:42:21,320
If you want to have forward secrecy in your protocol,

792
00:42:21,540 --> 00:42:22,620
you can use ratchets.

793
00:42:23,740 --> 00:42:27,540
You can send some non-encrypted messages with send clear

794
00:42:27,540 --> 00:42:29,540
and receive clear, and so on.

795
00:42:29,700 --> 00:42:32,940
What it does every time is that it absorbs those operations

796
00:42:32,940 --> 00:42:38,600
so that every following operation depends on these operations.

797
00:42:40,280 --> 00:42:42,080
Before I explain to you how it works,

798
00:42:42,780 --> 00:42:45,820
I'm going to talk to you about the internal of Strobe.

799
00:42:47,300 --> 00:42:52,240
This is really detailed, so bear with me.

800
00:42:52,320 --> 00:42:54,620
But basically, you don't have to understand this part.

801
00:42:55,920 --> 00:42:57,460
It's really if you're curious.

802
00:42:58,700 --> 00:43:01,180
So you have a default internal operation.

803
00:43:02,120 --> 00:43:05,620
And this is what happens every time you use some kind of operation.

804
00:43:05,920 --> 00:43:07,800
Or this is the default that happens

805
00:43:07,800 --> 00:43:09,940
when you use some of the Strobe operation.

806
00:43:09,940 --> 00:43:17,720
The default is to basically absorb your inputs inside the sponge, right?

807
00:43:17,780 --> 00:43:19,100
Or inside the duplex construction.

808
00:43:19,520 --> 00:43:20,720
So how do you absorb?

809
00:43:21,020 --> 00:43:25,480
Remember, you XOR your inputs, your message, with the states.

810
00:43:25,840 --> 00:43:28,020
Remember, that's the absorbing phase.

811
00:43:28,960 --> 00:43:30,680
So usually, you'll do that.

812
00:43:31,820 --> 00:43:36,540
Now, sometimes, you want to replace the state with your inputs.

813
00:43:36,540 --> 00:43:40,800
That might be when you want forward secrecy

814
00:43:40,800 --> 00:43:42,920
or when you want to key your protocol.

815
00:43:43,060 --> 00:43:45,700
You replace the bits of your state with your inputs.

816
00:43:46,140 --> 00:43:48,040
Like that, if you leak the states,

817
00:43:48,180 --> 00:43:50,520
nobody can guess what the previous state was

818
00:43:52,880 --> 00:43:57,400
without knowing the previous bits that were erased by this operation.

819
00:43:58,220 --> 00:43:59,380
One last operation.

820
00:43:59,940 --> 00:44:01,200
It's called the see-after.

821
00:44:01,660 --> 00:44:02,520
And basically,

822
00:44:05,600 --> 00:44:07,140
you do the same thing.

823
00:44:07,260 --> 00:44:09,100
You absorb your input with the states.

824
00:44:09,740 --> 00:44:10,920
That becomes the state.

825
00:44:11,500 --> 00:44:12,560
But you might have wondered,

826
00:44:12,680 --> 00:44:15,900
does that look like a one-time pad or a stream cipher?

827
00:44:18,320 --> 00:44:21,120
And basically, you can think of the state as a key stream,

828
00:44:21,320 --> 00:44:22,740
your input as your plaintext,

829
00:44:22,960 --> 00:44:24,120
and that could be the ciphertext.

830
00:44:24,620 --> 00:44:26,240
So if you retrieve that output,

831
00:44:26,400 --> 00:44:27,820
you can say that it's the ciphertext,

832
00:44:27,940 --> 00:44:29,960
and that's how you encrypt in Strobe.

833
00:44:30,880 --> 00:44:34,040
And I believe this is how Kayak and Ketier

834
00:44:34,040 --> 00:44:38,620
do authentication cipher work, also.

835
00:44:39,340 --> 00:44:40,340
One last one.

836
00:44:40,420 --> 00:44:41,620
It's called forcef.

837
00:44:41,780 --> 00:44:44,040
And this is to force the permutation to happen

838
00:44:44,040 --> 00:44:45,460
before you do anything.

839
00:44:45,920 --> 00:44:48,480
And this is basically when you really want your operation

840
00:44:48,480 --> 00:44:50,720
to rely on what happened previously.

841
00:44:51,380 --> 00:44:53,160
So every time you encrypt, for example,

842
00:44:53,180 --> 00:44:55,300
you really want your encryption operation

843
00:44:55,300 --> 00:44:58,220
to be dependent on maybe a key

844
00:44:58,220 --> 00:44:59,720
that you inserted in your state.

845
00:44:59,780 --> 00:44:59,940
So that's how you do it.

846
00:44:59,960 --> 00:45:01,940
So you're going to force the permutation

847
00:45:01,940 --> 00:45:02,940
before doing anything.

848
00:45:04,420 --> 00:45:06,980
So very quickly, an example.

849
00:45:08,760 --> 00:45:10,100
Here is your state, right?

850
00:45:10,160 --> 00:45:12,360
It has the public part and the secret part.

851
00:45:13,280 --> 00:45:14,840
I'm saying it comes from somewhere.

852
00:45:15,000 --> 00:45:16,220
Maybe you did something previously.

853
00:45:17,100 --> 00:45:19,260
And here I'm going to key the state.

854
00:45:19,760 --> 00:45:20,900
So before I do it,

855
00:45:21,020 --> 00:45:23,640
I'm going to absorb the operation I'm doing.

856
00:45:24,060 --> 00:45:25,660
Strobe is very verbose.

857
00:45:25,940 --> 00:45:28,460
And so I'm going to absorb the key operation.

858
00:45:29,640 --> 00:45:30,800
I'm simplifying here.

859
00:45:30,900 --> 00:45:32,020
There is some padding, et cetera.

860
00:45:32,120 --> 00:45:33,420
But basically, this is what we do.

861
00:45:33,500 --> 00:45:35,140
We first absorb the operation.

862
00:45:36,000 --> 00:45:38,560
Now we permute because we're keying.

863
00:45:39,180 --> 00:45:42,160
And we want to have this forward secrecy property.

864
00:45:42,420 --> 00:45:48,100
We want to erase the bits of the state with our key.

865
00:45:49,700 --> 00:45:52,000
And this is pretty much how the key operation works

866
00:45:52,000 --> 00:45:53,520
on this duplex construction.

867
00:45:54,280 --> 00:45:55,960
Now if I want to send some encryption,

868
00:45:56,280 --> 00:45:58,240
I will first absorb the operation.

869
00:45:58,240 --> 00:46:03,080
I permute because I want to depend on the key that was absorbed,

870
00:46:03,280 --> 00:46:05,000
or that was replaced in the state.

871
00:46:05,680 --> 00:46:08,240
And then I XOR the state with my plaintext.

872
00:46:08,440 --> 00:46:09,400
And I get it out.

873
00:46:09,400 --> 00:46:10,520
I get out the ciphertext.

874
00:46:11,980 --> 00:46:14,100
I have a bunch of examples like that.

875
00:46:14,420 --> 00:46:17,360
For example, the AD for authenticating more data.

876
00:46:18,160 --> 00:46:22,100
You don't need to permute because you're not sending anything right now.

877
00:46:22,320 --> 00:46:23,820
So you don't permute the thing.

878
00:46:24,540 --> 00:46:27,680
That means that you can have several operation in the same block

879
00:46:27,680 --> 00:46:28,600
before permuting.

880
00:46:29,460 --> 00:46:31,220
And then before sending the MAC,

881
00:46:31,280 --> 00:46:35,640
you really want the authentication tag to depend on that data

882
00:46:35,640 --> 00:46:36,840
that you want to authenticate.

883
00:46:36,920 --> 00:46:37,480
So you permute.

884
00:46:37,900 --> 00:46:39,540
And then you get the output,

885
00:46:39,700 --> 00:46:41,320
which will be the authentication tag.

886
00:46:43,580 --> 00:46:45,360
Again, you don't have to understand all of this.

887
00:46:45,840 --> 00:46:47,660
If you're really wondering how it works

888
00:46:47,660 --> 00:46:49,040
and one day you look at the specification,

889
00:46:50,120 --> 00:46:51,460
you can look at my slides

890
00:46:51,460 --> 00:46:54,360
and they can kind of help you to understand the specification

891
00:46:54,360 --> 00:46:55,660
and how it works.

892
00:46:56,220 --> 00:46:57,220
But this is really...

893
00:46:57,680 --> 00:46:59,240
to arouse your curiosity.

894
00:47:01,940 --> 00:47:03,700
I said that you can use strobe

895
00:47:03,700 --> 00:47:05,400
to do other things than protocol.

896
00:47:06,040 --> 00:47:06,700
For example,

897
00:47:06,740 --> 00:47:09,120
if you want to use the code base of strobe to just hash,

898
00:47:09,400 --> 00:47:11,440
what you will do is that you just initiate

899
00:47:12,440 --> 00:47:13,700
your strobe instance

900
00:47:13,700 --> 00:47:15,240
like you're initiating a protocol,

901
00:47:15,440 --> 00:47:17,320
but you just initiate a hash function.

902
00:47:17,460 --> 00:47:18,500
So you can call that hash

903
00:47:18,500 --> 00:47:19,820
or anything you want,

904
00:47:19,900 --> 00:47:20,540
myhash,

905
00:47:21,680 --> 00:47:22,120
myhashdavidwong,

906
00:47:22,240 --> 00:47:22,860
something like that.

907
00:47:23,720 --> 00:47:26,660
Then you add what you want to hash.

908
00:47:26,660 --> 00:47:28,120
You absorb what you want to hash.

909
00:47:28,840 --> 00:47:31,620
And then you squeeze it with the PRF function.

910
00:47:33,040 --> 00:47:35,920
And you can use this thing also

911
00:47:35,920 --> 00:47:38,120
to generate random numbers and so on.

912
00:47:38,460 --> 00:47:40,560
The specification kind of tells you

913
00:47:40,560 --> 00:47:41,840
every time you want to do something,

914
00:47:41,920 --> 00:47:44,900
how you can combine those operations.

915
00:47:46,360 --> 00:47:47,640
Key derivation function,

916
00:47:47,860 --> 00:47:49,640
again, an example where you can use

917
00:47:49,640 --> 00:47:52,000
different calls to derive a key

918
00:47:52,000 --> 00:47:54,220
out of a key itself.

919
00:47:56,100 --> 00:47:58,600
I'm not going over all the details here,

920
00:47:58,740 --> 00:47:59,780
but if you want to know more

921
00:47:59,780 --> 00:48:02,340
about this cool strobe protocol framework,

922
00:48:02,680 --> 00:48:05,420
you can check the specification on this page.

923
00:48:06,160 --> 00:48:08,700
It basically helps you to implement it.

924
00:48:08,860 --> 00:48:10,480
There is an implementation in C.

925
00:48:10,720 --> 00:48:12,360
I have an implementation in Go,

926
00:48:13,680 --> 00:48:15,480
which is more of a readable implementation

927
00:48:15,480 --> 00:48:17,580
to help you understand how it works.

928
00:48:17,700 --> 00:48:21,700
I don't have an optimized implementation yet,

929
00:48:22,800 --> 00:48:24,020
but it's coming.

930
00:48:25,560 --> 00:48:27,700
I don't have a part three yet,

931
00:48:27,740 --> 00:48:28,840
but it's coming.

932
00:48:29,020 --> 00:48:31,480
I'm doing some research currently on Disco.

933
00:48:32,180 --> 00:48:34,000
Disco is basically noise,

934
00:48:34,240 --> 00:48:36,220
which is this protocol framework,

935
00:48:36,420 --> 00:48:37,820
but basically focused on

936
00:48:38,560 --> 00:48:40,900
the handshake part of protocols.

937
00:48:41,380 --> 00:48:44,060
And strobe, which is focused on the symmetric parts.

938
00:48:44,240 --> 00:48:46,600
And together, I believe that they can be more efficient,

939
00:48:47,420 --> 00:48:48,500
easier to implement,

940
00:48:49,220 --> 00:48:51,860
and you can get rid of all the symmetric implementations

941
00:48:51,860 --> 00:48:53,340
just by having strobe.

942
00:48:53,340 --> 00:48:54,900
And this is called Disco.

943
00:48:55,400 --> 00:48:58,400
There is a draft of the extension on this page.

944
00:49:00,480 --> 00:49:02,220
If you want to find it,

945
00:49:02,240 --> 00:49:05,800
you can check my blog or check my Twitter.

946
00:49:05,920 --> 00:49:07,120
I usually talk about it.

947
00:49:08,560 --> 00:49:09,820
So read my blog.

948
00:49:10,000 --> 00:49:10,880
Follow me on Twitter.

949
00:49:11,360 --> 00:49:12,800
And this is basically the end.

950
00:49:13,720 --> 00:49:15,480
I don't know if I have time for questions.

951
00:49:15,540 --> 00:49:16,040
Do I have time?

952
00:49:16,880 --> 00:49:17,960
One minute for question.

953
00:49:19,740 --> 00:49:20,180
Yes?

954
00:49:20,720 --> 00:49:23,000
Yeah, so this is sort of a normal,

955
00:49:24,820 --> 00:49:25,660
normal developer.

956
00:49:26,020 --> 00:49:27,280
Good hash function and good match.

957
00:49:27,420 --> 00:49:29,240
I already have with SHA-2 and HMAC

958
00:49:29,240 --> 00:49:30,900
in my standard library.

959
00:49:31,160 --> 00:49:33,560
What's the most compelling reason

960
00:49:33,560 --> 00:49:35,360
I should choose SHA-2

961
00:49:35,360 --> 00:49:37,480
going forward over SHA-2 and HMAC?

962
00:49:37,700 --> 00:49:38,960
All right, that's a good question.

963
00:49:39,120 --> 00:49:40,440
My recommendation is that

964
00:49:40,440 --> 00:49:42,800
if you already use SHA-2 and HMAC,

965
00:49:42,900 --> 00:49:45,420
there are no real reasons to move.

966
00:49:45,980 --> 00:49:46,980
If you're using,

967
00:49:47,220 --> 00:49:49,420
if you're trying to choose hash functions

968
00:49:49,420 --> 00:49:51,460
and authentication type,

969
00:49:52,160 --> 00:49:53,040
something like MAC,

970
00:49:53,340 --> 00:49:55,120
message authentication codes and so on,

971
00:49:56,240 --> 00:49:58,360
you have no reason to choose SHA-2

972
00:49:58,360 --> 00:49:59,720
since we have these new,

973
00:50:00,480 --> 00:50:03,560
modern hash functions and all of that

974
00:50:03,560 --> 00:50:05,160
where you can use only one construction

975
00:50:05,160 --> 00:50:06,780
to do all your symmetric crypto.

976
00:50:08,260 --> 00:50:09,820
Unless you're using SHA-2

977
00:50:09,820 --> 00:50:11,940
to do this weird MAC thing

978
00:50:11,940 --> 00:50:13,460
where you have the key and the message,

979
00:50:13,680 --> 00:50:14,700
then you have,

980
00:50:14,800 --> 00:50:15,980
you might have a problem here.

981
00:50:16,160 --> 00:50:17,640
But if you're using SHA-2 correctly,

982
00:50:17,800 --> 00:50:20,980
I don't see any reason to move right now.

983
00:50:23,340 --> 00:50:23,560
Yes?

984
00:50:24,040 --> 00:50:26,660
It seems like there's a lot of randomness

985
00:50:26,660 --> 00:50:27,960
that we can squeeze out of this

986
00:50:27,960 --> 00:50:29,380
that depends on a key.

987
00:50:29,640 --> 00:50:31,040
Does that mean that we can use it

988
00:50:31,040 --> 00:50:33,160
as a stream cipher as well as a hash?

989
00:50:33,560 --> 00:50:35,580
Yeah, yeah, basically you can abuse it

990
00:50:35,580 --> 00:50:37,220
to use it as a stream cipher.

991
00:50:38,160 --> 00:50:40,660
I think some people are already using

992
00:50:40,660 --> 00:50:41,920
that as a stream cipher.

993
00:50:42,860 --> 00:50:44,380
And, I mean, basically,

994
00:50:45,360 --> 00:50:47,720
their proposition in the Caesar competition

995
00:50:47,720 --> 00:50:49,340
looks like a stream cipher.

996
00:50:49,580 --> 00:50:52,200
And strobe is kind of like a stream cipher as well.

997
00:50:53,560 --> 00:50:53,920
Yeah?

998
00:50:59,880 --> 00:51:01,480
It looks like a stream cipher.

999
00:51:08,180 --> 00:51:09,840
I mean, you can use it to, like,

1000
00:51:09,840 --> 00:51:11,400
pretty much generate random numbers

1001
00:51:11,400 --> 00:51:12,300
like a stream cipher

1002
00:51:12,300 --> 00:51:13,800
and then export that with your plaintext.

1003
00:51:15,600 --> 00:51:15,960
Right.

1004
00:51:16,240 --> 00:51:17,980
So this is what strobe does.

1005
00:51:18,120 --> 00:51:18,740
What was your question?

1006
00:51:20,900 --> 00:51:23,320
Yeah, we're moving away from stream ciphers

1007
00:51:23,320 --> 00:51:25,480
but it's mostly for bad reasons.

1008
00:51:25,560 --> 00:51:29,020
That was because RC4 was kind of broken.

1009
00:51:32,160 --> 00:51:34,860
And also, I think we realized that block ciphers

1010
00:51:34,860 --> 00:51:36,420
were easier to implement in hardware,

1011
00:51:36,900 --> 00:51:38,560
which was a good reason at the time,

1012
00:51:38,600 --> 00:51:40,900
but no software is very fast.

1013
00:51:41,220 --> 00:51:45,300
So if you look at the last cipher in TLS 1.3,

1014
00:51:45,420 --> 00:51:48,460
it's actually Shasha 20.1305

1015
00:51:48,460 --> 00:51:49,700
is actually a stream cipher.

1016
00:51:50,500 --> 00:51:51,880
Correct me if I'm wrong, but...

1017
00:51:51,880 --> 00:51:53,200
I mean, GCF is...

1018
00:51:53,320 --> 00:51:55,240
I guess what I was trying to say is

1019
00:51:55,240 --> 00:51:57,500
I thought people were moving away from stream ciphers

1020
00:51:57,500 --> 00:51:59,380
because it's so easy to screw up the protocol.

1021
00:51:59,800 --> 00:52:00,460
I don't know.

1022
00:52:01,020 --> 00:52:02,940
AES-GCM is a stream cipher.

1023
00:52:03,440 --> 00:52:03,880
Yeah.

1024
00:52:05,480 --> 00:52:07,880
So AES-GCM is also kind of a stream cipher

1025
00:52:07,880 --> 00:52:09,900
based on the block cipher, it's true, but...

1026
00:52:12,160 --> 00:52:16,820
So I don't believe people can screw up stream ciphers

1027
00:52:16,820 --> 00:52:17,840
more easily than...

1028
00:52:21,460 --> 00:52:22,820
I don't believe this is...

1029
00:52:22,820 --> 00:52:23,820
This is too correct,

1030
00:52:23,920 --> 00:52:26,100
but I'd be happy to be wrong

1031
00:52:26,100 --> 00:52:28,340
if you have a good argument for that.

1032
00:52:30,460 --> 00:52:32,360
Do I have to stop here, or...?

1033
00:52:32,360 --> 00:52:33,940
The next speaker isn't here yet,

1034
00:52:34,000 --> 00:52:35,040
so go on.

1035
00:52:35,320 --> 00:52:35,820
All right, all right.

1036
00:52:37,780 --> 00:52:38,660
Another question?

1037
00:52:39,460 --> 00:52:41,300
So you have a strobe

1038
00:52:41,300 --> 00:52:42,900
that could be used for 3D iteration.

1039
00:52:43,200 --> 00:52:43,620
Yeah.

1040
00:52:43,700 --> 00:52:45,380
How do you compare it with existing

1041
00:52:45,380 --> 00:52:47,660
like GPDF would be good for 3D?

1042
00:52:48,940 --> 00:52:52,800
So have I compared strobe to edge-cading?

1043
00:52:52,800 --> 00:52:54,380
HKDF or other key-derivation functions?

1044
00:52:55,580 --> 00:52:58,840
I have not, but it has the same properties, so...

1045
00:52:58,840 --> 00:53:00,340
Is there any reason

1046
00:53:00,340 --> 00:53:02,040
how it would go with strobe

1047
00:53:03,080 --> 00:53:05,880
Yeah, so the reason to use strobe

1048
00:53:05,880 --> 00:53:07,180
instead of edge-cading would be

1049
00:53:07,680 --> 00:53:09,460
that you're using strobe to do all the stuff.

1050
00:53:09,960 --> 00:53:11,580
So if you already have strobe

1051
00:53:11,580 --> 00:53:13,280
to do all the different stuff,

1052
00:53:13,400 --> 00:53:15,240
there is no reason to add edge-cading

1053
00:53:15,240 --> 00:53:17,280
to add another implementation on top of that

1054
00:53:17,800 --> 00:53:18,840
when you could be smaller

1055
00:53:18,840 --> 00:53:20,160
and you already have the implementation

1056
00:53:20,160 --> 00:53:22,000
for a key-derivation,

1057
00:53:22,000 --> 00:53:23,020
and so on.

1058
00:53:25,900 --> 00:53:26,500
Yeah?

1059
00:53:26,660 --> 00:53:28,120
I was curious to see

1060
00:53:28,120 --> 00:53:30,220
the advantage of using strobe.

1061
00:53:30,340 --> 00:53:33,220
Is that to reduce implementation errors

1062
00:53:33,220 --> 00:53:33,940
from verification

1063
00:53:33,940 --> 00:53:36,020
as it's ordered by a spot strobe?

1064
00:53:36,200 --> 00:53:37,560
So who uses strobe?

1065
00:53:38,020 --> 00:53:39,940
I'm saying what's the advantage

1066
00:53:39,940 --> 00:53:41,620
of compounding these functions together?

1067
00:53:42,200 --> 00:53:44,620
Is that to reduce the implementation errors

1068
00:53:44,620 --> 00:53:46,040
on the verification side?

1069
00:53:46,440 --> 00:53:49,220
Yeah, so it's rather a consequence

1070
00:53:49,220 --> 00:53:51,740
of using k-check at the core,

1071
00:53:51,840 --> 00:53:51,980
but it's also a consequence

1072
00:53:51,980 --> 00:53:54,000
is that you can do so many things with it

1073
00:53:54,000 --> 00:53:55,320
that you only need one primitive,

1074
00:53:55,480 --> 00:53:56,080
one implementation.

1075
00:53:56,900 --> 00:53:57,640
So it's...

1076
00:53:58,200 --> 00:54:00,340
Yeah, that's a consequence of using that

1077
00:54:00,340 --> 00:54:01,680
is that you can use all these...

1078
00:54:03,980 --> 00:54:05,160
So as a consequence,

1079
00:54:05,340 --> 00:54:07,680
it does reduce the cut size tremendously.

1080
00:54:08,120 --> 00:54:08,340
Yeah.

1081
00:54:08,960 --> 00:54:10,180
But that's the one advantage.

1082
00:54:10,320 --> 00:54:11,220
You don't see any other advantage

1083
00:54:11,220 --> 00:54:13,560
in terms of if you ordered it

1084
00:54:13,560 --> 00:54:14,260
in a certain way,

1085
00:54:14,740 --> 00:54:16,020
you can't have any...

1086
00:54:16,020 --> 00:54:17,180
You have to check the tag

1087
00:54:17,180 --> 00:54:17,840
as the first thing

1088
00:54:17,840 --> 00:54:19,860
as part of the reversing of that protocol, right?

1089
00:54:19,860 --> 00:54:20,240
Sorry?

1090
00:54:20,940 --> 00:54:22,400
Sorry, could you go up to the mic

1091
00:54:22,400 --> 00:54:23,380
when you're asking a question

1092
00:54:23,380 --> 00:54:24,340
so we have them recorded?

1093
00:54:24,740 --> 00:54:27,780
Oh, I can repeat the question, I guess.

1094
00:54:29,320 --> 00:54:30,620
But I'm not sure I understood it.

1095
00:54:31,220 --> 00:54:31,620
So...

1096
00:54:33,400 --> 00:54:35,860
So you're saying you have to verify the MAC

1097
00:54:35,860 --> 00:54:36,600
and it's, like, separated?

1098
00:54:37,140 --> 00:54:37,980
It's not like...

1099
00:54:37,980 --> 00:54:38,740
I'm saying there's definitely

1100
00:54:38,740 --> 00:54:40,980
less implementation issues

1101
00:54:41,740 --> 00:54:43,120
within crypto for...

1102
00:54:44,340 --> 00:54:44,740
Okay.

1103
00:54:45,860 --> 00:54:46,880
And I was saying,

1104
00:54:46,960 --> 00:54:48,080
does it have any orders

1105
00:54:48,080 --> 00:54:49,220
that it's going to use?

1106
00:54:49,220 --> 00:54:52,220
Okay, so the API of Strobe

1107
00:54:52,220 --> 00:54:54,420
is not too developer-friendly.

1108
00:54:55,420 --> 00:54:57,120
Strobe is still very experimental

1109
00:54:57,120 --> 00:54:57,880
at the moment,

1110
00:54:58,000 --> 00:55:00,500
and this is the kind of thing we're discussing.

1111
00:55:00,920 --> 00:55:02,400
Right now, the last discussion

1112
00:55:02,400 --> 00:55:03,920
is to make send encrypts,

1113
00:55:04,520 --> 00:55:08,340
to rename it to send an unauthenticated...

1114
00:55:08,340 --> 00:55:09,080
I cannot say this word.

1115
00:55:09,200 --> 00:55:11,000
Non-authenticated encrypts,

1116
00:55:11,020 --> 00:55:13,920
like that it might make developers understand

1117
00:55:13,920 --> 00:55:15,360
that this is not authenticated.

1118
00:55:15,760 --> 00:55:17,100
Another one would be to have

1119
00:55:17,100 --> 00:55:19,200
just to send authenticated encrypts

1120
00:55:19,220 --> 00:55:21,520
which would combine send encrypt and send MAC.

1121
00:55:22,380 --> 00:55:24,520
So, yeah, we're still, like, trying to see

1122
00:55:24,520 --> 00:55:27,520
how this could be made more...

1123
00:55:28,980 --> 00:55:31,020
less dangerous to use, let's say.

1124
00:55:31,200 --> 00:55:32,480
So this is very experimental.

1125
00:55:32,640 --> 00:55:33,180
This is...

1126
00:55:33,180 --> 00:55:34,340
If you know what you're doing,

1127
00:55:34,520 --> 00:55:35,980
this is a good idea,

1128
00:55:36,080 --> 00:55:37,320
but if you don't know what you're doing,

1129
00:55:37,440 --> 00:55:38,940
this is kind of edgy, right?

1130
00:55:39,740 --> 00:55:42,540
So you mentioned lots of different hash functions

1131
00:55:42,540 --> 00:55:45,160
derived from Chalk3 or Shape

1132
00:55:45,160 --> 00:55:47,160
that can be used for different purposes.

1133
00:55:47,260 --> 00:55:48,960
Is there some kind of abstraction

1134
00:55:49,220 --> 00:55:51,560
like lib-sodium that sort of abstracts away

1135
00:55:51,560 --> 00:55:54,480
the particular cipher or hash that's being used

1136
00:55:54,480 --> 00:55:56,320
to just call it an encrypted hash?

1137
00:55:56,600 --> 00:55:58,620
Is there some analogous API

1138
00:55:58,620 --> 00:56:00,160
for all the different hash functions

1139
00:56:00,160 --> 00:56:03,220
that sort of composes

1140
00:56:03,840 --> 00:56:05,580
the different derived hash functions

1141
00:56:05,580 --> 00:56:07,700
in a way that's easier to use and understand?

1142
00:56:08,000 --> 00:56:09,240
So you're saying

1143
00:56:09,240 --> 00:56:11,780
that there are so many derived functions from that?

1144
00:56:11,880 --> 00:56:14,840
Is there, like, an easier way to use them

1145
00:56:14,840 --> 00:56:16,220
or an easy API?

1146
00:56:16,820 --> 00:56:17,880
I don't believe so.

1147
00:56:17,880 --> 00:56:20,560
I think my talk is kind of the easiest way

1148
00:56:20,560 --> 00:56:22,060
to understand all of these constructions.

1149
00:56:22,100 --> 00:56:25,260
I don't think there is really any work in there

1150
00:56:25,260 --> 00:56:27,820
to make it easy for developers to understand

1151
00:56:27,820 --> 00:56:29,480
what are all these functions.

1152
00:56:30,960 --> 00:56:32,280
I'd say they're not...

1153
00:56:33,420 --> 00:56:34,620
KMAC is not a hash, right?

1154
00:56:34,700 --> 00:56:36,600
It's really like a message authentication code.

1155
00:56:36,720 --> 00:56:39,400
For the rest, I'd say just use Kangaroo 12

1156
00:56:39,400 --> 00:56:42,240
because it pretty much is the mature construction

1157
00:56:42,240 --> 00:56:45,200
that derives from Shake.

1158
00:56:45,400 --> 00:56:46,960
It's an extendable output function.

1159
00:56:46,960 --> 00:56:48,760
It derives from parallel hash.

1160
00:56:49,000 --> 00:56:50,160
You can parallelize it.

1161
00:56:50,480 --> 00:56:52,160
And it derives from Chaffery.

1162
00:56:52,180 --> 00:56:52,840
You can hash anything.

1163
00:56:53,120 --> 00:56:56,760
So Kangaroo 12 is kind of the easy API to use.

1164
00:56:57,320 --> 00:56:59,040
I need to drag you off-stage.

1165
00:56:59,040 --> 00:56:59,440
I'm sorry.

1166
00:56:59,600 --> 00:56:59,820
Thank you.