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

71–80 of 188 posts

Re: Maybe Skip SHA-3

#71

Post by tptacek »

remcob wrote: post #62
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.

True, the symmetric primitives are sort of interchangeable, but I'd like to see how to build an AEAD using hash functions that doesn't require you process the data twice. I don't think it can be easily done, if at all. It certainly won't do to combine a HMAC with a CTR-mode encryption. Keccak allows for very simple and efficient implementations of all these primitives. > H(key ‖ m) This is insecure for SHA2 (length e…

Why can't you just use a prefix MAC with SHA-2 512/224?

Re: Maybe Skip SHA-3

#72

Post by baby »

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

None of these are good reasons to build SHA-3 into a design today, which is the point of the post. He's not criticizing SHA-3's design; pretty much everyone thinks it's interesting and valuable. The point is that the resulting standard doesn't have a lot of immediate practical benefit for real systems.

I don't think that's true. TuppleHash is THE solution for fingerprints. SHAKE is useful for really a lot of different purposes. Imo self made protocols could really benefit from STROBE today as well.

Re: Maybe Skip SHA-3

#73

Post by baby »

snakeanus wrote: post #55
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…

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

I think a block cipher allows you to build a lot. Cmac for mac, a block cipher is at the center of sha1/2, aes-ctr for prngs, ... But it's rather that it's used as the center piece of some algorithm whereas doing anything with keccak is just natural.

Re: Maybe Skip SHA-3

#74

Post by dchest »

jasode wrote: post #58
JoshTriplett wrote: post #2

SHA-3 does seem to have relatively little to offer by way of incentives to switch. "Just as good" isn't motivation, and any notions of higher cryptographic strength haven't been extensively discussed. "Easier to implement in hardware" will be more compelling when such hardware exists. I'm curious about the statement that SHA-3 is slow; it links to https://www.imperialviolet.org/2016/05/16/agility.html , which doesn't…

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

Hmm, something is wrong with your benchmark: the absolute values in MB/s are very low for i7, and relative too — blake2sp should be much faster than SHA256.

Re: Maybe Skip SHA-3

#75

Post by snakeanus »

jasode wrote: post #58
JoshTriplett wrote: post #2

SHA-3 does seem to have relatively little to offer by way of incentives to switch. "Just as good" isn't motivation, and any notions of higher cryptographic strength haven't been extensively discussed. "Easier to implement in hardware" will be more compelling when such hardware exists. I'm curious about the statement that SHA-3 is slow; it links to https://www.imperialviolet.org/2016/05/16/agility.html , which doesn't…

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

I am quite surprised that CRC32 is slower than MD5.

> I think the specific variant of BLAKE that directly competed with Keccack is slower

BLAKE is slower than BLAKE2 indeed. BLAKE also has more rounds than BLAKE2.

Re: Maybe Skip SHA-3

#76

Post by baby »

tptacek wrote: post #53
richdougherty wrote: post #50

> As I've mentioned before, diversity of cryptographic primitives is expensive. ... exponential number of combinations ... limited developer resources ... It's a good point that diversity is expensive. There's a counter-argument too: if we all decide to use one thing, but it goes wrong - then we're in serious trouble. If we have multiple approaches, then the damage is lessened if one of them turns out to have problem…

The track record on that design strategy is not good. We've been pursuing designs with cryptographic diversity built in for several decades, and the result has been decades of terrible vulnerabilities --- almost none of which have been mitigated by diversity!

Have we had some big crypto failures besides "everyone was using md5" and "everyone was using DES"?

Re: Maybe Skip SHA-3

#77

Post by remcob »

agl wrote: post #60
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…

If I may (hopefully accurately) summarise your argument: the sponge construction means that we could just implement a single permutation in hardware / optimised software and build everything from it, thus saving die area / code size, and complexity. But deciding to skip SHA-3 doesn't preclude any of that. SHA-3 is the hash standard itself, and even the Keccak team appear to be pushing K12 rather than SHA-3. It seems…

Yes, I'm much more rooting for the Sponge construction than Keccak/SHA3 specifically. I'd like to see any permutation function get broad hardware support.

> I think there's wide agreement that SHA-3 is too conservative.

As you probably know, SHA3 originally had 18 rounds, but this was raised to 24 during the competition. This of course hurt performance. In some early proposals for a stream cipher, the authors reduced the rounds to 12 to get better performance.

Re: Maybe Skip SHA-3

#78

Post by jasode »

dchest wrote: post #74
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…

Hmm, something is wrong with your benchmark: the absolute values in MB/s are very low for i7, and relative too — blake2sp should be much faster than SHA256.

>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 for blake2sp, it would beat Crypto++ SHA256 performance.

The code I used is really simple. Used files "blake2sp-ref.c" and "blake2s-ref.c" from the BLAKE website. The hash code (no loops) is:

  blake2sp_state S[1];    // BLAKE 1 element array of the struct for state
  blake2sp_init(S, BLAKE2S_OUTBYTES);
  blake2sp_update(S, BufInput, iBuffersize);
  blake2sp_final(S, hashval_blake2sp_bytes, BLAKE2S_OUTBYTES);
... where iBuffersize is 500MB but I got the same results at larger buffer sizes 1GB+.

With that code, I'm guessing anyone can whip up a C++ project to benchmark blake2sp in 10 minutes. It would be interseting to see what MB/sec that others achieve.

Re: Maybe Skip SHA-3

#79

Post by ktta »

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 like good option then, with the optimized code.

But once SHA extensions use hardware instructions, it gets a 5.7x boost which blows BLAKE2 out of the water.[2] There are instructions for SHA-256 in NEON too although I couldn't find any benchmarks. I'd say it'll definitely be faster than BLAKE2 with HW instructions.

Combine that with SHA256 being uber popular everywhere, that'll be one less headache.

I also doubt SHA-256 will be over thrown in the near future, atleast until SHA-3 instructions become commonplace, which I anticipate will take about a decade from now.

[1]: https://news.ycombinator.com/item?id=14357197

[2]: https://github.com/randombit/botan/issues/807#issuecomment-2...

EDIT: Looks like SHA-224 might be the best option, considering it has the same core with a truncated output which will make it immune to length-extension attacks.

Re: Maybe Skip SHA-3

#80

Post by hdhzy »

oconnor663 wrote: post #46
hdhzy wrote: post #44

Earlier quoted context omitted.

I wonder why is that, I had a shared plan (3 numbers) that gave about 99 GB each month and Apple wouldn't let me download a 100 MB game through LTE?

Part of the rule might be an incentive for developers to keep size under control.

I wonder if that rather incentivises them to download assets as a separate HTTP request after the app is started. If not how do AAA games work on the iPhone?
Post reply on HN