141–150 of 171 posts
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.
Earlier quoted context omitted.
Never use MD5 except for compatibility.
This. There are hash functions that are faster than MD5, so it's not the fastest, and everyone knows (since 1996, actually[1]) that MD5 is insecure. If you want transmission error checking, use CRC32 or Siphash or whatever. If you want an actual, cryptographic hash function, then BLAKE3 is one of the options, though it's a very young one so unless you really know what you're doing, you should probably not use this fo…
This reads very condescending: I posed the question to learn something, not be told off.
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…
> are they slow because they are computationally intensive... In general, no. Most "slow" hashing schemes are designed to be memory-hard and highly serial (more threads = more contention, not throughput). Some of the earlier approaches just try to maximize computational requirements, but modern research acknowledges the march of computing power makes that an inherently poor choice for long term sensitive data. Argon2…
Earlier quoted context omitted.
> tune it so it’s slow enough without impacting overall usability (e.g. takes 50ms on your server) I want to insist that this is a very important part. If you are 99.9% of applications or websites out there, the only time you need to run that hash is at registration, login and password change. All of these case will be fine if it's a bit slow. Don't lowball it. Also informationally I would like to add that as part of…
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.
It did not win, and I believe it is only CPU hard and not also memory hard unlike argon2. Nevertheless techniques to do this have been explored academically and might make it into future designs.
In case it isn't obvious, please continue to use argon2 (I'm just mentioning this as a point of interest).
Earlier quoted context omitted.
SHA-224 is literally truncated SHA-256. There's no security proof this is safe, but only in the sense there is no proof SHA does what it claims to do at all. Hash truncation is in the design of SHA-2. There's even an appendix of one of the FIPS documents explaining how to do the truncation for arbitrary sizes. But be very careful to make sure that you only need preimage resistance...
A 224 bit output is going to be collision resistant too, though, for the foreseeable future. And when it comes to preimage resistance, even md5 is safe for the time being. (With the usual qualifier that there's absolutely no justification for using it with better hashes available.)
Earlier quoted context omitted.
This. There are hash functions that are faster than MD5, so it's not the fastest, and everyone knows (since 1996, actually[1]) that MD5 is insecure. If you want transmission error checking, use CRC32 or Siphash or whatever. If you want an actual, cryptographic hash function, then BLAKE3 is one of the options, though it's a very young one so unless you really know what you're doing, you should probably not use this fo…
> Heck, if anything in this comment is new to you, you'll want to steer clear of such low-level decisions and just use a library that makes the decision for you. This reads very condescending: I posed the question to learn something, not be told off.
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 decisions about these things until they learn more. Cryptographers commonly advise non-experts to use a library to do things for you (even those that know a bit more) since cryptography can be very subtle, but clearly I should have phrased that better.
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.
It's not server relief, but there's also a technique called delegated hashing, i.e. allowing the client to do part of the work of computing the actual hash. This was one of the main selling points of the Makwa candidate for the password hashing competition. It did not win, and I believe it is only CPU hard and not also memory hard unlike argon2. Nevertheless techniques to do this have been explored academically and m…
For whatever reason this seems to be seldom discussed but the general idea is as follows in hand-wavey fashion:
Set up HSM with a non-exportable symmetric key, set key usages to "encrypt only" and as one step of the hashing scheme you use, encrypt your hash through the HSM. Protected HMAC key would work too.
The result is that an attacker who compromises your password db cannot perform offline attacks on your passwords anymore - they now need to do key extraction on your HSM or remain in your infrastructure and keep running guesses through the HSM where it is relatively easy to monitor what is going on and they can't do a bajillion operations per second anymore.
Wish everyone running large user dbs like yahoo or linkedin etc applied anchoring to their password hashing - it's a relatively simple measure for an org "at scale" to make hash dumps alone useless.
Earlier quoted context omitted.
And we should all use bcrpyt to hash password. We all should have had it long long time ago, and people are still rolling out their own password hashing with salting mechanism. Biggest facepalm in the industry in my eyes.
not processing plaintext passwords on your server >> argon > scrypt > bcrypt > pbkdf2 >>> any hash
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…