Live data from Hacker News

BLAKE3 1.0

github.com

91–100 of 126 posts

Re: BLAKE3 1.0

#92
post #47
post #34

Earlier 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…

Why would anyone want to use BE mode at all?

Re: BLAKE3 1.0

#93
post #47

Earlier 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?

Handy for testing that your code doesn't have any endian bugs that might crop up if someone tried compiling it on older RISC hardware?

Or perhaps very slightly more efficient networking code, since big endian is the default order for many operations there?

Re: BLAKE3 1.0

#94
post #63

If 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

SHA-3 is extremely slow compared to common ciphers like AES and ChaCha20. Sponge functions might someday become the building blocks of symmetric ciphers, but it's unlikely that SHA-3 will (without hardware acceleration).

Re: BLAKE3 1.0

#95
post #22

Earlier 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?

If you have the output

    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

#96
post #8

Hopefully, 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)

It won't be added to OpenSSL until it's standardized (see [1]). However there's an external provider available of somewhat dubious quality that adds support for it ([2]).

[1] https://github.com/openssl/openssl/issues/11613#issuecomment...

[2] https://github.com/J-Montgomery/blake3-prov

Re: BLAKE3 1.0

#97
post #63

If 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

> look at the underlying design of SHA-3 - it’s really elegant

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

#98
post #37

Earlier 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.

Unfortunately almost no one can use ChaCha8 since the standards all call for ChaCha20.

Re: BLAKE3 1.0

#99
post #5

Earlier 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

That sort of depends: https://github.com/rui314/mold/issues/92#issuecomment-879709...

Re: BLAKE3 1.0

#100
post #77

One 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

Use printf.
Post reply on HN