Maybe Skip SHA-3 • Hacker News Board

Re: Maybe Skip SHA-3

#181

Post by baby » Fri, Jun 02, 2017, 3:26 PM UTC

smarnach wrote: post #180

baby wrote: post #179

Earlier quoted context omitted.

> SHA-512/256 Sure, if you know what you're doing :) In the mean time I will keep recommending SHA-3. > the virtually 40 years we've had to understand Merkle-Damgård I think at this point we've understand that M-D sucks. > blabla I don't see why I would go on on a name dropping battle :) I'll sum up our battle here: some people are advocating SHA-3, some people are not. I'm in the first category. You're in the second…

As someone neutral about the subject, my summary of the discussion looks a bit different. stouset claimed that there is no practical advantage of using SHA-3 over SHA-512/256. He gave three main arguments: 1. SHA-3 is slower. 2. SHA-3 was subject to less cryptanalysis. 3. Virtually all respected cryptographers do not recommend SHA-3 over SHA-2. On the other hand, baby claimed that there are practical advantages of us…

This prompted me to post my thoughts here: https://cryptologie.net/article/400/maybe-you-shouldnt-skip-...

Re: Maybe Skip SHA-3

#182

Post by ktta » Fri, Jun 02, 2017, 9:04 PM UTC

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…

You might also want to test out BLAKE2bp, which is optimized for 64-bit platforms, while BLAKE2sp is for 32-bit platforms. So the numbers for BLAKE2 will be even higher

Re: Maybe Skip SHA-3

#183

Post by richdougherty » Sun, Jun 04, 2017, 9:34 PM UTC

tptacek wrote: post #82

baby wrote: post #76

Earlier quoted context omitted.

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

Yes: for instance, the TLS BEAST vulnerability, which affected all the block ciphers in that version of TLS, because the protocol standardized interchangeable ciphers and a message encryption construction based on CBC as separate components. Ironically, when the RC4 attack refinements were published, for awhile sites were forced to choose between a vulnerable CBC implementation and using the vulnerable RC4 cipher. Wi…

I don't mean that something like TLS should support every type of crypto under the sun. As you say, that means TLS is only as secure as it's weakest component.

What I mean is that if I make a new protocol, it could use a different type of crypto from what is in mainstream use, so at least this new protocol will fail independently from other protocols.

Re: Maybe Skip SHA-3

#184

Post by npscalar » Mon, Jun 05, 2017, 2:53 PM UTC

stouset wrote: post #177

baby wrote: post #169

Earlier quoted context omitted.

If your hash function behaves like a random oracle it should allow you to do h(key|data) hashing password requires more than a random oracle because of the input small entropy so your argument is moot. The fact that sha-3 has received less analyzis has already been debunked Here: https://twitter.com/aarontoponce/status/869973259969675264 . K12 has the advantage of the speed. See https://cryptologie.net/article/393/ka…

> hashing password requires more than a random oracle because of the input small entropy so your argument is moot. As I pointed out, SHA-512/256 allows you to safely do H(key|data). But your original argument was along the lines of "H(key|data) makes sense intuitively. You have to understand the details in order to realize it's unsafe. Therefore a hash that allows H(key|data) is better". This same line of reasoning,…

Even after 16 yrs, SHA-2 has actually not received so much cryptanalysis effort, the majorty of which comes from the same group, and the effort is further diluted into two different 32/64-bit designs [1]. Add to that the absence of openness from the SHA-2 designers themselves…

[1] http://eprint.iacr.org/2016/374.pdf

Re: Maybe Skip SHA-3

#185

Post by npscalar » Mon, Jun 05, 2017, 3:01 PM UTC

baby wrote: post #72

tptacek wrote: post #54

Earlier quoted context omitted.

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.

And all the SHA-3-derived functions in SP 800-185. For instance, ParallelHash is super fast and a NIST standard.

Re: Maybe Skip SHA-3

#186

Post by npscalar » Mon, Jun 05, 2017, 3:05 PM UTC

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…

This page has an interesting speed graph: http://kangarootwelve.org/

Re: Maybe Skip SHA-3

#187

Post by npscalar » Mon, Jun 05, 2017, 3:07 PM UTC

baby wrote: post #99

jasode wrote: post #70

Earlier quoted context omitted.

>I guess 32-bit x86 performance is maybe not the best benchmark. I compiled for 32bit instead of 64bit because I wanted the same executable to also run on a 32bit Macbook. When Thomas Pornin ran benchmarks[1] in 2010 for both 32bit & 64bit, the SHA256 hash performance didn't change as much as the SHA512. I'll recompile for 64bit and report back if there was a massive difference. [1] https://stackoverflow.com/question…

SHA-3 lanes are 64 bits. In 64 bits arch they can use full registers for operations. I'd bet it would be way faster on 64bit

Mismatches can show an interesting property. It is likely that SHA-256 is slower than Keccak on 64-bit platforms, and that SHA-512 is slower than Keccak on 32-bit platform.

Re: Maybe Skip SHA-3

#188

Post by jasode » Wed, Jun 07, 2017, 12:37 PM UTC

dchest wrote: post #173

jasode wrote: post #148

Earlier quoted context omitted.

I think I found the issue. In terms of absolute (not relative) MB/sec performance, the main culprit is the slow cpu speed of 1.2GHz single threaded performance instead of 3.3GHz. The other investigations into "/O2 /O3" optimizations or 8k outer loop were red herrings. However, for relative MB/sec performance comparison to SHA256, it seems to point back to the blake2 official reference code (non SSE) being very slow.…

The implementations measured are listed here: https://bench.cr.yp.to/impl-hash/blake2s.html Code mirror: https://github.com/floodyberry/supercop Yeah, of course reference implementation is a lot slower — it's for algorithm reference, so has readable code, which is slow. It can even be greatly improved by just unrolling loops and inlining message indexing by sigma constants, even without SSE (like my JavaScript implem…

>Yeah, of course reference implementation is a lot slower — it's for algorithm reference, so has readable code, which is slow.

Exactly! That's why my original post had the footnote that I using the slower blake2sp reference code. Same situation as the SHA-3 reference code being the slowest implementation.

>As for memory copying — I didn't mean memcpy(), what I meant is that your CPU would have to get chunks of your huge buffer from RAM, which is slower and has more unpredictable performance.

But this observation also applies to all the other hash performance tests. If the blake2sp hash is handicapped by computing large RAM buffers beyond the L1/L2/L3 caches, the MD5/SHA1/SHA256/etc are also handicapped the same way. Whatever "noise" exists in the tests can be evened out by multiple executions.

Restricting the tests to tiny memory sizes that fit in L1/L2/L3 is not realistic for my purposes.