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.

Cheers,

Hannes
--
Dr. Hannes Reinecke                  Kernel Storage Architect
[email protected]                                +49 911 74053 688
SUSE Software Solutions GmbH, Frankenstr. 146, 90461 Nürnberg
HRB 36809 (AG Nürnberg), GF: I. Totev, A. McDonald, W. Knoblich

Reply via email to