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

SHA-3 Standard [pdf]

nvlpubs.nist.gov

Post reply on HN
Print view View original

31–40 of 91 posts

Re: SHA-3 Standard [pdf]

#31

Post by laumars »

emboss wrote: post #23
laumars wrote: post #17

Earlier quoted context omitted.

One of the key points of hashes in cryptography is to be computationally expensive rather than faster. Faster means more password attacks per second. Granted faster is better for non-cryptographic purposes like data indexes, but even there I'd consider performance secondary to the hash size, etc

General-purpose hash functions should be as efficient as possible. That's why they shouldn't be used for password hashing directly. There are special hash functions (slow, memory-intensive, hard to parallelize) for storing password hashes: https://password-hashing.net/

BLAKE wasn't specified as being general purpose and was compared against SHA-3 as being "better" because it's faster. Since SHA-3 does support cryptographic functions, my comment is a reasonable response stating that performance isn't the only metric when choosing a hashing function.

Re: SHA-3 Standard [pdf]

#32

Post by ori_b »

laumars wrote: post #30
ori_b wrote: post #27

Earlier quoted context omitted.

General cryptography -- for example, message validation -- does not need to be slow. In fact, slow message validation would cripple hash functions for cryptography, increasing CPU load and reducing throughput. Password checking is an edge case. Special purpose password hashing functions with tunable difficulty should be used for those. Do not use general purpose hash functions: They are better than plain text, but th…

> General cryptography -- for example, message validation -- does not need to be slow. In fact, slow message validation would cripple hash functions for cryptography, increasing CPU load and reducing throughput. There is definitely a trade off between the two (performance on servers vs rate of passwords an attacker can crack). But generally the advice is to go for the slowest you can afford. Hence why KDF's have an i…

No: This is why you have a split between KDFs and hashes. Where you use one, you would not want to use another.

Trying to make one that does both leads to something that sucks at both.

Re: SHA-3 Standard [pdf]

#34

Post by rogerbinns »

logicrime wrote: post #5

For non-scientists, what does this mean? Is SHA-2 not good anymore? What should I do?

Valerie Aurora has a nice post showing the lifetime of cryptographic hash functions. You can see them all following the same pattern over time. You don't want to be on the bleeding edge, but also should avoid the trailing edge. http://valerieaurora.org/hash.html

Re: SHA-3 Standard [pdf]

#35

Post by laumars »

ori_b wrote: post #32
laumars wrote: post #30

Earlier quoted context omitted.

> General cryptography -- for example, message validation -- does not need to be slow. In fact, slow message validation would cripple hash functions for cryptography, increasing CPU load and reducing throughput. There is definitely a trade off between the two (performance on servers vs rate of passwords an attacker can crack). But generally the advice is to go for the slowest you can afford. Hence why KDF's have an i…

No: This is why you have a split between KDFs and hashes. Where you use one, you would not want to use another. Trying to make one that does both leads to something that sucks at both.

> No: This is why you have a split between KDFs and hashes. Where you use one, you would not want to use another.

That's not true either. Hashes are recommended to be used as input to KDFs.

"Modern password-based key derivation functions, such as PBKDF2 (specified in RFC 2898), use a cryptographic hash, such as SHA-2"

Source: https://en.wikipedia.org/wiki/Key_derivation_function#Key_st...

> Trying to make one that does both leads to something that sucks at both.

eh? Nobody is advocating that what-so-ever. Not me, not anybody.

I think you're now arguing with me for the sake of arguing with me. :-/

Re: SHA-3 Standard [pdf]

#36

Post by tedunangst »

laumars wrote: post #31
emboss wrote: post #23

Earlier quoted context omitted.

General-purpose hash functions should be as efficient as possible. That's why they shouldn't be used for password hashing directly. There are special hash functions (slow, memory-intensive, hard to parallelize) for storing password hashes: https://password-hashing.net/

BLAKE wasn't specified as being general purpose and was compared against SHA-3 as being "better" because it's faster. Since SHA-3 does support cryptographic functions, my comment is a reasonable response stating that performance isn't the only metric when choosing a hashing function.

In any context where slower is better, SHA3 is not nearly slow enough.

Your comment (none of them, really) was not at all reasonable, assuming as it did that cryptographic hash is synonymous with password hash.

Re: SHA-3 Standard [pdf]

#37

Post by tedunangst »

laumars wrote: post #26
hroi wrote: post #20

Earlier quoted context omitted.

I think you are confusing hash functions with key derivation functions..

I'm not. Hash functions are used in cryptography for password storage (eg SHA2-512). Best practice would be to use a KDF with a hash salt, but in a lot of cases, SHA2 + salt + pepper is sufficient.

> Hash functions are used in cryptography for password storage

hint: they're used for more than that.

you are woefully out of your depth here.

Re: SHA-3 Standard [pdf]

#38

Post by ori_b »

laumars wrote: post #35
ori_b wrote: post #32

Earlier quoted context omitted.

No: This is why you have a split between KDFs and hashes. Where you use one, you would not want to use another. Trying to make one that does both leads to something that sucks at both.

> No: This is why you have a split between KDFs and hashes. Where you use one, you would not want to use another. That's not true either. Hashes are recommended to be used as input to KDFs. "Modern password-based key derivation functions, such as PBKDF2 (specified in RFC 2898), use a cryptographic hash, such as SHA-2" Source: https://en.wikipedia.org/wiki/Key_derivation_function#Key_st... > Trying to make one that do…

Ok, that was sloppy phrasing on my part, but my point still stands: The entire reason that KDFs exist is to deal with the fact that hash functions are designed to be as fast as possible. If it made sense to make hash functions slow, then KDFs would not be needed.

While KDFs do use hash functions internally, the hash function is an implementation detail.

Re: SHA-3 Standard [pdf]

#39

Post by laumars »

tedunangst wrote: post #37
laumars wrote: post #26

Earlier quoted context omitted.

I'm not. Hash functions are used in cryptography for password storage (eg SHA2-512). Best practice would be to use a KDF with a hash salt, but in a lot of cases, SHA2 + salt + pepper is sufficient.

> Hash functions are used in cryptography for password storage hint: they're used for more than that. you are woefully out of your depth here.

> you are woefully out of your depth here.

I very much doubt that since I've been able to provide back up sources to evidence my points. However if I am wrong then please do educate me instead of posting uninformative troll comments like the above.

Re: SHA-3 Standard [pdf]

#40

Post by schoen »

laumars wrote: post #28
0x0 wrote: post #22

Earlier quoted context omitted.

Isn't the main purpose of a hashing function to validate file (edit: or "message") integrity? so you want them to process as many MB/s as possible? I thought using hashing to save passwords is misusing cryptographic hashes for something they were not intended to do? (Assuming they will keep the input secret as opposed to preventing finding colliding duplicate inputs?)

Collision attacks is a non-issue with modern hashes. The point of hashing passwords is it's a one-way cither. ie can't be unencrypted - can only be brute forced or rainbow table attacked (the latter is where salts and peppers come into the equation). https://en.wikipedia.org/wiki/Cryptographic_hash_function

You keep defining "cryptographic" hashing as equivalent to password hashing, but password hashing is only one application of cryptographic hashing (a minority application). A hash function is still "cryptographic" and its applications are still "cryptographic applications" when they aren't password-related. Those applications commonly optimize for speed, rather than pessimizing for speed. In many of those contexts, the input to the hash and the hash value are presented simultaneously to the verifying party (or aren't even secret); in those contexts there is no benefit at all from making the cryptographic hash function slow to compute, and considerable benefit from making it fast to compute.
Post reply on HN