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

Blake3 is 10 times faster than SHA-2

nextjournal.com

Post reply on HN
Print view View original

91–100 of 171 posts

Re: Blake3 is 10 times faster than SHA-2

#91

Post by s_tec »

tylersmith wrote: post #73
ganzuul wrote: post #69

Earlier quoted context omitted.

Agreed. We are not just securing for today, we are securing for perhaps decades into the future. If we don't know for sure what the threat is, then the right measure of paranoia is as much as we can afford. We are not just securing ourselves, but our social network too. Something you do can be used to discredit your kids and grand-kids a long time from now.

Why not increase the rounds then? What makes the current security margins acceptable but not smaller margins?

The basic intuition behind symmetric cryptography is that once your input bits are "thoroughly mixed", there's no way to un-mix them besides brute-force.

On the other hand, we don't have a solid theory of computational complexity yet. Even basic questions like P = NP are still unanswered, so we have no idea what "thoroughly mixed" actually means, how to measure it, how to achieve it, or even if it exists.

Whatever it is, a single round of BLAKE certainly isn't "thoroughly mixed". Is 10 rounds enough? Nobody knows. On the other hand, we suspect that a thousand rounds are no better than a hundred - there's probably a plateau of "maximum entropy", and once you get there, extra mixing doesn't help.

So, since we don't actually know what we are doing, we pick a safety margin, like 1.4x or 2x, and just use that. It's all just guesswork until the theoretical side catches up, so your opinion is as good as mine. On the other hand, picking a safety margin of 1 seems rash. If you have practical attacks in the round before, you probably aren't anywhere near the plateau of maximum entropy!

Re: Blake3 is 10 times faster than SHA-2

#92

Post by throwawaymath »

lucb1e wrote: post #81
throwawaymath wrote: post #44

Earlier quoted context omitted.

Unfortunately, not all password hashing algorithms are key derivation functions. That's just a common design and closely related.

I've never really understood the difference between a KDF, hashing function, password hashing function, though it's relevant to know when writing reports (I work for a security company). We recommend Argon2/scrypt/bcrypt for password storage of course, but we call them KDFs and I'm not sure if it's correct. From my understanding, a KDF can be fast, but a PBKDF must be slow. Could you elaborate or do you know a good r…

I don't know of a good source beyond textbooks or papers which focus precisely on the low level crypto details you (rightly) want to avoid. There just isn't much of a need for that kind of nuance most of the time. I also (gently) reject the premise; as far as practical security is concerned, if your team is recommending Argon2/scrypt/bcrypt to developers then that's far more important than being able to explain the difference between key derivation and keyless password hashing.

It's essentially like rectangles versus squares. You can create a key derivation function out of anything which passes all the criteria of a password hashing function. But it won't be a particularly performant or useful key derivation function. Likewise you can create a password hashing algorithm out of a dedicated key derivation function, but that's insufficient on its own.

There's no need to get bogged down in the details, just continue recommending a reputable implementation of these algorithms. On the other hand, if you'd like to learn more out of intellectual curiosity, Boneh & Shoup's textbook is good (work in progress) [1]. Galbraith's textbook includes chapters which cover the topic to a depth that's beyond what you're looking for, but you'll learn whatever it is you want to know [2].

Finally, more accessible, informal answers that get the basic idea across are [3], [4].

1. https://toc.cryptobook.us/

2. https://www.math.auckland.ac.nz/~sgal018/crypto-book/main.pd...

3. https://security.stackexchange.com/questions/95410/what-is-t...

4. https://crypto.stackexchange.com/questions/70716/key-derivat...

Re: Blake3 is 10 times faster than SHA-2

#93

Post by lucb1e »

amlozano wrote: post #90
lucb1e wrote: post #81

Earlier quoted context omitted.

I've never really understood the difference between a KDF, hashing function, password hashing function, though it's relevant to know when writing reports (I work for a security company). We recommend Argon2/scrypt/bcrypt for password storage of course, but we call them KDFs and I'm not sure if it's correct. From my understanding, a KDF can be fast, but a PBKDF must be slow. Could you elaborate or do you know a good r…

When talking about passwords specifically in our reports (I work at a security company too), I tell our team to use the same language as NIST 800-63B, since its the best "standard" for passwords and authentication I can find. The relevant bit here is this: Verifiers SHALL store memorized secrets in a form that is resistant to offline attacks. Memorized secrets SHALL be salted and hashed using a suitable one-way key d…

That's one of the reference documents we also use. Somehow I still feel like KDF (or "one-way KDF") describes a broader set of algorithms than we truly mean, but you make a good point that if some official body writes it this way, the terminology is probably at least correct enough.

Re: Blake3 is 10 times faster than SHA-2

#94

Post by kragen »

tgb wrote: post #79
kragen wrote: post #76

Earlier quoted context omitted.

