Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Password Hashing Competition winner and special recognitions

groups.google.com

Post reply on HN
Print view View original

11–20 of 23 posts

Re: Password Hashing Competition winner and special recognitions

#11

Post by ReidZB »

biot wrote: post #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 b…

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 https://github.com/khovratovich/Argon2/tree/master/Argon2i/r...).

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 is a language that's supposed to help in that regard, but I don't know offhand who all uses that.

Re: Password Hashing Competition winner and special recognitions

#12

Post by ademarre »

ReidZB wrote: post #5
agl wrote: 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.

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

Re: Password Hashing Competition winner and special recognitions

#13

Post by ReidZB »

ademarre wrote: post #12
ReidZB wrote: post #5

Earlier quoted context omitted.

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.

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

I don't expect there to be a similar community reaction. NIST and the PHC panelists (list at 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.

Re: Password Hashing Competition winner and special recognitions

#14

Post by nly »

ultramancool wrote: post #9
tyho wrote: 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.

This is trivial to achieve with any hash function.

Re: Password Hashing Competition winner and special recognitions

#15

Post by baby »

tyho wrote: 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.

> 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

Can't you do that with any password hashing alg?

Re: Password Hashing Competition winner and special recognitions

#16

Post by floodyberry »

ademarre wrote: post #12
ReidZB wrote: post #5

Earlier quoted context omitted.

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.

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

The SHA-3 backlash was because they cut second preimage resistance in half, and because the only reason for the change was due to Keccak performing very poorly in software.

Re: Password Hashing Competition winner and special recognitions

#17

Post by riquito »

nly wrote: post #14
ultramancool wrote: post #9

Earlier quoted context omitted.

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.

This is trivial to achieve with any hash function.

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?

Re: Password Hashing Competition winner and special recognitions

#18

Post by technion »

ReidZB wrote: post #11
biot wrote: post #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 b…

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 cryptograp…

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.

Re: Password Hashing Competition winner and special recognitions

#19

Post by ufo »

biot wrote: post #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 b…

Low-level crypto stuff such as block cyphers and hashing functions is usually done in C or assembly language. One of the biggest reasons is that its very hard to avoid timing attacks on higher level languages (when a computation takes a different time to run depending on the inputs an attacker can extract some info about secrets you control). Performance is also really important because the bad guys will use whatever means necessary to speed up their brute-forcing and you don't want to give them too much of an edge.

Another reason for C and assembly is that when everything your algorithm manipulates is a bunch of bytes you don't get much advantage from a type system.

Re: Password Hashing Competition winner and special recognitions

#20

Post by mankyd »

riquito wrote: post #17
nly wrote: post #14

Earlier quoted context omitted.

This is trivial to achieve with any hash function.

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 u…

Hash your existing hash with a more powerful algorithm.
Post reply on HN