On Fri, Nov 06, 2026 at 02:02:11PM +0100, Hannes Reinecke wrote: > On 11/6/26 10:05 AM, Eric Biggers wrote: > > On Fri, Nov 06, 2026 at 09:21:32AM +0100, Hannes Reinecke wrote: > > > While I am pretty much in favour with this approach, is there a specific > > > reason why siphash has been chosen? > > > > SipHash is the preferred choice for secure hash tables. It is secure, > > performs well on short inputs, and doesn't require special instructions. > > See Documentation/security/siphash.rst > > > > > Would there be a chance to make this configurable? > > > I do see slight complications when running in secure environments > > > (ie FIPS-certified environments) where most of the hash functions > > > might not be available ... > > > > SipHash support is available even when the kernel is booted with fips=1, > > so there's no issue there. It's already widely used in the kernel for > > hash tables, and that hasn't blocked FIPS certifications either. > > > Ah, right. Thanks for the information. Just wanted to cross-check here. > > > Side note: fips=1 actually has little do with security, and in some > > cases it actually decreases security. See for example > > https://lore.kernel.org/linux-crypto/[email protected]/ > > where I'm fixing a vulnerability caused by fips=1. > > > Oh, I am fully aware. FIPS is more a rubber-stamp than anything else. > Unfortunately, a pretty powerful one.
Just representing this as an option but in the current mainline indices are used instead of addresses, and thus it would be also an option to just jhash across the board, if that part is retained (now it is being removed). On plus side, any security bugs in cryptography would not be a concern of keyrings. Br, Jarkko
