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

161–170 of 171 posts

Re: Blake3 is 10 times faster than SHA-2

#161

Post by SAI_Peregrinus »

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…

The HKDF paper[1] has a good definition of a KDF:

    A Key derivation function (KDF) is a basic and essential component of cryptographic systems: Its goal is to take a source of initial keying material, usually containing some good amount of randomness, but not distributed uniformly or for which an attacker has some partial knowledge, and derive from it one or more cryptographically strong secret keys.
Not all KDFs are hash functions, or hash-function based. There are block-cipher based KDFs, stream-cipher based KDFs, etc.

Hash functions take arbitrary length input (well, up to some very large maximum size) and provide fixed-length output.

eXtensible Output Functions (XOFs)take arbitrary length input (up to some very large max) and provide arbitrary length output (up to some very large max).

Password Hashing Functions take (at least) three inputs: a unique salt, a secret password, and a tuning parameter (or set of parameters). They use the tuning parameter(s) to change the amount of work needed to compute their outputs. For any set of inputs they produce a deterministic output. The output may or may not be directly suitable for use as a cryptographic key, and may or may not be variable length.

Some password hashing functions are KDFs, taking effectively arbitrary input length and producing effectively arbitrary output length. PBKDF2 and Argon2 are KDFs.

Some password hashing functions are NOT KDFs, having limits on their input & output sizes. Bcrypt is not a KDF and not a hash function: it has a maximum 56-byte input (55 bytes if taking a null-terminated string, 72 bytes max in newer implementations) and a 60-byte output. It's suitable for logins where the password is hashed and compared to the stored hash, but not for directly deriving key material. And it's not necessarily suitable for non-ASCII passwords/passphrases, due to the short input.

[1] https://eprint.iacr.org/2010/264

Re: Blake3 is 10 times faster than SHA-2

#162

Post by SAI_Peregrinus »

rhn_mk1 wrote: post #157
lucb1e wrote: post #147

Earlier quoted context omitted.

I'm sorry, I hate it when others do that and don't notice when I do it myself apparently. It was really just meant to be read in the literal sense and not as that such a person is of less value or stupid. It can easily (and has) lead to security breaches if assumptions are made about this. I'm not saying you don't know the difference between md5 and crc32, but if anyone doesn't yet know that, then it's risky to make…

> Cryptographers commonly advise non-experts to use a library to do things for you On the high level, the problem is that libraries are usually "CRC32", "MD5", "SHA256", etc. There's no guiding resource that I have found that matches use cases to libraries, which is where the initial question comes from. That is, unless you meant a library that covers the entire use case, but there isn't always one.

That's part of why NaCl, Libsodium, and Libhydrogen have the APIs they do: they cover secure ways to use the primitives, make those ways easy, and make it harder to misuse things. It's also why so many security professionals like the "noise" protocol: it doesn't leave any of the difficult choices open to be misused.

Re: Blake3 is 10 times faster than SHA-2

#163

Post by throwawaymath »

SAI_Peregrinus wrote: post #161
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…

The HKDF paper[1] has a good definition of a KDF: A Key derivation function (KDF) is a basic and essential component of cryptographic systems: Its goal is to take a source of initial keying material, usually containing some good amount of randomness, but not distributed uniformly or for which an attacker has some partial knowledge, and derive from it one or more cryptographically strong secret keys. Not all KDFs are…

This is a great comment, but I just want to point out:

> Bcrypt is not a KDF and not a hash function

This is true, but it's also a good example of what I was saying in my other comment. bcrypt is an example of a password hashing function which is not itself a KDF, but which can be used to construct a KDF.

All password hashing functions can be used to construct key derivation functions or simply are key derivation functions. But not all password hashing functions are key derivation functions. Whether or not it would be advisable to use a given password hashing function as a KDF depends, of course. In bcrypt's case you can construct a reasonable KDF. For example: https://github.com/pyca/bcrypt/blob/master/README.rst

