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

81–90 of 91 posts

Re: SHA-3 Standard [pdf]

#81

Post by logicallee »

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…

whaaaaaaat - taking a 512-bit hash and truncating it to 256 preserves everything you need about it! That's crazy (surprising). Naively - if you hadn't just told me otherwise - I'd think it's up there with my brilliant new algorithm: in a loop pad your input with 0x00 through 0xFF, take the SHA512 hash of each result, but only use the first bit! You now have a sooper secure 256 bit hash. I call it SHA512/1/1/.../1 (I'd write it all out here, but it looks obnoxious and might break someone's window width.)

Re: SHA-3 Standard [pdf]

#82

Post by [deleted] »

elithrar wrote: post #68
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.

> SHA2 + salt + pepper is sufficient Not even close. The attempts/sec you can run against SHA-2 vs. the attempts/sec you can run against bcrypt or scrypt are an order of magnitude apart. You should not use anything less than a proven KDF (scrypt, bcrypt, PBKDF2-HMAC-SHA2 with a lot of rounds) for password storage. Many of your posts conflate "cryptographic" with "password hashing", which is certainly not the case. No…

[deleted]

Re: SHA-3 Standard [pdf]

#83

Post by copsarebastards »

alextgordon wrote: post #14
serge2k wrote: post #13

Earlier quoted context omitted.

Why, what's better about BLAKE?

It's faster (in software).

This is a disturbing answer. You come out strongly in favor of BLAKE, but without any consideration of its security properties, just "it's faster".

BLAKE uses the same basic construction as MD5 and SHA1, neither of which is a responsible choice for a collision-resistant hash function any more. While attacks producing collisions have not been presented, this construction means it's susceptible to some other attacks. There are well-understood ways to avoid these attacks, but a naive usage of BLAKE2 in a production system will likely leave you open to length extension attacks in particular.

Keccak, on the other hand, uses the novel sponge construction, which injects content into the hash (absorb phase) and then iterates a threshing function (squeeze phase). This construction specifically addresses security concerns which BLAKE2 simply doesn't.

To be clear: I do think the BLAKE developers made a good contribution to the security community: particularly, using ChaCha makes their algorithm very fast, and I suspect that the next generation of fast collision-resistant hash functions will use ChaCha in the sponge construction. There are situations where BLAKE is a better choice than SHA3. But its use requires a great deal of knowledge and care to be secure, and for the average person implementing a secure system, SHA3 is a much more responsible choice.

Security should not be taken lightly. Bad security can expose people's private information and get people jailed, doxxed, and sometimes even killed. Glibly claiming BLAKE is better without any discussion of the security properties of the algorithms is completely irresponsible.

Re: SHA-3 Standard [pdf]

#84

Post by pbsd »

copsarebastards wrote: post #83
alextgordon wrote: post #14

Earlier quoted context omitted.

It's faster (in software).

This is a disturbing answer. You come out strongly in favor of BLAKE, but without any consideration of its security properties, just "it's faster". BLAKE uses the same basic construction as MD5 and SHA1, neither of which is a responsible choice for a collision-resistant hash function any more. While attacks producing collisions have not been presented, this construction means it's susceptible to some other attacks. T…

BLAKE(2) is not open to length-extension attacks---in fact resistance to those was a requirement of any SHA-3 submission. Its design does not have much in common with MD5 and SHA-1 beyond the usage of the compression function building block, instead of a public permutation as sponges do. The mode of operation of BLAKE is not Merkle-Damgard, but a variant of HAIFA.

As far as security goes, Keccak and BLAKE are mostly in equal standing both in security margin (number of rounds attacked vs total number of rounds) and cryptanalytic attention received.

Re: SHA-3 Standard [pdf]

#85

Post by tptacek »

copsarebastards wrote: post #83
alextgordon wrote: post #14

Earlier quoted context omitted.

It's faster (in software).

This is a disturbing answer. You come out strongly in favor of BLAKE, but without any consideration of its security properties, just "it's faster". BLAKE uses the same basic construction as MD5 and SHA1, neither of which is a responsible choice for a collision-resistant hash function any more. While attacks producing collisions have not been presented, this construction means it's susceptible to some other attacks. T…

Can you please explain where exactly you got the idea that BLAKE2 was length-extendable?

Can you also please explain some of these other attacks you're talking about it sharing with MD5 and SHA1? The commonality between MD5, SHA1, and SHA2 is the Merkle Damgard structure. BLAKE2 isn't an MD hash. Are these MD attacks that you're asserting apply to BLAKE2?

I'd like to know where the certitude you're projecting is coming from.

Re: SHA-3 Standard [pdf]

#86

Post by atoponce »

pbsd wrote: post #84
copsarebastards wrote: post #83

Earlier quoted context omitted.

