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

21–30 of 91 posts

Re: SHA-3 Standard [pdf]

#21

Post by schoen »

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

There are lots of non-password-hashing applications of cryptographic hashes, like virtually every authenticity application. Your computer calculated hashes to allow you to post that post on HN.

Although we do want hashing to be slow when it's password hashing, that doesn't mean we want our general-purpose hash primitives themselves to be slow.

Re: SHA-3 Standard [pdf]

#22

Post by 0x0 »

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

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?)

Re: SHA-3 Standard [pdf]

#23

Post by emboss »

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

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/

Re: SHA-3 Standard [pdf]

#24

Post by laumars »

ori_b wrote: post #19
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

No -- You are confusing password hashing algorithms with general purpose hashing algorithms. Algorithms like bcrypt and scrypt have a tunable difficulty parameter, and are designed to be slow. For general purpose hashing, you want to check if the fingerprint of these ten gigabytes of data is the same as the fingerprint of these other ten gigabytes, as quickly as possible. Or whether a file that you downloaded is the…

I'm not getting confused. SHA-3 can be used for cryptographic hashing. In the linked PDF:

"The SHA-3 family consists of four cryptographic hash functions, called SHA3-224, SHA3-256, SHA3-384, and SHA3-512, and two extendable-output functions (XOFs), called SHAKE128 and SHAKE256."

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

Re: SHA-3 Standard [pdf]

#25

Post by twotwotwo »

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…

++ on SHA-512/256. SHA-512 uses 64-bit operations where SHA-256 uses 32-bit, so on a beefy 64-bit chip, it's faster per byte hashed. So, compared to SHA-256, more rounds, twice the state size, same familiar/widely-implemented design, and faster -- what's not to love?

See http://bench.cr.yp.to/results-hash.html for a comparison of hash-function speeds.

Re: SHA-3 Standard [pdf]

#26

Post by laumars »

hroi wrote: post #20
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

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.

Re: SHA-3 Standard [pdf]

#27

Post by ori_b »

laumars wrote: post #24
ori_b wrote: post #19

Earlier quoted context omitted.

No -- You are confusing password hashing algorithms with general purpose hashing algorithms. Algorithms like bcrypt and scrypt have a tunable difficulty parameter, and are designed to be slow. For general purpose hashing, you want to check if the fingerprint of these ten gigabytes of data is the same as the fingerprint of these other ten gigabytes, as quickly as possible. Or whether a file that you downloaded is the…

I'm not getting confused. SHA-3 can be used for cryptographic hashing. In the linked PDF: "The SHA-3 family consists of four cryptographic hash functions, called SHA3-224, SHA3-256, SHA3-384, and SHA3-512, and two extendable-output functions (XOFs), called SHAKE128 and SHAKE256." If BLAKE isn't intended for cryptography then it's not a direct competitor to SHA-3.

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 they are designed to be fast, and this makes it easier to brute force them.

Re: SHA-3 Standard [pdf]

#28

Post by laumars »

0x0 wrote: post #22
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

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

Re: SHA-3 Standard [pdf]

#29

Post by laumars »

schoen wrote: post #21
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

There are lots of non-password-hashing applications of cryptographic hashes, like virtually every authenticity application. Your computer calculated hashes to allow you to post that post on HN. Although we do want hashing to be slow when it's password hashing, that doesn't mean we want our general-purpose hash primitives themselves to be slow.

I know. I made that comment in the post you're replying to.

Re: SHA-3 Standard [pdf]

#30

Post by laumars »

ori_b wrote: post #27
laumars wrote: post #24

Earlier quoted context omitted.

I'm not getting confused. SHA-3 can be used for cryptographic hashing. In the linked PDF: "The SHA-3 family consists of four cryptographic hash functions, called SHA3-224, SHA3-256, SHA3-384, and SHA3-512, and two extendable-output functions (XOFs), called SHAKE128 and SHAKE256." If BLAKE isn't intended for cryptography then it's not a direct competitor to SHA-3.

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 iteration parameter so passwords can be hardened as harder gets faster.

Post reply on HN