Live data from Hacker News

Maybe we shouldn't skip SHA-3

cryptologie.net

61–70 of 112 posts

Re: Maybe we shouldn't skip SHA-3

#61

Earlier quoted context omitted.

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

Heh heard that one, and the always very convincing answer in a discussion to do or not do certain things...

"if it is on the checklist, then.. it is on the checklist"

Re: Maybe we shouldn't skip SHA-3

#62
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 use case isn't security critical, and you know for a fact it won't become security critical later, and MD5 is convenient for whatever reason, then just use MD5.

Pardon my frustration, but: Jesus Christ, people. Why do we need to sell everyone on the fancy new thing in a hypothetical situation where it is defined not to matter?

Re: Maybe we shouldn't skip SHA-3

#63
post #47
post #17

Earlier quoted context omitted.

This is a little like saying that if you told someone to use Rijndael they might instead use DES.

I really don't agree. Rijndael and DES are different algorithm. SHA-512/256 is a made-up algorithm that you need to be aware of. Again I'm talking about "misuse" here. SHA-2 is vulnerable to misuse even if SHA-512/256 is not.

I think you're reaching here.

Re: Maybe we shouldn't skip SHA-3

#64
post #11
post #7

Earlier quoted context omitted.

I think our comments and discussions just add to the general confusion though, this is why I just plainly recommend SHA-3. Now if I would personally work on a project I would think of SHAKE first, and I would seriously consider KangarooTwelve (especially for tree hashing, which makes K12 better than any other hash to hash big files).

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…

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

The name is a serious problem. If you work with this stuff regularly enough to know the difference it might seem obvious, but that's not the case for many would-be implementors and bug-fixers.

The name makes communication problematic enough to not recommend usage.

Re: Maybe we shouldn't skip SHA-3

#65
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?

Make sure it can easily be replaced if needed though. I also use it in contexts where I need some consistent "randomization" (like your hash ring).

The thing is that even though security might not be an issue in your application, you might discover in the future that it is. For example python dict relies on hash table to store key-values, doesn't seem like something that would be concerning (you're not encrypting or keeping anything secret), but python applications then started being targeted by collision attacks. The attacks' goal was to insert many elements that hashed to the same value, which caused DoS. Their solution though was to use salt value which is different on every run.

The point is that something that might not seem like a security issue might turn out to be later on. It doesn't necessary mean we should always strong cryptographic hash functions (in many cases they might be too expensive) but at least write code in such way that we can easily replace it with something else if we need to.

Re: Maybe we shouldn't skip SHA-3

#66

Earlier quoted context omitted.

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?

Maybe because it is less popular, this is first time I hear about it. Probably it's also not as widely available.

Re: Maybe we shouldn't skip SHA-3

#67
post #62

Earlier quoted context omitted.

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

If the use case isn't security critical, and you know for a fact it won't become security critical later, and MD5 is convenient for whatever reason, then just use MD5. Pardon my frustration, but: Jesus Christ, people. Why do we need to sell everyone on the fancy new thing in a hypothetical situation where it is defined not to matter?

Exactly this. I dont like when people try to sell new things even though my use case is perfectly fine with the older solution. I understand the security implications, yet there more to this topic than just security.

Re: Maybe we shouldn't skip SHA-3

#68

Earlier quoted context omitted.

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?

I agree. There is also siphash that we use.

Re: Maybe we shouldn't skip SHA-3

#69
post #64
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…

> 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? The name is a serious problem. If you work with this stuff regularly enough to know the difference it might seem obvious, but that's not the case for many would-be implementors and bug-fixers. The name makes communication problematic enough to not recommend usage.

No, it doesn't. SHA-2 is by an overwhelming margin the most popular hash used in cryptosystems today, and it is overwhelmingly used safely.

Seriously, if you care that much about the name, rename it; Even systems that use SHA-3 use HMAC (SHA-2 is perfectly safe, no matter what variant you use, in HMAC). Name the prefix MAC (an idiosyncratic construction) that uses SHA-2 something specific.

The SHA-3 advocates have already conceded this point. They don't call SHA-3's prefix MAC "prefix MAC"; they call it KMAC, which is a specific construction.

So all you have to accept is that there's SHA2MAC --- which, like KMAC, is not simply the hash function, but instead the optimal MAC construction built on the hash --- and then define it as the prefix MAC built from SHA2-512/256.

Re: Maybe we shouldn't skip SHA-3

#70
post #63
post #47

Earlier quoted context omitted.

I really don't agree. Rijndael and DES are different algorithm. SHA-512/256 is a made-up algorithm that you need to be aware of. Again I'm talking about "misuse" here. SHA-2 is vulnerable to misuse even if SHA-512/256 is not.

I think you're reaching here.

I might be a bit. Although, I don't feel like it's too far from the kind of misuse we've pointed out with nonce re-use in AES-GCM or nonce re-use in DSA/ECDSA.

Anyway that was my point! Just wanted to write it up :)

Post reply on HN