Add Blake2B hash support ?

[udf2457]

Currently you have sha256 and sha512.

Could you consider adding blake2b in 256 & 512 ?

Yes the blake functions are under /x/crypto but as Filippo Valsorda (maintainer of crypto/... and x/crypto...) says here, you should not treat them differently as they are maintained in the same manner. Its just that x has a faster cadence.

As for why Blake2b ? The official website covers it nicely. TL;DR 64-bit friendly and works better on constrained machines, especially those with no hardware acceleration for SHA.

[jku]

The only argument against adding new algorithms is that keeping implementations compatible with each other is something many of us want -- and currently [sha256, sha512] is the set known to be supported by the major TUF implementations...

That said, blake2b is good and is already supported by python-tuf (since python-tuf supports everything hashlib does and for better or worse leaves the compatibility issues for the user to resolve...). There is one detail in the python-tuf implementation I will point out: blake2b refers to the full 64 byte digest but blake2b-256 is supported as well for the 32 byte digest. We could change to blake2b-512 and blake2b-256 for consistency if requested.

Checklist for better blake2b support in TUF ecosystem in general would be

• discuss in TUF community meeting: should "common hash algorithm" set be documented somewhere? I'll add this tentatively to agenda although I'm not sure I'll be in the call myself https://hackmd.io/jdAk9rmPSpOYUdstbIvbjw
• Add blake2b (and maybe blake2b-256) in tuf-conformance test suite so client projects notice a failing test and decide if they want to support blake2b or not
• Add support in go-tuf specifically

[udf2457]

@jku Agree specifically with your "common hash algorithm" point. Before opening this issue yesterday, I did look through the TUF spec and I was surprised there was no list of hash algorithms, not even sha256 or sha512. Meanwhile the spec is very happy to dictate what signature formats should be supported.

sha256 is only mentioned in the specs in the example files, not in the spec itself
sha512 receives no mention whatsoever

So theoretically under the present spec wording there is no guarantee of sha256 or sha512 support, let alone blake2b.

[jku]

So theoretically under the present spec wording there is no guarantee of sha256 or sha512 support, let alone blake2b.

This is correct and in fact even the signing algorithms are just examples: no support is required IIRC. The tuf spec desperately needs a companion "implementer notes" document but the best we have at the moment is the conformance test suite

[JustinCappos]

We have something like this with the POUF system in Uptane <https://uptane.org/enhancements/pouf/pouf-main>. Most TUF implementations are in their own ecosystem, which may make interoperability less important.

…

On Wed, Jan 22, 2025 at 10:03 AM Jussi Kukkonen ***@***.***> wrote: So theoretically under the present spec wording there is no guarantee of sha256 or sha512 support, let alone blake2b. This is correct and in fact even the signing algorithms are just examples: no support is required IIRC. The tuf spec desperately needs a companion "implementer notes" document but the best we have at the moment is the conformance test suite — Reply to this email directly, view it on GitHub <#668 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGROD4U4CMNFB27UA5EOIL2L6XN5AVCNFSM6AAAAABVS2ZP4CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMMBXGQ4DSMBSGA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[jku]

Most TUF implementations are in their own ecosystem, which may make interoperability
less important.

This was almost certainly a self fulfilling prophecy: Because tuf libraries did not (and could not) guarantee compatibility with each other, of course end users avoided using TUF for anything that would require interoperability: Doing so would have been foolish of them.

[udf2457]

in fact even the signing algorithms are just examples: no support is required IIRC

Interestingly:

Implementing the KEYTYPEs and SCHEMEs below is RECOMMENDED for all implementations, as this enables interoperability.

So not required, but "RECOMMENDED", which is more than can be said for the hashes which are left as an "exercise to the reader". 😆