
Password Hashing Competition winner and special recognitions - earthrise
https://groups.google.com/forum/#!topic/crypto-competitions/3QNdmwBS98o
======
ReidZB
Hmm. I didn't expect this announcement this soon - at least on the public
mailing list, the notion of a winner still seemed very far away. Just 18 days
ago: [https://groups.google.com/forum/#!searchin/crypto-
competitio...](https://groups.google.com/forum/#!searchin/crypto-
competitions/phc$20winners/crypto-competitions/E99ZyJATo6E/plkmr4sQQ8QJ)

Anyway, as best as I could tell, the consensus on the public mailing list was
that the best case for a singular winner would be an amalgamation of four
finalists: Argon2, Lyra2, Catena, and yescrypt. Each of them has some
properties that are desirable. I'm curious to what extent Argon2 will be
modified - and especially curious if the final spec will have tunable
parameters / multiple modes or be a one-size-fits-all deal.

Edit: If you're interested in more information, a decent starting place is
this paper:
[https://eprint.iacr.org/2014/881.pdf](https://eprint.iacr.org/2014/881.pdf)
If you folks want more reading material, I can pull some emails from the
mailing list

------
agl
Here is the spec for the winner: [https://password-
hashing.net/submissions/specs/Argon-v2.pdf](https://password-
hashing.net/submissions/specs/Argon-v2.pdf)

~~~
ReidZB
To be clear, that isn't the final spec. AFAIK, we don't yet know the extent of
changes that may be made to Argon2. The email says that Argon2 will be the
"basis" for the final winner, which could have some interesting results.

~~~
ademarre
> _Argon2 will be the "basis" for the final winner_

I expect there will be a long review period before the winner is considered
suitable for common use. It reminds me of the backlash at NIST for some late
changes to the SHA-3 winner, Keccak:
[https://en.wikipedia.org/wiki/SHA-3#NIST_announcement_contro...](https://en.wikipedia.org/wiki/SHA-3#NIST_announcement_controversy)

~~~
ReidZB
I don't expect there to be a similar community reaction. NIST and the PHC
panelists (list at [https://password-hashing.net/](https://password-
hashing.net/)) are two __very __different bodies.

Argon2's internals will likely be altered (with community input); Keccak's
internals were left alone (only parameters were tweaked).

The community _wants_ modifications to Argon2 before its final publication.
Essentially, each of the five supreme finalists possess nifty properties. It'd
be nice if Argon2 could be modified to possibly have some of these too.

That being said, I do expect you're correct that the winner will not be in
mainstream production for a couple years at least.

------
guelo
For those like me that weren't aware of this competition here's their website
with more info [https://password-hashing.net/](https://password-hashing.net/)

------
tyho
Impressive stuff. One of the features of the winner is that you can offload
the expensive computation to a client and still maintain the security you
would have if it were done on the server. This should hopefully persuade
people to use slow hash functions where they otherwise would not due to
performance concerns.

~~~
ultramancool
It also allows client-independent strengthening of the hashes, so you don't
have to wait for users to login again to be able to increase the strength of
all existing hashes.

~~~
nly
This is trivial to achieve with any hash function.

~~~
riquito
AFAIK you store the hash along the algorithm/parameters you used to generate
it. To update the hash you wait for the user to log in and...

1\. check if the stored hash is identical to the hash you generate on fly
using the old algorithm

2\. create a new hash using the new algorithm and substitute both the old hash
and the old informations about the algorithm/parameters

What's the trivial way to achieve it without the user logging in?

~~~
mankyd
Hash your existing hash with a more powerful algorithm.

~~~
nly
Exactly, it's hacky, but Scrypt'ing your ancient MD5 databases is better than
sitting on your ass and being caught with your pants down when your database
gets dumped on pastebin or a Russian forum

------
biot
What tools are typically used to develop these algorithms? The site has
[https://password-hashing.net/faq.html#qd](https://password-
hashing.net/faq.html#qd) which mentions attempts to formally define the
security of a good algorithm though a quick scan of the two papers indicates
the definitions are mathematical properties described in English. However,
when it comes to implementations is there a generally accepted
language/framework in which correctness can be proven? Haskell comes to mind
as one such language which its proponents tout as ensuring correctness, though
I lack the experience to determine whether this means "your broken algorithm
runs 100% correctly" vs. "a broken algorithm will not compile".

~~~
ReidZB
Typically, cryptographic primitives (like block ciphers, hash functions, KDFs,
etc) are written in C. Bugs are caught solely by the use of a sharp mind and
careful reading.

There are really two reasons for this: (1) optimization is a really big deal;
some impls go so far as to have asm for specific architectures or use
architecture-specific features like SSE2 and (2) there really isn't very much
code for a cryptographic primitive, typically <=1000 lines. (e.g., see
[https://github.com/khovratovich/Argon2/tree/master/Argon2i/r...](https://github.com/khovratovich/Argon2/tree/master/Argon2i/ref)).

Once a simple reference implementation is hand-checked, it can be used to
generate comprehensive test vectors for other implementations.

This isn't my area of expertise, but I believe there's some research in
applied crypto for implementation verification. I know
[https://github.com/GaloisInc/cryptol](https://github.com/GaloisInc/cryptol)
is a language that's supposed to help in that regard, but I don't know offhand
who all uses that.

~~~
technion
The other reason for C is that the reference implementation is generally
expected to eventually have bindings for every other language - a new standard
won't flourish if you find out it's hard access to it in your choice of
language.

If you can _also_ write an implementation in something such as Haskell,
verifying the input/output between the two implementations is a great way to
assure it works as expected.

