Re: [PATCH v5 2/3] KEYS: Replace assoc_array with rhashtable

[Hannes Reinecke <hare@suse.de>]

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/20261026183332.11402-1-ebiggers@kernel.org/
> 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
hare@suse.de                                +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