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

Maybe Skip SHA-3

imperialviolet.org

Post reply on HN
Print view View original

111–120 of 188 posts

Re: Maybe Skip SHA-3

#111

Post by dchest »

gigatexal wrote: post #68
jasode wrote: post #58

Earlier quoted context omitted.

>I'm curious about the statement that SHA-3 is slow; [...] I wonder how much relative attention the SHA-3 winner (Keccak) gets compared to other alternatives, like BLAKE? Coincidentally, I ran a bunch of hash performance benchmarks last week. These were my findings: test: hash a 500MB block of memory. hardware: Intel Core i7-5820K Haswell-E 6-Core 3.3GHz compiler: MSVC2017 (19.10.25019), 32-bit exe: blake2sp - offici…

It'd be interesting to see what SHA2-512 would do since I think modern intel CPUs prefer that size to 256. (I could be wrong though as i have no source to cite just something I remember reading.)

You're not wrong. Type this into Terminal:

     openssl speed sha512 sha256

Re: Maybe Skip SHA-3

#112

Post by stouset »

baby wrote: post #108
stouset wrote: post #106

Earlier quoted context omitted.

SHA-3 is currently a reasonable choice for effectively zero real world use-cases. SHA-2 has many advantages over it, and I can't think of a single disadvantage. SHA-3 has practical value as a moderately well-analyzed cipher in the event of rapid catastrophic cryptanalysis of SHA-2, but barring that kind of event its real value is in the general theoretical advancement of sponge constructions.

I think your mis using "world use case". It's a hash function and so it is usable as a hash function. I'll repeat what was said elsewhere. SHA-2 of vulnerable to length extension attacks.

I said it's not a reasonable choice in the real world. Virtually anywhere you could use it, you would be better off be using a SHA-2 variant instead.

Length extension attacks only apply in cases where you've chosen to use the wrong cryptographic primitive (a hash) for your purpose (a MAC).

Re: Maybe Skip SHA-3

#113

Post by an27 »

baby wrote: post #109
koenigdavidmj wrote: post #104

Earlier quoted context omitted.

Which is ROT(ate), one of the listed options, even though you have to express it with shifts when writing C.

I'm not sure I understand what you two mean. 1) How does not having SHR makes it easier to audit? 2) how are sha-3 implementations actually using SHR not making the parent's comment moot?

GP disputed SHR is used in the snippet you highlighted.

Re: Maybe Skip SHA-3

#114

Post by remcob »

baby wrote: post #109
koenigdavidmj wrote: post #104

Earlier quoted context omitted.

Which is ROT(ate), one of the listed options, even though you have to express it with shifts when writing C.

I'm not sure I understand what you two mean. 1) How does not having SHR makes it easier to audit? 2) how are sha-3 implementations actually using SHR not making the parent's comment moot?

A rotate operation is invertible, a logic shift by itself is not.

Another fun one is x ^= x >> n with n some strictly positive constant, this is also invertible. It's used a lot in the murmurhash family of non-cryptograhic hash functions.

Re: Maybe Skip SHA-3

#115

Post by RcouF1uZ4gsC »

tptacek wrote: post #84
ktta wrote: post #79

My suggestion after looking around for the best hash function is SHA-256. Not SHA-512, not SHA-512/256. Not even SHA-224 because it offers no performance benefits. BLAKE2 is a good candidate right now considering speed. But SHA-256 instructions will only get more prevalent which will take care of the speed issue. There have been speed comparisons between SHA-256 and BLAKE2 without SHA instructions[1]. BLAKE2 seems li…

The advantage to 224 or 512/256 is that they don't expose the full register state of the hash at output and thus, like Blake2 and SHA-3, aren't vulnerable to length-extension attacks: you can (though it would be idiosyncratic to do so) use a simple prefix MAC with them, rather than HMAC.

With SHA 224, there is only 32 bits worth of information that are lost. Isn't a LEA "feasible" by generating the ~ 4 billion messages and finding the 1 that validates.

With 512/256 this is infeasible.

Is this a real concern with 224 in practice?

Re: Maybe Skip SHA-3

#116

Post by karaziox »

kobeya wrote: post #47
remcob wrote: post #45

> SHA-3 did introduce something useful: extendable output functions Much more than that! Keccak (SHA-3) introduced the Sponge construction. This goes _way_ further than extendable output functions: It allows you to build all the symmetric cryptographic primitives from one basic element! This means: hashes, PRNGs, MACs, encryption, AEAD, etc. The only thing you need that looks like crypto code is a single permutation…

