21–30 of 171 posts
Even CRC32 is still used in embedded systems for short pieces of data.
Is there anything else important for detecting transmission errors if the data was sent encrypted, or is something like MD5 still sufficient for such uses?
Is Blake3 even worth considering for such a use case?
Earlier quoted context omitted.
For general purpose algorithms yes. Blake3 is not a password hashing algorithm it’s a general purpose one, used for checksums or verifying 2 files are the same etc. For password hashing you’re correct they should be slow, bcrypt for example.
> For password hashing you’re correct they should be slow, bcrypt for example. Slowness is not the quality of a hashing algorithm that guarantees anything :)
Resistance to quickly creating a rainbow table with significant coverage, however, is a reasonable property.
The mentioned bcrypt library allows you to “tighten the ratchet” over time as average computing power increases to make hashing a single password in 2010 take about the same amount of time on average modern computing hardware as in 2020 (assuming you correctly increase the number of iterations)
Earlier quoted context omitted.
For general purpose algorithms yes. Blake3 is not a password hashing algorithm it’s a general purpose one, used for checksums or verifying 2 files are the same etc. For password hashing you’re correct they should be slow, bcrypt for example.
> For password hashing you’re correct they should be slow, bcrypt for example. Slowness is not the quality of a hashing algorithm that guarantees anything :)
The commenter above obviously meant "slow to brute-force".
You're pedantically interpreting it to mean "slow for a given implementation, even if there are some scenarios under which it would be faster to brute force".
What the parent comment meant is clear enough I think, and it's accurate in that context. The whole point of modern hashing algorithms that require memory and have scaling difficulty factors is to make it slower for an attacker with certain kinds of resources to brute force it.
If you have a very slow hashing algorithm implementation of a fast hashing algorithm (say 'sleep 5, echo 1'), that's not slow by the parent's comment definition because it's not slow to brute force.
Similarly, if the hashing algorithm has predictable output that allows the attacker to derive information about the input, that obviously is also faster to brute-force.
That sort of pedantry is arguably somewhat useful if you also choose to provide a more precise definition or explanation. It's definitely not constructive if you just add a little smiley face and do it as an asinine "hah look at how smart I am".
What are the criteria for choosing an integrity checking hash? Speed is always desired, and longer output makes collisions due to random bit swaps less likely. Even CRC32 is still used in embedded systems for short pieces of data. Is there anything else important for detecting transmission errors if the data was sent encrypted, or is something like MD5 still sufficient for such uses? Is Blake3 even worth considering…
Speed comparison from the BLAKE3 authors: https://github.com/BLAKE3-team/BLAKE3/ I hadn't heard of BLAKE3 before (I thought BLAKE2b was the latest and greatest), judging by commits from the repositories of that user it's about half a year old now. Paper's abstract starts with: > BLAKE3 [is] an evolution of the BLAKE2 cryptographic hash that is both faster and also more consistently fast across different platforms and…
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
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 and SHA is entirely sequential
What are the criteria for choosing an integrity checking hash? Speed is always desired, and longer output makes collisions due to random bit swaps less likely. Even CRC32 is still used in embedded systems for short pieces of data. Is there anything else important for detecting transmission errors if the data was sent encrypted, or is something like MD5 still sufficient for such uses? Is Blake3 even worth considering…
I don't think it's a coincidence that BLAKE3 has been released shortly after the latest SHA-1 news. Many SHA-1 users would rather avoid the performance impact of SHA-2/3.