On Thu, May 29, 2025 at 08:32:43AM -0700, Blaise Boscaccy wrote:

Lukas Wunner [off-list ref] writes:

quoted

Constraining oneself to sha256 doesn't seem future-proof.

Definitely not a bad idea, curious, how would you envision that looking
from an UAPI perspective?

If possible, extend the anonymous struct used by BPF_PROG_LOAD command
with an additional parameter to select the hash algorithm.

Alternatively, create a new command to set the hash algorithm for
subsequent BPF_PROG_LOAD commands.

Use enum hash_algo in include/uapi/linux/hash_info.h to encode the
selected algorithm.  You don't need to support all of these
(some of them are deprecated), but at least the sha3 and possibly
sha2 family is a good idea.

Note that CNSA 2.0 has raised the minimum approved hash size to
384 bits both for sha2 and sha3 in light of PQC:

https://www.fortanix.com/blog/which-post-quantum-cryptography-pqc-algorithm-should-i-use

https://media.defense.gov/2022/Sep/07/2003071836/-1/-1/0/CSI_CNSA_2.0_FAQ_.PDF

Granted, there's no mainline support for PQC signature algorithms yet,
but there's at least one out-of-tree implementation, it's only a question
of when not if something like this is submitted for mainline:

https://github.com/smuellerDD/leancrypto

Thanks,

Lukas