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

91–100 of 112 posts

Re: Maybe we shouldn't skip SHA-3

#91

Post by ghshephard »

tptacek wrote: post #11
baby wrote: 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…

This thread is the first time I was ever aware that "SHA-2 512/256" was actually a unique and different algorithm. I've always thought it was just the last 256 bits of SHA-512.

Also, just looking at a reasonably recent version of Python 3.6: (dir(hashlib))

"'blake2b', 'blake2s', 'md5', 'new', 'pbkdf2_hmac', 'sha1', 'sha224', 'sha256', 'sha384', 'sha3_224', 'sha3_256', 'sha3_384', 'sha3_512', 'sha512', 'shake_128', 'shake_256']"

So - no reference to sha2_512/256 as a unique algorithm there either. Nothing in https://docs.python.org/3/library/hashlib.html either. So, the whole SHA-2 512/256 thing isn't that straightforward.

With that said, I would hope that anyone who was doing this for a real purpose would at least take 10 minutes to read the wikipedia page. And lots of useful information on crypto.stackexchange.com as well.

Re: Maybe we shouldn't skip SHA-3

#92

Post by tptacek »

ghshephard wrote: post #91
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…

This thread is the first time I was ever aware that "SHA-2 512/256" was actually a unique and different algorithm. I've always thought it was just the last 256 bits of SHA-512. Also, just looking at a reasonably recent version of Python 3.6: (dir(hashlib)) "'blake2b', 'blake2s', 'md5', 'new', 'pbkdf2_hmac', 'sha1', 'sha224', 'sha256', 'sha384', 'sha3_224', 'sha3_256', 'sha3_384', 'sha3_512', 'sha512', 'shake_128', 's…

It's not a unique and different algorithm. It is simply a truncated SHA-2 512 hash.

Re: Maybe we shouldn't skip SHA-3

#93

Post by tptacek »

azinman2 wrote: post #86
cryptonector wrote: post #52

Earlier quoted context omitted.

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

For us who don't know better, could you explain why MD5 or SHA1 are ok in an HMAC context?

Because a collision in MD5 doesn't give you a second preimage of an MD5 hash.

Re: Maybe we shouldn't skip SHA-3

#94

Post by andrewflnr »

btrask wrote: post #62
StreamBright wrote: post #46

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?

A situation where it is defined not to matter is unrealistic. Things you don't think are "security critical" have a tendency to unexpectedly become so; at least that's my impression. Why not use a more secure algorithm?

Re: Maybe we shouldn't skip SHA-3

#95

Post by cryptonector »

iRobbery wrote: post #61
cryptonector wrote: post #52

Earlier quoted context omitted.

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"

There is lots of junk on those checklists. Like "must implement n-strikes you're locked", which is idiotic in many contexts.

Re: Maybe we shouldn't skip SHA-3

#96

Post by yuhong »

dom0 wrote: post #76
oconnor663 wrote: post #44

Earlier quoted context omitted.

BLAKE2 is faster than MD5. I think that means there's no longer any reason to use MD5 in new applications, if you have any choice.

While the portable, pure C implementation of BLAKE2 that is used almost exclusively by libraries (e.g. Python, OpenSSL) is already faster than MD5... ...there are even faster implementations of BLAKE2 around. E.g. Samuel Neves' AVX2 implementation is almost 40 % faster on Haswell. libsodium ships a different AVX2 implementation (considered experimental AFAIK by its original author, so I find that a bit strange).

For this kinds of thing, I am thinking that it might be worth it to do a "web browser" mode which uses 128-bit vectors and a "web server" mode which use 256-bit.

Re: Maybe we shouldn't skip SHA-3

#97

Post by briansmith »

tptacek wrote: post #92
ghshephard wrote: post #91

Earlier quoted context omitted.

This thread is the first time I was ever aware that "SHA-2 512/256" was actually a unique and different algorithm. I've always thought it was just the last 256 bits of SHA-512. Also, just looking at a reasonably recent version of Python 3.6: (dir(hashlib)) "'blake2b', 'blake2s', 'md5', 'new', 'pbkdf2_hmac', 'sha1', 'sha224', 'sha256', 'sha384', 'sha3_224', 'sha3_256', 'sha3_384', 'sha3_512', 'sha512', 'shake_128', 's…

It's not a unique and different algorithm. It is simply a truncated SHA-2 512 hash.

NIST did specify a SHA-512/256 that has its own IV, like SHA-384.

Re: Maybe we shouldn't skip SHA-3

#98

Post by nincompope »

aseipp wrote: post #10
JoshTriplett wrote: post #4

Earlier quoted context omitted.

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

The parameters NIST specified are just fairly conservative, for one thing (e.g. NIST, IIRC, oddly requested an increase in the number of rounds during the final stages, one of the things people waxed on about.) Regarding another variant: yes, you can get more compelling results, and the authors of Keccak themselves have also proposed another function based on Keccak called KangarooTwelve[1]. K12 has much better perfo…

As far as I can tell, the increase from 18 to 24 rounds was not NIST's call, but due to the zero-sum distinguishers found on Keccak-f, which made it no longer "hermetic": http://keccak.noekeon.org/NoteZeroSum.pdf

Re: Maybe we shouldn't skip SHA-3

#99

Post by arnarbi »

taneq wrote: post #23
JoachimS wrote: post #18

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?

It depends what you're using it for, no? If you're using it as part of an auth mechanism then sure, don't use it. If you're using it for anything else (checksum, verification etc.) where you don't expect any adversarial action then it's fine.

I'd much rather have it as a well known meme that "md5 is broken, don't use it. Period." than a list of caveats like "ok for non security" or "ok with hmac".

I've seen many claims from good engineers of the sort "this design is ok because it's not for security" when it absolutely was.

A simpler rule wins, even if it costs a bit now. It'll save someone in a bigger way later.

Re: Maybe we shouldn't skip SHA-3

#100

Post by nincompope »

apendleton wrote: post #89
dsacco wrote: post #71

Earlier quoted context omitted.

That's not necessarily a dangerous assertion. SHA-2 is theoretically immune to foreseeable improvements in computational power. If you use something like SHA-512, a birthday attack will require searching through approximately more candidates than there are atoms in the observable universe. You can't meaningfully improve this by scaling up inordinate amounts of computing power. If you can't rely on raw computational p…

Would it also be fair to say that novel math could just as easily be discovered that would break SHA-3, and so, switching to SHA-3 would not reduce risk? (Or, worse: might it increase it, since the SHA-3 constructions have been subject to less cryptographic research and so might be more likely to fall to some kind of new math?)

It's arguable that SHA-3 is better understood than SHA-2, at least in the open research community. The rationales behind every component of SHA-3 are well documented, and the design is very conservative, both in structure and number of rounds. More so than SHA-2.

It is in theory possible that a new technique could break SHA-3 and not SHA-2, but the opposite seems far more plausible.

Post reply on HN