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

51–60 of 91 posts

Re: SHA-3 Standard [pdf]

#51

Post by Dylan16807 »

laumars wrote: post #44
tedunangst wrote: post #36

Earlier quoted context omitted.

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.

For a fast hash, being fast is always better. You were not pointing out that there are other metrics, you were directly contradicting a true statement, that BLAKE being faster makes it better.

There is no use case where you want your super-fast hash to be 50% slower.

With a hash this fast you need to get thousands or more times slower to have any benefits in those specialized use cases.

It's sort of a bathtub curve.

Re: SHA-3 Standard [pdf]

#52

Post by laumars »

tedunangst wrote: post #50
laumars wrote: post #39

Earlier quoted context omitted.

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

Those two points aren't mutually inclusive. I do understand cryptography and hashes - maybe not to a security researchers level nor be up to date with the latest proposals - but that doesn't mean I'm out of my depth to ask the questions I've been asking either.

Furthermore, the way you conduct yourself in these posts isn't exactly helpful. You're condescending and terse. Your comments contain the bare minimum information (or in the case of this latest exchange, no useful information what-so-ever) and it feels very much like you're more interested in winning ego points than you are in educating someone who could clearly benefit from your greater wisdom. Which is sad because without that exchange of knowledge, these kinds of threads will keep happening.

edit: that said, I did appreciate your comment about hardware vs software: https://news.ycombinator.com/item?id=10012537 so thank you for that post :)

Re: SHA-3 Standard [pdf]

#53

Post by harshreality »

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…

Unfortunately, the SHA cpu extensions that will soon be available in Skylake Xeon parts (and the crypto extensions in ARMv8-a) only support sha2-256 (and SHA256/224, and the ill-advised sha1... why is Intel adding instructions or microcode for a hash function that's being phased out?). So you have a choice between a faster-in-software-on-64bit sha-512/256 and a faster-in-hardware sha-256. Unless there's some way to get partial speed-up of sha-512 using sha-256 instructions, but at a glance they don't look low-level enough to apply to sha-512... do they?

Or you can ignore both sha256 and sha512/256 and use something else like sha-3 or blake2b. Blake2b obviously has less attention on it so more likely to harbor a weakness, but it's fast in software. And sha-3 will get cpu extensions eventually, and it'll hopefully be a better thought out inplementation than just support for the 256-bit variant.

Re: SHA-3 Standard [pdf]

#54

Post by Retr0spectrum »

tedunangst wrote: post #16
infinity0 wrote: post #8

If I were the NSA, how would I backdoor this?

I would tell people new crypto can't be trusted, and they should stick with proven standards like MD5.

That's exactly what the NSA would say to get us to use a new, backdoored hash function! /s

Re: SHA-3 Standard [pdf]

#55

Post by tedunangst »

laumars wrote: post #52
tedunangst wrote: post #50

Earlier quoted context omitted.

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

Those two points aren't mutually inclusive. I do understand cryptography and hashes - maybe not to a security researchers level nor be up to date with the latest proposals - but that doesn't mean I'm out of my depth to ask the questions I've been asking either. Furthermore, the way you conduct yourself in these posts isn't exactly helpful. You're condescending and terse. Your comments contain the bare minimum informa…

If you're interested in learning, ask more questions. This thread started off with some dubious statements, and when that was pointed out, you dug in deeper and deeper. That doesn't inspire much confidence that you will appreciate someone taking the time to educate you. Hence, the terseness.

Re: SHA-3 Standard [pdf]

#56

Post by yabun »

Perseids wrote: post #48
tptacek wrote: post #7

Earlier quoted context omitted.

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

Concatenation of the hashes seems like an unjustified risk, that in certain circumstances will allow weaknesses from either algorithm to flow throw to the final hash. If you really want to combine the hashes, XOR seems like a safer bet to me (since the algorithms are unrelated there should be no potential cancellation of entropy).

Re: SHA-3 Standard [pdf]

#57

Post by tptacek »

harshreality wrote: post #53
tptacek wrote: post #7

Earlier quoted context omitted.

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…

Unfortunately, the SHA cpu extensions that will soon be available in Skylake Xeon parts (and the crypto extensions in ARMv8-a) only support sha2-256 (and SHA256/224, and the ill-advised sha1... why is Intel adding instructions or microcode for a hash function that's being phased out?). So you have a choice between a faster-in-software-on-64bit sha-512/256 and a faster-in-hardware sha-256. Unless there's some way to g…

512/224 is fine too, and also isn't length extendable.

Re: SHA-3 Standard [pdf]

#58

Post by laumars »

tedunangst wrote: post #55
laumars wrote: post #52

Earlier quoted context omitted.

Those two points aren't mutually inclusive. I do understand cryptography and hashes - maybe not to a security researchers level nor be up to date with the latest proposals - but that doesn't mean I'm out of my depth to ask the questions I've been asking either. Furthermore, the way you conduct yourself in these posts isn't exactly helpful. You're condescending and terse. Your comments contain the bare minimum informa…

If you're interested in learning, ask more questions. This thread started off with some dubious statements, and when that was pointed out, you dug in deeper and deeper. That doesn't inspire much confidence that you will appreciate someone taking the time to educate you. Hence, the terseness.

My first draft of that post was more question-based than statement-based but for some reason I thought the rewritten version was better presented. In hindsight that was really poor judgement on my part. Sorry for that. But I assure you that I'm very much interested in learning :)

The "digging deeper" was more down to responding to other people who had misunderstood my original comment. And lets be honest, there has been a lot of that as well.

edit: oh jeez, someone's been on the rampage with the ▾ clicking. I think it's time I get HN a break because the moderation on here has really been bugging me in recent months. I know it's a tired cliche, but I'm sure this community used to be less hostile.

Re: SHA-3 Standard [pdf]

#59

Post by [deleted] »

tptacek wrote: post #57
harshreality wrote: post #53

Earlier quoted context omitted.

Unfortunately, the SHA cpu extensions that will soon be available in Skylake Xeon parts (and the crypto extensions in ARMv8-a) only support sha2-256 (and SHA256/224, and the ill-advised sha1... why is Intel adding instructions or microcode for a hash function that's being phased out?). So you have a choice between a faster-in-software-on-64bit sha-512/256 and a faster-in-hardware sha-256. Unless there's some way to g…

512/224 is fine too, and also isn't length extendable.

[deleted]
Post reply on HN