This is a disturbing answer. You come out strongly in favor of BLAKE, but without any consideration of its security properties, just "it's faster". BLAKE uses the same basic construction as MD5 and SHA1, neither of which is a responsible choice for a collision-resistant hash function any more. While attacks producing collisions have not been presented, this construction means it's susceptible to some other attacks. T…

BLAKE(2) is not open to length-extension attacks---in fact resistance to those was a requirement of any SHA-3 submission. Its design does not have much in common with MD5 and SHA-1 beyond the usage of the compression function building block, instead of a public permutation as sponges do. The mode of operation of BLAKE is not Merkle-Damgard, but a variant of HAIFA. As far as security goes, Keccak and BLAKE are mostly…

You can read about HAIFA here: http://csrc.nist.gov/groups/ST/hash/documents/DUNKELMAN_NIST...

Re: SHA-3 Standard [pdf]

#87

Post by atoponce »

alextgordon wrote: post #14
serge2k wrote: post #13

Earlier quoted context omitted.

Why, what's better about BLAKE?

It's faster (in software).

Supposedly. So far, I haven't found a software implementation that is faster than MD5. However, I have found plenty of Skein software implementations that come close to meeting the speed specification.

See http://ae7.st/p/5px. I'm using the reference code at https://github.com/BLAKE2/BLAKE2 for blake2, and https://jxself.org/git/?p=skeinsum.git for skein.

Re: SHA-3 Standard [pdf]

#88

Post by Snesker »

copsarebastards wrote: post #83
alextgordon wrote: post #14

Earlier quoted context omitted.

It's faster (in software).

This is a disturbing answer. You come out strongly in favor of BLAKE, but without any consideration of its security properties, just "it's faster". BLAKE uses the same basic construction as MD5 and SHA1, neither of which is a responsible choice for a collision-resistant hash function any more. While attacks producing collisions have not been presented, this construction means it's susceptible to some other attacks. T…

You've misspelled a word, fella. https://stallman.org/doxing.html

Re: SHA-3 Standard [pdf]

#89

Post by copsarebastards »

tptacek wrote: post #85
copsarebastards wrote: post #83

Earlier quoted context omitted.

This is a disturbing answer. You come out strongly in favor of BLAKE, but without any consideration of its security properties, just "it's faster". BLAKE uses the same basic construction as MD5 and SHA1, neither of which is a responsible choice for a collision-resistant hash function any more. While attacks producing collisions have not been presented, this construction means it's susceptible to some other attacks. T…

Can you please explain where exactly you got the idea that BLAKE2 was length-extendable? Can you also please explain some of these other attacks you're talking about it sharing with MD5 and SHA1? The commonality between MD5, SHA1, and SHA2 is the Merkle Damgard structure. BLAKE2 isn't an MD hash. Are these MD attacks that you're asserting apply to BLAKE2? I'd like to know where the certitude you're projecting is comi…

> Can you please explain where exactly you got the idea that BLAKE2 was length-extendable?

No, you're right: I misunderstood the algorithm; an extension attack has not yet been found. My core point still stands though: choosing a cryptographic anything should start with a consideration of the security properties of the algorithm, and only then should we talk about speed.

Re: SHA-3 Standard [pdf]

#90

Post by copsarebastards »

pbsd wrote: post #84
copsarebastards wrote: post #83

Earlier quoted context omitted.

This is a disturbing answer. You come out strongly in favor of BLAKE, but without any consideration of its security properties, just "it's faster". BLAKE uses the same basic construction as MD5 and SHA1, neither of which is a responsible choice for a collision-resistant hash function any more. While attacks producing collisions have not been presented, this construction means it's susceptible to some other attacks. T…

BLAKE(2) is not open to length-extension attacks---in fact resistance to those was a requirement of any SHA-3 submission. Its design does not have much in common with MD5 and SHA-1 beyond the usage of the compression function building block, instead of a public permutation as sponges do. The mode of operation of BLAKE is not Merkle-Damgard, but a variant of HAIFA. As far as security goes, Keccak and BLAKE are mostly…

> BLAKE(2) is not open to length-extension attacks---in fact resistance to those was a requirement of any SHA-3 submission.

I did make a mistake understanding the algorithm. You're mostly right: no length extension attack has yet been found. However, HAIFA is far more similar to MD than the sponge construction, and this is widely cited as a reason for Keccak's selection.

> As far as security goes, Keccak and BLAKE are mostly in equal standing both in security margin (number of rounds attacked vs total number of rounds) and cryptanalytic attention received.

Then why was Keccak selected? It's clear that at least some analysts think Keccak has significant advantages over BLAKE.

And ultimately my point still stands: a comparison of cryptographic hashes should start with a discussion of their security properties. Glibly stating "it's faster therefore it's better!" is highly dangerous.

Post reply on HN