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

81–90 of 171 posts

Re: Blake3 is 10 times faster than SHA-2

#81

Post by lucb1e »

throwawaymath wrote: post #44
amlozano wrote: post #41

Earlier quoted context omitted.

We often use 'hash' as a sort-hand way of saying 'Key Derivation Function' when talking about secrets like passwords. https://en.wikipedia.org/wiki/Key_derivation_function These functions usually use hashes as a primitive, but there is more to them than that. Using a plain hash to store passwords is usually a red flag that the storage is insecure. I see it when doing source code audits: some legacy software using md5…

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 resource (short of a whole book on low level crypto details)?

Re: Blake3 is 10 times faster than SHA-2

#82

Post by ganzuul »

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?

I don't know a reason for why they are acceptable. AES256 is considered quantum-proof, but there exists another theoretical quantum computer design which seems to raise the bar again. I don't know if there exists a theoretical limit for how powerful quantum computers can get.

Re: Blake3 is 10 times faster than SHA-2

#83

Post by yarg »

nneonneo wrote: post #67
yarg wrote: post #54

Earlier quoted context omitted.

In any situation where a hashcode is cacheable (which seems to me to cover all situations where a hashcode even makes sense) a cryptographic hash function might not be such a bad idea (especially if you're IO bound in any way). With a bad hash function you can end up with a high level of bucket utilisation, significantly reducing the efficiency of the structure. With user defined data there's even the possibility of…

Cryptographic hash functions can be orders of magnitude slower than functions tuned for hashtables and dictionaries. If you’re using them as hash table indexes, then you have to take the big cryptographically secure number and mod it by a small bucket count - and then you’re going to have collisions. If you don’t salt, then an attacker is going to predict the bucket indexes no matter how strong your hash function is,…

Thanks.

Re: Blake3 is 10 times faster than SHA-2

#84

Post by espadrine »

antpls wrote: post #61
rurban wrote: post #7

Not really. It's even 2x slower than SHA256-NI, the builtin. b3sum is much faster than sha256sum, and blake3 is about 2x faster than blake2. http://rurban.github.io/smhasher/doc/table.html

Not sure why you are downvoted. Your table looks more factual than the blake3's github.

RE: the downvotes; while I didn't partake, I know there is history between the BLAKE/BLAKE2/BLAKE3 author, JP Aumasson, and Rurban, in particular related to differing opinions over the publication of SipHash.

Differing opinions here means that most of the cryptographic community agree that SipHash clears its claims as a PRF, while Rurban indicated he has found undisclosed vulnerabilities that he wishes not to publish.

RE: the table; a point to note is that BLAKE3's main implementation, in Rust, benefits a lot from multithreading on large files, which SHA2 cannot. The C version, which Rurban copied, does not leverage multithreading: https://github.com/BLAKE3-team/BLAKE3/blob/master/c/README.m...

Re: Blake3 is 10 times faster than SHA-2

#85

Post by lucb1e »

espadrine wrote: post #62
lucb1e wrote: post #49

Earlier quoted context omitted.

Compared to? MD2, MD4, MD5, SHA-1, etc.: There are collisions known, so yes. SHA-2, SHA-3, BLAKE2b, Skein, Whirlpool, etc.: We don't have any collisions for these, so it doesn't get any better than that.

> SHA-2, SHA-3, BLAKE2b, Skein, Whirlpool, etc.: We don't have any collisions for these, so it doesn't get any better than that. There are important differences; some of those primitives are definitely more trustworthy than others. SHA-2 and Whirlpool use the old Merkle–Damgård construction, which has fallen out of favor because of unfortunate properties. They are vulnerable to length extension attacks, such that it…

That was informative, thanks! It matched my gut feeling about the algorithms and I knew some of these things, but not everything :)

> a safe bet is still SHA-512/256, which is safe against length extension attacks.

I would like to add here that this does not mean "SHA-512 or SHA-256" (I remembered that SHA-256 was not length-extension resistant and looked up the details). Instead, it means the version of SHA-512 that gets truncated to 256 bits. This is apparently relatively new (or at least added after I last read up on SHA-2):

> In March 2012, the standard was updated in FIPS PUB 180-4, adding the hash functions SHA-512/224 and SHA-512/256, and describing a method for generating initial values for truncated versions of SHA-512.

-- https://en.wikipedia.org/wiki/SHA-2#Hash_standard

I feel like that notation could have been chosen better by NIST.

Re: Blake3 is 10 times faster than SHA-2

#86

Post by amlozano »

throwawaymath wrote: post #44
amlozano wrote: post #41

Earlier quoted context omitted.

We often use 'hash' as a sort-hand way of saying 'Key Derivation Function' when talking about secrets like passwords. https://en.wikipedia.org/wiki/Key_derivation_function These functions usually use hashes as a primitive, but there is more to them than that. Using a plain hash to store passwords is usually a red flag that the storage is insecure. I see it when doing source code audits: some legacy software using md5…

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

You are right. I still think we should call "Password Hashing Algorithms". "One-way password storage" maybe. Or something. Just get rid of the word hashing.

Edit: NIST uses "one-way key derivation function" in their requirements, which I like, but that perhaps unfairly excludes other potential functions.

Re: Blake3 is 10 times faster than SHA-2

#87

Post by kzrdude »

rurban wrote: post #7

Not really. It's even 2x slower than SHA256-NI, the builtin. b3sum is much faster than sha256sum, and blake3 is about 2x faster than blake2. http://rurban.github.io/smhasher/doc/table.html

> I.e. the usage of SipHash for their hash table in Python 3.4, ruby, rust, systemd, OpenDNS, Haskell and OpenBSD is pure security theatre.

This seems like a noteworthy claim, and the hflounge link is unfortunately broken!

Is it possible to you to provide more information about this, that Siphash would be essentially broken?

Re: Blake3 is 10 times faster than SHA-2

#88

Post by dgacmu »

yarg wrote: post #55
yarg wrote: post #54

Earlier quoted context omitted.

In any situation where a hashcode is cacheable (which seems to me to cover all situations where a hashcode even makes sense) a cryptographic hash function might not be such a bad idea (especially if you're IO bound in any way). With a bad hash function you can end up with a high level of bucket utilisation, significantly reducing the efficiency of the structure. With user defined data there's even the possibility of…

Actually, a counter-point: there might be situations where you want an anti-cryptographic hash function - where similar inputs produce generally similar hashes. It could have some application as a preprocessing step in clustering (if it could be done efficiently).

The term for this is locality sensitive hashing, and it's very useful in some contexts.

Re: Blake3 is 10 times faster than SHA-2

#89

Post by [deleted] »

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.

[deleted]

Re: Blake3 is 10 times faster than SHA-2

#90

Post by amlozano »

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…

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 derivation function. Key derivation functions take a password, a salt, and a cost factor as inputs then generate a password hash.

They are specific about the type of KDF required: "one-way key derivation function".

The examples given later are PBKDF2 and Balloon.

Post reply on HN