Live data from Hacker News

Password Hashing Competition winner and special recognitions

groups.google.com

1–10 of 23 posts

Re: Password Hashing Competition winner and special recognitions

#3
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...

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 If you folks want more reading material, I can pull some emails from the mailing list

Re: Password Hashing Competition winner and special recognitions

#5
post #2

Here is the spec for the winner: https://password-hashing.net/submissions/specs/Argon-v2.pdf

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.

Re: Password Hashing Competition winner and special recognitions

#6
What tools are typically used to develop these algorithms? The site has 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".

Re: Password Hashing Competition winner and special recognitions

#7
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.

Re: Password Hashing Competition winner and special recognitions

#8
post #7

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.

Being able to have the client (which knows the password it offered) do this computation isn't something super special though-- it's something that could be done fine with pbkdf2-- for example.

If fancy client support is really an option it would usually be better to use a zero-knoweldge authentication protocol (like SRP), though one of these KDFs could be used as a preprocessing step.

Re: Password Hashing Competition winner and special recognitions

#9
post #7

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.

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.

Re: Password Hashing Competition winner and special recognitions

#10
post #7

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.

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.

That's a pretty compelling feature.
Post reply on HN