BLAKE3 1.0
91–100 of 126 posts
Re: BLAKE3 1.0
#92Earlier quoted context omitted.
I know ARM in principal supports BE, but never heard real BE ARM products yet. Is there one? I am just curious.
The hardware products support setting endianness at boot time. It's just a matter of OS's supporting BE mode. Netbsd releases big endian versions that work on various ARM boards. Here's an announcement showing it works on an Rpi3 and below, for example: https://mail-index.netbsd.org/port-arm/2020/12/03/msg007117.... They said at the time that it's not yet working on the Rpi4 because of issues getting BE mode and UEFI…
Re: BLAKE3 1.0
#93Earlier quoted context omitted.
The hardware products support setting endianness at boot time. It's just a matter of OS's supporting BE mode. Netbsd releases big endian versions that work on various ARM boards. Here's an announcement showing it works on an Rpi3 and below, for example: https://mail-index.netbsd.org/port-arm/2020/12/03/msg007117.... They said at the time that it's not yet working on the Rpi4 because of issues getting BE mode and UEFI…
Why would anyone want to use BE mode at all?
Or perhaps very slightly more efficient networking code, since big endian is the default order for many operations there?
Re: BLAKE3 1.0
#94If 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. https://keccak.team/sponge_duplex.html
Re: BLAKE3 1.0
#95Earlier quoted context omitted.
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?
h = SHA-256(k || m1)
you can easily compute a function `F(h, m2)` such that SHA-256(k || m1 || m2) = F(h, m2)
allowing you to forge a verifier for `m1 || m2` under `k` for any `m2` you wish without actually knowing `k`.Re: BLAKE3 1.0
#96Hopefully, like BLAKE2 it makes it into OpenSSL. One thing I was wondering about, OpenSSL 1.3 dropped support for SSL compression. Would that mean the compression function in BLAKE2 and future BLAKE3 integration couldn't be used or is this a different layer? https://en.wikipedia.org/wiki/BLAKE_(hash_function)
[1] https://github.com/openssl/openssl/issues/11613#issuecomment...
Re: BLAKE3 1.0
#97If 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. https://keccak.team/sponge_duplex.html
Yes, I imlemented a whole pile of hash functions, and I agree wholeheartedly. Whereas md5/sha seem to be have been designed by pouring a hodgepodge of complexity into a algorithm until something indecipherable turned up sha3 is simple. It's just a small number of easily understood operations, each with a clear purpose.
Actually, it looked to me like it's been an evolution. md5 is insanely complex and the sha2 family got simpler, then then we get t sha3.
Symmetric algorithms look to be going the same way. DES is insanely complex, AES less so, and Speck in almost unbelievably simple (look at the source code on Wikipedia https://en.wikipedia.org/wiki/Speck_(cipher)). It seems to be an unfashionable viewpoint, but in my mind that simplicity makes Speck seem more worthy of trust that a lot of it's rivals.
Mind you,
Re: BLAKE3 1.0
#98Earlier quoted context omitted.
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.
It should be noted that chacha20 has insanely comfortable security margin. With a more accurate estimate chacha8 has a security margin similar to that of AES, and chacha20 has 2.5 times more rounds, see if it's worth the cost.
Re: BLAKE3 1.0
#99Earlier 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…
According to zooko, one of the authors, in new-ish cpus blake3 beats sha256 even with hardware acceleration: https://twitter.com/zooko/status/1419403567320821760
Re: BLAKE3 1.0
#100One of my favorite aspects of the b3sum utility is that it has a --no-names flag: $ echo hi | b3sum --no-names 0b8b60248fad7ac6dfac221b7e01a8b91c772421a15b387dd1fb2d6a94aee438
I've noticed in my shells that when I do this I get the newline, so be wary of that if you are passing this hash around. I think echo -n should fix that on most platforms. I just tried your "hi" against https://connor4312.github.io/blake3/index.html and get hi/n - 0b8b60248fad7ac6dfac221b7e01a8b91c772421a15b387dd1fb2d6a94aee438 hi - 85052e9aab1b67b6622d94a08441b09fd5b7aca61ee360416d70de5da67d86ca