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

Maybe we shouldn't skip SHA-3

cryptologie.net

Post reply on HN
Print view View original

51–60 of 112 posts

Re: Maybe we shouldn't skip SHA-3

#51

Post by tytso »

I think the argument that people could misuse SHA-2 is bogus, because if people are rolling their own crypto, they can get themselves into a lot of trouble, not just with SHA-2(key || data). Indeed, that argument may cause people to assume that it's ok for application programmers to do cryptographic protocol engineering, which would be disastrous.

A much more general argument is that most people should be using cryptographic frameworks (e.g., which implement TLS), and Adam Langley's thoughts about whether or not SHA-2 should be skipped should be aimed at people who are creating those cryptographic frameworks.

But if we are giving advice to random application programmers, they shouldn't be trying to pick cryptographic algorithms to begin with, and the question of whether you should be using SHA-2(key || data) is the sort of thing where the Zen master would be hitting the student with a cluestick for asking the wrong question to begin with.

Re: Maybe we shouldn't skip SHA-3

#52

Post by cryptonector »

JoachimS wrote: post #18
tptacek wrote: post #2

If you're going to pick a hash specifically to avoid length-extension attacks, pick SHA-2 512/256, which isn't vulnerable to length extension attacks. Or, for that matter, pick Blake2, which is a slightly less idiosyncratic choice than SHA-3. Everyone --- including the authors of SHA-3 --- is unhappy with the SHA-3 parameters and resulting performance. SHA-2 512/256 is much faster than SHA-3 and supported by more lib…

Regarding MD5. I advice people from using MD5 in new designs even if it is for HMAC-MD5. Not because that construct is broken (which it isn't), but because we add yet another dependency on an algorithm we in general consider too weak to use. Do you agreee with that advice?

Yes-ish. I don't sweat HMAC-MD5, nor HMAC-SHA-1. What really sucks though is when you can't use them (even though for interop reasons you must) because some stupid auditor (typically software) goes "oh no! MD5 found!! alert! alert!".

Re: Maybe we shouldn't skip SHA-3

#53

Post by throw86045651 »

tracked24x7 wrote: post #15
tptacek wrote: post #11

Earlier quoted context omitted.

You keep saying that here, and on Twitter, and people --- not just me --- keep telling you that if you're going to recommend a hash specifically to avoid length extension attacks, 512/256 accomplishes that without requiring the adoption of new hashing code. I really don't understand the argument that people can safely type "SHA-3" but not "SHA-2 512/256". Would it help if we renamed SHA-2 512/256? We could call it SH…

Are your respective companies (yours and OP's) business competitors?

They are both professional consultants in this space.

Re: Maybe we shouldn't skip SHA-3

#54

Post by bradleyjg »

StreamBright wrote: post #46
tptacek wrote: post #22

Earlier quoted context omitted.

Definitely don't use MD5!

What if the use case is not security sensitive, I just want to implement a distributed hash ring for example?

If the application isn't security sensitive why not a faster non-cryptographic hash like farmhash?

Re: Maybe we shouldn't skip SHA-3

#55

Post by stouset »

StreamBright wrote: post #46
tptacek wrote: post #22

Earlier quoted context omitted.

Definitely don't use MD5!

What if the use case is not security sensitive, I just want to implement a distributed hash ring for example?

BLAKE2 is faster and has features you might find useful in that sort of scenario. And doesn't forfeit security, should you decide to use this in a an unexpectedly security-sensitive application.

Re: Maybe we shouldn't skip SHA-3

#56

Post by cryptonector »

JoshTriplett wrote: post #4
tptacek wrote: post #2

If you're going to pick a hash specifically to avoid length-extension attacks, pick SHA-2 512/256, which isn't vulnerable to length extension attacks. Or, for that matter, pick Blake2, which is a slightly less idiosyncratic choice than SHA-3. Everyone --- including the authors of SHA-3 --- is unhappy with the SHA-3 parameters and resulting performance. SHA-2 512/256 is much faster than SHA-3 and supported by more lib…

> Everyone --- including the authors of SHA-3 --- is unhappy with the SHA-3 parameters and resulting performance. Would another variant of Keccak, not the one that became SHA-3, provide more competitive results? Or does Keccak in general not have compelling properties compared to the alternatives?

SHAKE is Keccack with parameters that are comparable to SHA-2's, and so performs better.

Re: Maybe we shouldn't skip SHA-3

#57

Post by remcob »

In which use cases is the asymptotic cycles per byte relevant compared to the small case performance?

I mostly use hashes as part of signing/verifying small messages, say an 80 byte JWT, a Blockchain transaction, a certificate, an TLS/SSH packet, etc. Besides hashing large files (which I rarely do), I don't see where I would reach asymptotic performance, or even use tree-hashing.

SHA3's block size is 200 bytes, KangarooTwelve's is, if I'm not mistaken, 8192? I'm more worried about not even filling the first block :)

Re: Maybe we shouldn't skip SHA-3

#58

Post by ben0x539 »

sp332 wrote: post #27
tptacek wrote: post #11

Earlier quoted context omitted.

You keep saying that here, and on Twitter, and people --- not just me --- keep telling you that if you're going to recommend a hash specifically to avoid length extension attacks, 512/256 accomplishes that without requiring the adoption of new hashing code. I really don't understand the argument that people can safely type "SHA-3" but not "SHA-2 512/256". Would it help if we renamed SHA-2 512/256? We could call it SH…

We should definitely rename it, because until yesterday I didn't know that "SHA-512/256" was an actual thing. I thought it was just shorthand referring to both SHA-512 and SHA-256. Edit: this comment got 7 upvotes before the editing timeout, so I'm not the only one either.

Having read the article and the comments above yours, and being generally aware that there's some truncation thing related to SHA-256 and SHA-512 somewhere, it still took me until your comment to catch onto that.

Re: Maybe we shouldn't skip SHA-3

#60

Post by niftich »

It's unfortunate that the 'bar' in misuse-resistant crypto isn't always equally high, and different experts (as evidenced from this thread) argue that you get there in different ways. In that regard, I think the author makes a good point: despite the hard-to-implement-in-hardware aspect of GCM, the dangers of nonce reuse have always been well-documented, and it's only recently that that went from being a simple algorithmic contract to bad design worthy of correction.

I think the point the OP makes is that a suggestion like "use SHA-3" is a simple, succinct, and not-unacceptable answer to a question like "what cryptographic hash function should I use?", giving a safe albeit conservative, but instantly graspable answer without having to go into additional detail -- other than the obligatory mention to that general-purpose hash functions aren't by themselves appropriate for key derivation ("password hashing").

The alternative view -- that SHA-512/256 (which suffers from its naming), or the longer-but-less-truncated-state SHA-384 is faster, more studied, more widely supported -- is a more nuanced recommendation, but then you have to explain why you don't mean SHA-256 or SHA-512. The innovation of libraries like nacl and libsodium was to the user of crypto from having to be a crypto expert themselves, and once you have to explain which of the SHA-2 hashes specified in FIPS PUB 180-4 you should and shouldn't use, we're not really any better than in the footgun days.

Post reply on HN