One of my favorite aspects of the b3sum utility is that it has a --no-names flag: $ echo hi | b3sum --no-names 0b8b60248fad7ac6dfac221b7e01a8b91c772421a15b387dd1fb2d6a94aee438
Sometimes genius is in the little things :)
BLAKE3 1.0
61–70 of 126 posts
Re: BLAKE3 1.0
#62Earlier 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…
Big-endian ARM basically does not exist in the wild. It is very much an edge case of an edge case, and definitely not something that should be a blocker for a 1.0 release.
Re: BLAKE3 1.0
#63If I had a BLAKE3 implementation available in the programming language of choice, is there any reason to still prefer the SHA family over it (for integrity checks, not for password hashing, as mentioned in the readme)?
Aside from the various technical reasons others have given, I would like to say please have a look at the underlying design of SHA-3 - it’s really elegant, with so many applications beyond just hash functions. Ironically, I feel like SHA-3 should obsolete block ciphers like AES more than it obsoletes SHA-2.
Re: BLAKE3 1.0
#64Earlier quoted context omitted.
According to zooko, one of the authors, in new-ish cpus blake3 beats sha256 even with hardware acceleration: https://twitter.com/zooko/status/1419403567320821760
I'd like to see the benchmarks, including power draw. I suspect it is similar to soft ChaCha vs hard AES. A ChaCha software implementation can achieve similar speed as the AES hardware at the cost of significantly higher power draw due to pushing the AVX units at near maximum utilization.
I benchmarked hardware AES vs software ChaCha20, and the former showed an overall performance improvement of an end to end QUIC software stack of more than 50%. The pure crypto difference is probably even higher. That's a huge gap - even thought it might totally be possible that the ChaCha20 implementation of Ring is still improvable.
As a result of that, I asked for rustls to default to AES instead of the previous ChaCha20 default [1]
Re: BLAKE3 1.0
#65So 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?
Variants of "make even faster" (including "making keys smaller" or "allow to run on more limited hardware") is most of what drives new core cryptographic primitives. There's a tweet from one of the BLAKE authors (@veorq) saying what I think a bunch of cryptography engineers believe, that it's unlikely that SHA2 will ever be directly broken.
There are security improvements in new primitives, often based on a notion of "misuse-resistance". SHA2 isn't broken; it remains quite strong. But it's a classic Merkle Damgard design, which means you can take the output of SHA2 and hash more data into it, which breaks simple keyed hash constructions like H(k, m) (this is why we have HMAC!). SHA3 and other modern hashes don't have this property; you can safely build simple keyed hash constructions out of them. You can see the same thing with AEADs (the SIVs vs. GCM) and with curves (Curve25519, for instance, where keys are --- don't @ me --- just simple random byte strings).
Re: BLAKE3 1.0
#66This 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. [1] https://github.com/…
Yeah it's a bummer that a highwayhash is only cryptographically strong (but not cryptographically secure) as it can be significantly faster (3x).
But BLAKE3 does seem to offer the best compromise when a cryptographically secure hash is required.
Re: BLAKE3 1.0
#67Earlier quoted context omitted.
xxhash is not suitable for cryptographic purposes, but much faster.
I assume MD5 is in there too now. Just out of curiosity, what are the most common use cases for non-cryptographic hash functions?
MD5 isn't particularly fast. Basic non-vector BLAKE3 beats it, and SHA1 beats it by even more.
Re: BLAKE3 1.0
#68Earlier quoted context omitted.
Security-wise they are roughly equivalent. While SHA has had more eyes on it I doubt either construction will ever be practically broken at hash sizes like 384 or 512 bits. Someone may find an "academic break" at some point. BLAKE3 is faster, sometimes a lot faster, on hardware without SHA instructions. On hardware with SHA instructions SHA may be faster. Same as the AES story where AES is faster than ChaCha on CPUs…
One aspect of security is also the misuse resistance. You can of course create a secure MAC with SHA256 in the HMAC configuration, but it usually takes a masters level course on cryptography to know what is Merkle-Damgård construction, and why it's design is imperfect: You can't just do SHA256(key + message) to generate a safe MAC. With BLAKE (and all SHA3 finalists) you can do that safely. It's true every time you m…
> You can't just do SHA256(key + message) to generate a safe MAC.
Can you explain this?
Re: BLAKE3 1.0
#69Earlier 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…
Support for an architecture would be a minor release, no? That's "adding a feature". It wouldn't be a breaking change.
Re: BLAKE3 1.0
#70How does it compare against xxhash?
I like to check smhasher for comparison of many hash implementations: https://github.com/rurban/smhasher. It’s a bit clunky to search for the exact items you want to compare, but there’s lots of data and a good summary under the table.