Replying here because you said most of the things I was going to say. This article just makes me sad -- Keccak was chosen for SHA-3 specifically because it turned out SHA-2 wasn't as broken as we feared, and although slow Keccak brings to the table cryptographic diversity and the slew of cool things that can be done with a sponge construction that are now possible using standard cryptographic primitives. NIST made cl…

But NIST didn't make that clear. The thing they made clear is in fact the exact opposite and the OP mentions it. They called it SHA-3, saying to the world that this was a better SHA-2. If they wanted to make clear that SHA-3 wasn't to replace SHA-2, they should really have named it something else. Now everybody not knowledgeable to the details will sadly assume the 3 is better than the 2.

Re: Maybe Skip SHA-3

#117

Post by jasode »

dchest wrote: post #107
jasode wrote: post #78

Earlier quoted context omitted.

>blake2sp should be much faster than SHA256. blake2sp is indeed faster than Microsoft's builtin Crypto API for SHA256. However, it is not as fast as Wei Dai's Crypto++ library implementation of SHA256 that has lots of hand tuned assembly language code. The official C source code for blake2sp does not have assembly language primitives in it. It's very possible that if an assembly language expert wrote optimizations fo…

My pure JavaScript implementation of blake2s (which is approximately half the speed of parallelized sp variant) on 2.6 GHz Core i5 hashes at 170 MiB/s. JavaScript! Whatever you do with your benchmark, you're doing it wrong. Also, there is no reason to use such large buffer sizes, I suspect this only makes benchmarks more unreliable. For real numbers on many platforms, see https://bench.cr.yp.to/results-hash.html (war…

>My pure JavaScript implementation of blake2s (which is approximately half the speed of parallelized sp variant) on 2.6 GHz Core i5 hashes at 170 MiB/s.

If I recompile blake2sp with "/O2" optimization, it improves to 171MB/sec. I ran tests with "/Od" optimizations disabled because the default Crypto++ library project has optimizations disabled when it makes the lib file. Therefore, every hash had no optimizations to keep the comparisons apples to apples.

I see your Javascript code of BLAKE2 on github so I'll try it and compare. (https://github.com/dchest/blake2s-js)

>Also, there is no reason to use such large buffer sizes, I suspect this only makes benchmarks more unreliable.

I chose 500MB because I wanted the fastest hashes (CRC32, MD5) to take at least 1 second and many data sizes I want to hash will be 10GB+.

Re: Maybe Skip SHA-3

#118

Post by tptacek »

RcouF1uZ4gsC wrote: post #115
tptacek wrote: post #84

Earlier quoted context omitted.

The advantage to 224 or 512/256 is that they don't expose the full register state of the hash at output and thus, like Blake2 and SHA-3, aren't vulnerable to length-extension attacks: you can (though it would be idiosyncratic to do so) use a simple prefix MAC with them, rather than HMAC.

With SHA 224, there is only 32 bits worth of information that are lost. Isn't a LEA "feasible" by generating the ~ 4 billion messages and finding the 1 that validates. With 512/256 this is infeasible. Is this a real concern with 224 in practice?

224 is 512/224.

Re: Maybe Skip SHA-3

#119

Post by ktta »

tptacek wrote: post #118
RcouF1uZ4gsC wrote: post #115

Earlier quoted context omitted.

With SHA 224, there is only 32 bits worth of information that are lost. Isn't a LEA "feasible" by generating the ~ 4 billion messages and finding the 1 that validates. With 512/256 this is infeasible. Is this a real concern with 224 in practice?

224 is 512/224.

Wait, so I was talking about SHA-224 which is SHA-256 truncated to 224 bits, not SHA-512 truncated to 224 bits.

Nevertheless, does this mean SHA-224 is still susceptible to length extension attacks?

Re: Maybe Skip SHA-3

#120

Post by remcob »

tptacek wrote: post #56
snakeanus wrote: post #55

Earlier quoted context omitted.

> It allows you to build all the symmetric cryptographic primitives from one basic element! This means: hashes, PRNGs, MACs, encryption, AEAD, etc Isn't this true for most cryptographic hash functions? MAC with HMAC or H(key || m), encryption with a CTR-like mode on top of the MAC, etc.

Observe also that Chapoly, which is built on a stream cipher generated from a hash running in counter mode, written by basically one of the pioneers of ciphers-from-hash-constructions, does not use its hash core as its MAC; it's simply faster to use a polynomial MAC.

With a sponge construction the AEAD is a one-pass operation. You feed plaintext in, out comes ciphertext. In the end you crank it one more time and out comes the MAC/tag.

This is unlike other constructions, where you need to go over the data twice, with two different crypto algorithms (encryption + mac) that may or may not share a core component.

Post reply on HN