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

41–50 of 91 posts

Re: SHA-3 Standard [pdf]

#41

Post by laumars »

ori_b wrote: post #38
laumars wrote: post #35

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

Ok, thank you. That does make more sense now :)

Re: SHA-3 Standard [pdf]

#42

Post by joeyh »

pshc wrote: post #9

Whoa, finally! I've been oddly attached to Keccak's story over the years ever since it won the contest. Glad to see SHA-3 finished. Did NIST make any changes to the algorithm since? From what I can tell it looks like they only made clarifications. To celebrate, here's a hacked-up keccak-512 implementation in Rust: https://github.com/pshc/keccak (I have yet to check whether it's actually SHA-3.)

I'm not clear either on whether anything substantial has changed since the April 2014 draft. Would be good to have some authoratative hash values to test libraries against.

Glad to see it sets c = 2d at least.

Re: SHA-3 Standard [pdf]

#43

Post by copsarebastards »

laumars wrote: post #17
alextgordon wrote: post #14

Earlier quoted context omitted.

It's faster (in software).

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

You're being downvoted because despite the "wealth of other content online about using cryptographic hashes for password storage", you haven't actually read enough of it to know that neither SHA3 nor BLAKE are appropriate for password storage. Neither is a key stretching function. Ignorance isn't a sin, but unwarranted overconfidence is.

SHA3 and BLAKE are cryptographic hash functions, but they are fast collision resistant hash functions, NOT key stretching functions. They're primitives used in the construction of other cryptographic tools. Some cases where you might use a fast collision-resistant hash:

* Timing-attack-resistant string comparison: if you're comparing API keys, you should hash them both first to prevent an attacker from guessing the keys a character at a time.

* HMAC (look it up).

* One can implement key stretching functions by applying fast collision-resistant hashes multiple times.

* Signing (one can hash a message and sign the hash, which provides as much security as signing the message itself).

* Fingerprinting (a fast hash of a public key can be used as shorthand to verify public key ownership without having to read off the entire key).

* Addressing (Bitcoin uses a fast hash of a public key as an address).

Re: SHA-3 Standard [pdf]

#44

Post by laumars »

tedunangst wrote: post #36
laumars wrote: post #31

Earlier quoted context omitted.

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.

I didn't make that assumption. I exampled one use of cryptographic hashes as being for password hashing. An example is not the same as saying two things are the same.

Re: SHA-3 Standard [pdf]

#45

Post by laumars »

schoen wrote: post #40
laumars wrote: post #28

Earlier quoted context omitted.

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, t…

As per https://news.ycombinator.com/item?id=10012384:

I didn't make that assumption. I exampled one use of cryptographic hashes as being for password hashing. An example is not the same as saying two things are the same.

I've possibly expressed myself rather poorly, but I think quite a few people on here have made some incorrect assumptions about the point I was raising.

Re: SHA-3 Standard [pdf]

#46

Post by fryguy »

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.

KDF should be slow.

Stream ciphers should be fast.

Message authentication should be fast.

Hash functions can be used in any of the above, therefore it should be fast. Key derivation functions generally work by taking a secure hash (that can be done fast), and then taking an operation that transforms the output of the hash function to another output that requires a lot of time and/or memory. And then possibly takes the hash of this as well to obscure the internal workings. The "slowness" is part of the KDF, and not part of the hash function. The reason it's tuneable is because it doesn't matter how fast the hash is, you can just run more iterations.

Re: SHA-3 Standard [pdf]

#47

Post by laumars »

copsarebastards wrote: post #43
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

You're being downvoted because despite the "wealth of other content online about using cryptographic hashes for password storage", you haven't actually read enough of it to know that neither SHA3 nor BLAKE are appropriate for password storage. Neither is a key stretching function. Ignorance isn't a sin, but unwarranted overconfidence is. SHA3 and BLAKE are cryptographic hash functions, but they are fast collision res…

I will admit that I'm not familiar with SHA3 nor BLAKE - in fact my OP demonstrates that I'm looking for more information about why BLAKE is a "better" hashing function. But I am actually quite aware of timing attacks, HMAC, and the other points you raised.

Maybe my "wealth of other content online" comment pissed a few people off - but equally I was pissed off that my original comment was downvoted so heavily with a few comments that weren't entirely accurate in response (I've often said the negative rep on HN gets over used and often causes more arguments - but that's another topic). Anyhow, I've removed my offending comment now and glad to see that the quality of responses have improved :)

Re: SHA-3 Standard [pdf]

#48

Post by Perseids »

tptacek wrote: post #7
logicrime wrote: post #5

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

SHA-2 is fine, and in fact the more conservative choice right now. SHA-3 didn't happen because SHA-2 was threatened. My current favorite conservative hash choice is SHA512/256, which is the SHA-2 that generates a 512-bit output but truncates it to 256. It gives you the same length extension protection that is the most important feature of SHA-3, and is available in most libraries already. I have never recommended to…

> SHA-2 is fine, and in fact the more conservative choice right now. SHA-3 didn't happen because SHA-2 was threatened.

To extend on that, shortly after SHA-1 fell, there was the very real threat that the SHA-2 family would follow suit (they are conceptionally similar). This worry brought NIST to hold the SHA-3 competition. Fortunately, the SHA-1 attacks did not turn out to be transferrable, so far, and consequently trust in SHA-2 has substantially increased since. Still, NIST (rightly) followed through with the initial idea of the contest and chose a hash function that was as different from SHA-2 as possible (Keccak).

Thus, we have now two very high quality hash functions to our disposal. If you need a really conservative choice, hash the message m as SHA512(m)||SHA3-512(m) (the concatenation of the individual hashes). This construction is collision resistant if at least one of them remains collision resistant. (Pseudo randomness relies on the security of both hashes, though, and hashing the whole message twice comes at a hefty performance hit. Especially since SHA3-512 is veeery slow – blame it on the clueless tech media attacking NIST for tweaking Keccak, ignoring even the authors who supported NIST's decision.)

Re: SHA-3 Standard [pdf]

#49

Post by tedunangst »

laumars wrote: post #17
alextgordon wrote: post #14

Earlier quoted context omitted.

It's faster (in software).

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

I feel silly just wading back in here, but...

Even assuming we're optimizing our selection for a KDF, blake2 is probably still the better choice. An attacker is likely to be using a hardware implementation. Your server is using software. An algorithm that's comparatively efficient in software reduces the disparity in capabilities.

Re: SHA-3 Standard [pdf]

#50

Post by tedunangst »

laumars wrote: post #39
tedunangst wrote: post #37

Earlier quoted context omitted.

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

"If BLAKE isn't intended for cryptography then it's not a direct competitor to SHA-3."

If you didn't know that BLAKE was one of the entries in the SHA3 competition (one of the finalists in fact), I think you are out of your depth.

Post reply on HN