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/[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. > > 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
