-
Notifications
You must be signed in to change notification settings - Fork 2
/
report-finalists.html
292 lines (249 loc) · 7.37 KB
/
report-finalists.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
<!doctype html>
<html lang="en">
<head>
<title>Password Hashing Competition</title>
<link href="style.css" rel="stylesheet" type="text/css" media="screen">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<section>
<h2>
PHC status report
</h2>
<p><i>First published on February 3, 2015, by the PHC panel</i></p>
<p>
The Password Hashing Competition (PHC) is a project aiming to identify new password hashing schemes in order to improve on the state-of-the-art and to encourage the use of strong password protection. In March 2014, PHC received 24 complete submissions. Based on the discussions on the public and private mailing lists, finalists of the competition are announced on December 8, 2014.
</p>
<p>
This report provides rationale on the selection of the nine PHC finalists, which are Argon, battcrypt, Catena, Lyra2, Makwa, Parallel, POMELO, Pufferfish, yescrypt.
</p>
<p>
<p>Selection criteria including, in no particular order:</p>
<ul>
<li>
Defense against GPU/FPGA/ASIC attackers
</li>
<li>
Defense against time-memory tradeoffs
</li>
<li>
Defense against side-channel leaks
</li>
<li>
Defense against cryptanalytic attacks
</li>
<li>
Elegance and simplicity of design
</li>
<li>
Quality of the documentation
</li>
<li>
Quality of the reference implementation
</li>
<li>
General soundness and simplicity of the algorithm
</li>
<li>
Originality and innovation
</li>
</ul>
</p>
<p>
We attempted to include algorithms relevant for most applications of a password hashing scheme, from web service authentication to client login or key derivation. We also believed that having diversity in the finalists is beneficial, therefore selected algorithms of different types and suitable for different applications.
</p>
<p>
Below we provide comments about each of the 24 submissions, to help understand our decisions. Due to limited time and resources, we succinctly report the main reasons that motivated our selection or non-selection as a finalist.
</p>
<p>
We thank all submitters for their contribution. Comments and questions may be sent to the public PHC mailing list or to <a
href="mailto:[email protected]">[email protected]</a>.
</p>
<p>
It is planned that the PHC winner(s) be announced in Q2 2015.
</p>
<h3>
Finalists
</h3>
<p>
Below we list specific properties that motivated our selection of the finalists. This is not to say the finalists are free of drawbacks (we are aware of many) or defects. It's just that in this brief report we list some of what motivated our choice in favor of the finalists, rather than against.
</p>
<h4>
Argon
</h4>
<ul>
<li>Thorough security analysis, especially against TMTO</li>
<li>Uses only AES as external primitive, often available as CPU instructions</li>
</ul>
<h4>
battcrypt
</h4>
<ul>
<li>Simple and minimalistic design and implementation</li>
<li>Optimized for PHP, as it includes a Blowfish implementation</li>
</ul>
<h4>
Catena
</h4>
<ul>
<li>Well-motivated design, convincing theoretical framework</li>
<li>Well-understood side-channel and TMTO resistance</li>
</ul>
<h4>
Lyra2
</h4>
<ul>
<li>Elegant sponge-based design, with a single external primitive</li>
<li>Good security analysis</li>
</ul>
<h4>
Makwa
</h4>
<ul>
<li>Unique design supporting delegation, suited only for specific applications</li>
<li>Thorough analysis and documentation, good quality code</li>
</ul>
<h4>
Parallel
</h4>
<ul>
<li>Minimalistic and compact design, addressing low-memory applications</li>
<li>Original distinction of sequential vs. parallel cost</li>
</ul>
<h4>
POMELO
</h4>
<ul>
<li>No external primitive required, partial cache-timing mitigation</li>
<li>Polished documentation and (succinct) code</li>
</ul>
<h4>
Pufferfish
</h4>
<ul>
<li>Leverages bcrypt's understanding and GPU resistance</li>
<li>Enhanced bcrypt with 64-bit optimization and support for higher memory</li>
</ul>
<h4>
yescrypt
</h4>
<ul>
<li>Leverages scrypt's understanding and modularity</li>
<li>Well-understood performance ratio, simplification potential</li>
</ul>
<h3>
Non-finalists
</h3>
<p>
Given that diversity was among our criteria for selection of finalists,
non-selection of a submission does not necessarily imply that we found
the submission less suitable than all of those we selected as
finalists—in some cases, the non-finalist submission merely received considerably less support by the panel than other submissions that we felt were competing in the same category (targeting the same use cases and/or offering the same kind of defenses). Without what we deemed a more suitable submission in a (loosely defined) category, some of these non-finalist submissions could have been selected. Besides, a number of non-finalists contributed original or interesting ideas, and this contributed to our understanding of what constitutes a password hashing scheme suited for practical applications. That said, we actually found many non-finalists less mature, less analyzed, and generally less understood than most of the finalists.
</p>
<p>
Below we point out specific properties or defects that motivated our choice. This is not to say the non-finalists lack advantages (we are aware of many). It's just that in this brief report we list some of what motivated our choice against the non-finalists, rather than in favor.
</p>
<h4>
AntCrypt
</h4>
<ul>
<li>Data-dependent branching is a controversial area not sufficiently explored in time for this competition, hence current design was deemed unlikely to maximize benefits vs. risks</li>
<li>Floating-point arithmetic complicates reproducibility and
portability</li>
</ul>
<h4>
Catfish
</h4>
<ul>
<li>Withdrawn</li>
</ul>
<h4>
Centrifuge
</h4>
<ul>
<li>Too slow for its memory usage (byte-grained random memory accesses)</li>
</ul>
<h4>
EARWORM
</h4>
<ul>
<li>Relies solely on ROM-hardness whereas better understood defenses are also affordable by its target applications</li>
<li>Uses multiple external primitives, not second-preimage resistant</li>
</ul>
<h4>
Gambit
</h4>
<ul>
<li>Similar to Catena, but a less mature design and potentially worse ASIC resistance (due to the use of Keccak)</li>
</ul>
<h4>
Lanarea
</h4>
<ul>
<li>Too slow for its memory usage</li>
</ul>
<h4>
M3lcrypt
</h4>
<ul>
<li>Withdrawn</li>
</ul>
<h4>
MCS_PHS
</h4>
<ul>
<li>Similar to PBKDF2, without significant improvement</li>
<li>Unclear security of the underlying hash, from earlier versions' breaks</li>
</ul>
<h4>
OmegaCrypt
</h4>
<ul>
<li>Same concern about data-dependent branching as with AntCrypt, and partially predictable branches and memory addresses (unlike claimed)</li>
<li>Lack of convincing security or performance analysis</li>
</ul>
<h4>
PolyPassHash
</h4>
<ul>
<li>A protocol to recover a symmetric key used to encrypt passwords, not a password hashing scheme, too far from what PHC is expecting</li>
</ul>
<h4>
RIG
</h4>
<ul>
<li>Similar to Catena, but received less attention (cf. bugs found in
the v1 specification and code)</li>
</ul>
<h4>
Schvrch
</h4>
<ul>
<li>Cryptographically weak</li>
<li>ASIC-friendly, total cost = time + memory</li>
</ul>
<h4>
Tortuga
</h4>
<ul>
<li>Fails basic statistical tests</li>
</ul>
<h4>
TwoCats
</h4>
<ul>
<li>Interesting mix of ideas, but less understood design than other candidates in the same space</li>
</ul>
<h4>
Yarn
</h4>
<ul>
<li>Not as mature and finely-tuned design as other candidates in its category</li>
</ul>
</section>
<footer>
<hr />
<i><small>Modified: 2015-03-25</small></i>
</footer>
</body>
</html>