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

[Jarkko Sakkinen]

On Fri, Nov 06, 2026 at 07:19:20PM +0000, Eric Biggers wrote:
> On Fri, Nov 06, 2026 at 09:05:15PM +0200, Jarkko Sakkinen wrote:
> > 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/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.
> > 
> > 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.
> 
> SipHash is also useful for resistance against denial-of-service attacks,
> where a user puts all their keys in one hash bucket.
> 
> As I mentioned, it's already used for secure hash tables elsewhere in
> the kernel.  That is what it's for; see
> Documentation/security/siphash.rst.  It's very fast as well, so if you
> are thinking of cryptography as being something very slow and hard to
> use, that is not what this is (or ever needed to be).
> 
> Let's just use it and not over-complicate things.

I'm pretty much non-opionated when it comes to this detail. I just
merely represent all the possible if anything comes up to mind. DoS
protection that you explained was not something I did even consider so
that seals it for me.

> 
> - Eric

Br, Jarkko