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

[Hannes Reinecke]

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@xxxxxxxxxx/
> 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@xxxxxxx                                +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