Re: Blake3 is 10 times faster than SHA-2

#164

Post by tgb »

pnako wrote: post #133
nneonneo wrote: post #128

Earlier quoted context omitted.

I don’t see how that follows. If HSrv is expensive or slow, a malicious client could just submit nonsense hashes that only look like they might have come from HCli - the server shouldn’t be able to tell the difference. Requiring client-side JavaScript for your login system seems fraught. I would much rather have an approach that does server side hashing exclusively, but gates it behind some kind of DDoS protection or…

You do the slow (bcrypt, argon2 or whatever) hash in the browser, and then the server can do the hyper-fast hash (SHA256). You can still flood the server, but you're flooding it with things that take microseconds to compute, instead of 50ms.

That's not what the article states, though it's not very explicit about why you shouldn't do what you suggest.

Re: Blake3 is 10 times faster than SHA-2

#166

Post by PabloGranolabar »

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…

This is not good advice at all. Reducing rounds to increase performance is going to significantly weaken the cipher if obfuscation is the key. And new attack vectors, especially with the advent of cheap cloud storage (rainbow tables), advances in GPU performance, and quantum computing are all necessary factors to consider. I wouldn't use Blake3 for anything after reading the above.

Re: Blake3 is 10 times faster than SHA-2

#167

Post by PabloGranolabar »

Reducing 10 rounds in Blake2 to 7 in Blake3.. huh?

The entire industry is going in exactly the opposite direction of this, to increase the complexity and depth of the attack surface of cryptographic methods and algorithms due to advances in quantum computing. Cloudflare, Microsoft Research etc are all investing heavily into post-quantum cryptography technologies, almost exactly the opposite of what this guy is promoting. Makes no sense. ‾\_(ツ)_/‾

Re: Blake3 is 10 times faster than SHA-2

#168

Post by mekster »

nneonneo wrote: post #71

A lot of people in the comments are wondering about using SHA-2 vs Blake3 for password hashing. The answer is, neither of these is suitable by itself for password hashing. Sadly there’s still a lot of advice on the internet (and, sadly, real systems) which do things like store md5(password) in a database and call it a day. Blake2/3, SHA-2/3, and other cryptographic hash functions are meant to be fast , while also eff…

Argon2 is a recent entry which won the password hashing competition in 2015 and is slowly getting included in recent versions of languages like PHP 7.2 as an alternative to bcrypt.

https://password-hashing.net/

As stated in the parent, integrity check hashing (should be fast) and password hashing (should be slow) are very different things and should not be mixed to use wrong implementations.

As bcrypt and argon2 both have specific prefixes, you can still keep bcrypt hashes and verifier can work on both (assuming it supports argon2) while using argon2 for newer entries stored in a database. (Preferably update the old bcrypt into argon2 on next login or something.)

Re: Blake3 is 10 times faster than SHA-2

#169

Post by garmaine »

SlowRobotAhead wrote: post #160
garmaine wrote: post #145

Earlier quoted context omitted.

He's talking about 12 to 16 byte outputs though, which is 96-128 bits of preimage resistance, and only 48-64 bits of collision resistance.. which would be very broken today.

Mostly. There are 12-16 byte hash or hash-like results are plenty secure. They’re keyed though. The output from HMAC and AEAD ciphers with no encryption (think the additional data portion of ChaCha20-Poly1305 in a Nonce-MAC mode)... or maybe I’m wrong because these require nonces and keys.

Whether you are using it in a keyed authentication mode is orthogonal to collision resistance.

Re: Blake3 is 10 times faster than SHA-2

#170

Post by rurban »

kzrdude wrote: post #87
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?

I never said that Siphash is broken, read what I said. It's not broken, it's just theatre,and way too slow to be useful for anything. And it doesn't protect against hash table attacks. Proper protections need to be done at the collision handling step, not in the hash function.

http://perl11.org/blog/seed.html https://news.ycombinator.com/item?id=13361860

Post reply on HN