On 24/03/2026 01:30, danny mcClanahan wrote:
Hello coreutils,
I was hoping to open a discussion about implementing the BLAKE3 algorithm, the
project's understanding of length extension attacks, and how an archive format
might be able to take advantage of features of tree hashes of this variety in
concert with an implementation such as coreutils.
Coincidentally I responded to someone privately about blake3 yesterday, with:
"""
Yes we probably should add blake3 support given blake2 is in place.
We copied the blake2 reference implementation into the coreutils repo,
so we could do similarly for blake3 (https://github.com/BLAKE3-team/BLAKE3)
Note we defer our platform specific optimized implementation to openssl,
but I don't see blake3 as being available in openssl-3.5.4 at least.
Though that wouldn't be a blocker as we don't use any optimized blake2
routines at present.
As for interface, we're not going to add any more separate *sum utilities.
That's not a scalable solution.
Instead we should do like we did for sha3 and sm3
and just add a new option to `cksum -a blake3`.
It helps that blake3 doesn't hav variants like blake2 did.
You can see the current GNU cksum interface at:
https://www.gnu.org/s/coreutils/manual/coreutils.html#cksum-a
"""
I would love nothing more than to engage in this, but I happened to be made aware of a
new section in the kernel config through what seems to have been "luck" on
Friday and a lot of facially broken changes are being added at an incredible clip.
In general the Linux kernel makes huge efforts in backwards compatibility,
so I'd be optimistic on them keeping compat here. In any case,
coreutils doesn't depend on --with-linux-crypto as it's off by default
for reasons previously discussed. In summary it's more suited to those
with dedicated hardware, and otherwise can be slower than other software
implementations.
cheers,
Padraig
