💾 Archived View for 9til.de › lobsters › daw1oa.gmi captured on 2023-11-14 at 07:47:08. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
.----------------. | .--------------. | | | _____ | | | | |_ _| | | | | | | | | | | | | _ | | | | _| |__/ | | | | | |________| | | | | | | | '--------------' | '----------------'
Viewing comments for "Reasons to prefer blake3 over sha256"
---
LeahNeukirchen commented [12]:
Note that a large part of the speed up results from the
ability to operate in parallel (which doesn't work on
streaming data), however, even single-threaded it is fast:
% dd if=/dev/urandom of=/tmp/rand bs=1M count=1024
% hyperfine 'b3sum < /tmp/rand'
Benchmark 1: b3sum < /tmp/rand
Time (mean +- s): 617.3 ms +- 44.6 ms [User: 453.3
ms, System: 161.1 ms]
Range (min .. max): 553.2 ms .. 698.5 ms 10 runs
% hyperfine 'b3sum /tmp/rand'
Benchmark 1: b3sum /tmp/rand
Time (mean +- s): 228.1 ms +- 18.2 ms [User: 955.8
ms, System: 190.9 ms]
Range (min .. max): 204.1 ms .. 263.1 ms 13 runs
% hyperfine 'sha256sum /tmp/rand'
Benchmark 1: sha256sum /tmp/rand
Time (mean +- s): 7.498 s +- 0.205 s [User: 7.282
s, System: 0.178 s]
Range (min .. max): 7.220 s .. 7.789 s 10 runs
And, for fairness:
Benchmark 1: openssl sha3-256 /tmp/rand
Time (mean +- s): 5.160 s +- 0.266 s [User: 4.900
s, System: 0.233 s]
Range (min .. max): 4.712 s .. 5.598 s 10 runs
> oconnor663 commented [3]:
Yes on modern chips, "SIMD" parallelism is just as big of
a deal as multithreading. (For various reasons library code
can generally use SIMD optimizations without asking the
caller's permission, but spawning threads without permission
is less ok, so SIMD optimizations end up getting much wider
deployment.) Desktop chips routinely have 8x SIMD support,
and some have 16x. You leave most of that on the table if
the block diagram of your algorithm is serial.
That said, 7 seconds to hash 1 GB is a really slow
implementation of SHA-256. I'd expect OpenSSL to do
it on any desktop machine in 1-3 seconds, depending on
whether you have hardware acceleration. I've run this same
benchmark ..too many times :)
> wizeman commented [2]:
That said, 7 seconds to hash 1 GB is a really slow
implementation of SHA-256.
AFAIK sha256sum doesn't use hardware acceleration. OpenSSL
does, but note that @LeahNeukirchen didn't benchmark
OpenSSL's SHA-256 (i.e. SHA-2) implementation, but rather
SHA3-256 (i.e. SHA-3), which AFAIK (most?) CPUs don't have
dedicated instructions for.
> jmillikin commented [3]:
As other comments noted, you wanted to benchmark openssl
sha256, not openssl sha3-256, which is Keccak.
$ hyperfine 'b3sum /tmp/rand'
Benchmark 1: b3sum /tmp/rand
Time (mean +- s): 34.0 ms +- 0.4 ms [User: 183.3
ms, System: 62.7 ms]
Range (min .. max): 33.4 ms .. 35.1 ms 83 runs
$ hyperfine 'openssl sha256 /tmp/rand'
Benchmark 1: openssl sha256 /tmp/rand
Time (mean +- s): 270.0 ms +- 2.4 ms [User: 210.8
ms, System: 59.2 ms]
Range (min .. max): 266.3 ms .. 274.2 ms 11 runs
$ hyperfine 'openssl sha3-256 /tmp/rand'
Benchmark 1: openssl sha3-256 /tmp/rand
Time (mean +- s): 900.5 ms +- 16.0 ms [User: 832.0
ms, System: 67.9 ms]
Range (min .. max): 880.3 ms .. 929.0 ms 10 runs
$ hyperfine 'sha256sum /tmp/rand'
Benchmark 1: sha256sum /tmp/rand
Time (mean +- s): 1.355 s +- 0.008 s [User: 1.297
s, System: 0.058 s]
Range (min .. max): 1.343 s .. 1.366 s 10 runs
raphting commented [10]:
Speaking about Go, I would always prefer to use what's in
the standard packages over pulling 3rd party packages to
do my crypto. As long as blake3 is not part of the standard
packages, sha256 is the better choice imo.
> jstoja commented [5]:
Also, good luck explaining to auditors that blake3 is much
better. I use sha256, they nod, move on.
river commented [7]:
It's a shame to see sha3 being the absolute worst at
perfomance. I really liked the sponge design. I hope that
the bad performance isn't going to put people off of using
it.
> 0x2ba22e11 commented [4]:
At the time I think it was justifiable. SHA1 had broken,
SHA2 looked like it might break any day, so they made
"dissimilarity to SHA1+2" an explicit design goal for SHA3.
> lonjil commented [6]:
Though the sponge construction isn't the most efficient in
software, I think the slowness of SHA3 has a lot more to
so with the stupid high security requirements NIST imposed
(the perf delta between SHA3 and Blake1 were a lot smaller
than SHA3 and Blake3) than the sponge construction. If the
requirements had been reasonable, Keccak probably still
would've won due to dissimilarity to Sha2, but would've been
a lot more attractive.
Hm, I should go look up how proper modern SIMD
implementations of Kangaroo12 compare to Blake3.
> 0x2ba22e11 commented [2]:
Oh interesting, thanks!
> ssl commented [4]:
And BLAKE3's precursor was submitted into the competition,
but Keccak won instead.
> oconnor663 commented [2]:
I'm very biased, but I think most of the advantages of
the sponge construction go away when you try to allow
for parallelism, which (again biased) seems like table
stakes for new designs. The tree structures of BLAKE3 and
KangarooTwelve aren't really "spongy": they don't interleave
output with input, and they don't really care whether
you process the nodes with a compression function or a
permutation or whatever. Also on the output side, you really
want something that looks like a counter-based stream,
i.e. like ChaCha or AES-CTR, so again you end up setting
"spongy" features aside even if you implement that with a
block permutation.
phoebos commented [5]:
We've been using blake3 in KISS Linux for more than a year,
because of the speed increase.
> zk commented [3]:
For what purpose? Package integrity verification?
> phoebos commented [1]:
Not for packages but for sources (KISS is source-based)
hauleth commented [4]:
I do not disagree with the premise, but the article does
hardly any job there except saying "they are old, weak
and slow while we are new, secure and fast" with a single
sentence from something that most non crypto related people
probably not even heard of and single bar graph. IMHO not
the best article.
> gerikson commented [3]:
It is composed to tweets, so ..
river commented [2]:
I think that you could create a table of pros and cons
to compare blake3 and sha256 to get a better overview and
understanding of how they compare.
Both are fine, really. the really popular ones that are
still used are md5 and sha1.
---
Served by Pollux Gemini Server.