In b4 blakecoin
BLAKE3 1.0
51–60 of 126 posts
Re: BLAKE3 1.0
#52This is awesome. We have been using BLAKE3 in Wasmer for more than a year [1] and has been working great for us.
We were trying to find a hash function for WebAssembly files that is crypto-safe. The only alternatives that were fast enough (>1Gbps) were not crypto-safe (ahash, murmur, crc32), so BLAKE3 was the obvious choice to not sacrifice on speed while getting a cryptographic hash function.
Re: BLAKE3 1.0
#53Re: BLAKE3 1.0
#54One of my favorite aspects of the b3sum utility is that it has a --no-names flag:
$ echo hi | b3sum --no-names
0b8b60248fad7ac6dfac221b7e01a8b91c772421a15b387dd1fb2d6a94aee438Re: BLAKE3 1.0
#55Earlier quoted context omitted.
Correct, the truncated versions of SHA2 are secure against length extension.
So SHA224 and SHA384? They're not exactly common. SHA256 is pretty much the standard and SHA512 is usually used for hashing larger files due to the larger block size and thus faster speed. I don't think I've ever seen 224/384 used anywhere.
SHA-512/256 is what I default to since it is faster than SHA-256 but doesn't have the ridiculously long hash length of SHA-512
Re: BLAKE3 1.0
#56So what are the next steps for cryptographic hash functions? Is it going to just be "make even faster" ? Or are we chasing new properties, or stronger guarantees (or hopes?) of existing properties?
Not an expert, but it would be nice to provide security proofs. Not a must-have thing, perhaps, but certainly nice to have. One such example of a "provably secure" hash function is this one: https://en.wikipedia.org/wiki/SWIFFT#:~:text=In%20cryptograp.... Unfortunately, it's quite slow, and can't be used as a "random oracle".
A lot of security proofs assume the random oracle model (but not for hash functions though, which are supposed to implement the "random oracle"). Strictly speaking, the model is incorrect, because a hash function is never a random oracle. I don't know if a suitable substitute has been found.
Re: BLAKE3 1.0
#57Earlier quoted context omitted.
1.0 is not the last and final version of a product. There can always be 1.0.1 or 1.1 or 2.0. Numbers are plentiful. Rust ecosystem is already overthinking 1.0 releases, which results in tons of crates having 0.x versions while being depended on as de-facto stable.
> 1.0 is not the last and final version of a product. Of course, but if you bother to do semantic versioning, it should strive to be a stable one and not a "we are still experimenting" release. IMHO knowing that something doesn't work, or isn't even implemented yet and will be addressed in the next release is OK for an 0.x.y release, but you shouldn't rush towards 1.0.0, already planing to release it "unfinished" and…
By that logic, would you ever release a 1.0?
Imho, just having a stable API that works on x86-64 without optimizations would be enough for a 1.0 release. Having a stable API with highly optimized implementation for x86 and common ARM systems is a lot for a 1.0 release. The limitations on ARM BE could be better documented though.
Re: BLAKE3 1.0
#58BLAKE3 is a successor to BLAKE2 (used by wireguard for example) a really fast crypto hash function. It uses binary trees and other approaches that allow to use SIMD and multithreading.
Thank you for the concise explanation and context.
Re: BLAKE3 1.0
#59Earlier quoted context omitted.
Correct, the truncated versions of SHA2 are secure against length extension.
So SHA224 and SHA384? They're not exactly common. SHA256 is pretty much the standard and SHA512 is usually used for hashing larger files due to the larger block size and thus faster speed. I don't think I've ever seen 224/384 used anywhere.
For processors that have hardware SHA256 (AMD Zen, most 64-bit ARM, some Intel models), SHA224 can be computed with the same instructions.
For 64-bit CPUs without hardware SHA256, SHA512 & SHA384 are the fastest and they have identical speed (as only the values of some constants differ, while the algorithm is the same).
Most libraries and hash utilities implement all these variants, so any variant can be chosen without problems.
Re: BLAKE3 1.0
#60Earlier quoted context omitted.
So SHA224 and SHA384? They're not exactly common. SHA256 is pretty much the standard and SHA512 is usually used for hashing larger files due to the larger block size and thus faster speed. I don't think I've ever seen 224/384 used anywhere.
SHA-512/256 is what I default to since it is faster than SHA-256 but doesn't have the ridiculously long hash length of SHA-512
It is faster on any 64-bit CPU without hardware SHA256, i.e. on most Intel CPUs.
On CPUs with hardware SHA256 (AMD Zen, 64-bit ARM, some recent Intel CPUs), SHA256 is faster.