Also you can do the stretching in the browser client (“server relief”) without losing security. Historically this would have meant a big performance penalty (and thus an advantage for attackers, who don't need to use your code) but JS and wasm are fast enough now that the price is fairly low.

Can you elaborate? This doesn't sound right to me but I don't know much about this.

It is indeed surprising; it took me a long time to be sure it was safe. Google “server relief”.

Re: Blake3 is 10 times faster than SHA-2

#95

Post by oconnor663 »

lucb1e wrote: post #51
doomrobo wrote: post #45

Earlier quoted context omitted.

It was announced in a lightning talk following that session

That doesn't sound very official. Most text in the paper seems to date from August, so it looks like this has been out for a while and was not only just announced, even if it was mentioned or officially "announced" (while being already released) in a surprise talk at that conference.

JPA and I announced BLAKE3 at the RWC lightning talks, after JPA's Too Much Crypto talk, and we published all the repos and crates.io packages about 30 minutes prior to that. The commit history that you see in the repos was private until January 9.

Re: Blake3 is 10 times faster than SHA-2

#96

Post by diegocg »

dathinab wrote: post #64
baby wrote: post #58

JP Aumasson just announced Blake3 at Real World Crypto a few days ago during the lightning talks. This was also right after he presented on "Too Much Crypto"[1] which argues that we use too many rounds in symmetric constructions: our security margins are too high and don't match any of the best "practical" attacks. We're too paranoid for our own good. He suggests reducing the number of rounds for a number of construc…

> which argues that we use too many rounds in symmetric constructions: our security margins are too high and don't match any of the best "practical" attacks. We're too paranoid for our own good. He suggests reducing the number of rounds for a number of constructions like AES, SHA-3, Blake2, etc. This seems a quite dangerous way of thinking. New attacks, methods to attack crypto are discovered regularly. A view years…

I don't know what his arguments are, and I don't have much of a clue about crypto, but perhaps his argument could go along the lines of "a secure algorithm shouldn't be secured just by increasing the number of rounds too much"?

Re: Blake3 is 10 times faster than SHA-2

#97

Post by phiresky »

dpc_pw wrote: post #78
littlestymaar wrote: post #77

Earlier quoted context omitted.

This is a good time to ask for a question I have always wondered about these slow hash functions: are they slow because they are computationally intensive or is it that they have other tricks that makes them slow without costing too much load on your server (like needing RAM access, syscalls or anything that add latency but not much CPU load). If it's the former, isn't it a good DOS target, making your server busy ha…

They are computationally slow, no tricks. The purpose is to prevent attackers from calculating the plain passwords if they actually got access to the content of your DB. They are not that slow (let's say less than a second to calculate) - fast enough for your user to not notice , slow enough so that attacker can't do gazillion tries per second with their GPU or something. As per DOS: rate limit per ip and account, an…

> They are computationally slow, no tricks

They have to and do use tricks, they aren't just slow. You could trivially make sha256 slow by just applying it a million times (that's not even parallelizable as well), but scrypt et al improve on that by making the algorithm also require a lot of RAM, use complex instructions (hard to recreate on a GPU or FPGA) and so on.

It's really hard to do very well, look at cryptocurrencies trying to be ASIC resistant: They want every normal person to be able to mine it, and don't want companies to be able to build a machine that can eclipse the mining power of everyone which means centralization.

Re: Blake3 is 10 times faster than SHA-2

#98

Post by oconnor663 »

thephyber wrote: post #27
mintyc wrote: post #10

Do the runtime tests decouple from I/O times e.g. file and memory caching aren't affecting the results? Surprised because I'd expect a big file like that to be I/o bound in practice

There is a tech talk about Bao (I think it’s the same author) where he prefaced the talk by describing a few caveats like “benchmarks are lies” and he mentioned that you should always run a timed process a second time to tease out bias from cached/pages instructions and data. The core reason this method is faster than traditional SHAs is because Blake3 is a binary tree where the leaf blocks can be hashed in parallel…

To be clear, "benchmarks are nothing but lies" is an exaggeration to get my point across. (And a good way to get a laugh at the start of a talk.) But take a look at Figure 3 from the Performance section of the BLAKE3 spec: https://i.imgur.com/smGHAKA.png. Even ignoring things like caching and compiler settings and different hardware, that's a complicated graph! The lines cross all over each other. I count 5 different functions in that graph that are, for at least some input, the "fastest hash function". (I think BLAKE2sp just baaarely passes below BLAKE2bp, just prior to 8 KiB.) It's hard to give a simple summary of a complicated picture. For the big red bar chart at the top of the BLAKE3 repo, we certainly cherry-picked a point where BLAKE3 looks good. But you could also cherry-pick points where it looks bad.

Re: Blake3 is 10 times faster than SHA-2

#99

Post by oconnor663 »

wolf550e wrote: post #72

I would like to see the performance of KanagarooTwelve in the same tree structure as BLAKE3, with AVX-512, on the same hardware (AWS c5.metal).

Take a look at Figure 3 in the Performance section of the BLAKE3 spec: https://i.imgur.com/smGHAKA.png. That graph doesn't account for differences in the tree structure, but it compares the performance of both with AVX-512.

Re: Blake3 is 10 times faster than SHA-2

#100

Post by [deleted] »

jupp0r wrote: post #46

This benchmark is not a comparison between BLAKE3 and SHA-2, it’s a comparison between b3sum and sha2sum. Things like file access pattern, hiding io latency, distributing work to cores, etc can make huge differences that have nothing to do with the hash functions themselves.

[deleted]
Post reply on HN