linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers@kernel.org>
To: "Jason A. Donenfeld" <Jason@zx2c4.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
	Theodore Ts'o <tytso@mit.edu>
Subject: Re: [PATCH] siphash: update the HalfSipHash documentation
Date: Thu, 21 Apr 2022 16:40:11 -0700	[thread overview]
Message-ID: <YmHrWy2o72k2cFLM@sol.localdomain> (raw)
In-Reply-To: <CAHmME9rtrjyE0Cqk9qvW_xxhFduvbMt5-cmjD134JCxk2iLKDQ@mail.gmail.com>

On Fri, Apr 22, 2022 at 01:08:01AM +0200, Jason A. Donenfeld wrote:
> Hi Eric,
> 
> On Thu, Apr 21, 2022 at 10:44 PM Eric Biggers <ebiggers@kernel.org> wrote:
> > -Danger!
> > +**Danger!** HalfSipHash should only be used in a very limited set of use cases
> > +where nothing better is possible, namely:
> >
> > -Do not ever use HalfSipHash except for as a hashtable key function, and only
> > -then when you can be absolutely certain that the outputs will never be
> > -transmitted out of the kernel. This is only remotely useful over `jhash` as a
> > -means of mitigating hashtable flooding denial of service attacks.
> > +- Hashtable key functions, where the outputs will never be transmitted out of
> > +  the kernel. This is only remotely useful over `jhash` as a means of mitigating
> > +  hashtable flooding denial of service attacks.
> 
> I think we should actually drop this chunk of the patch. You wrote in
> your commit message, "HalfSipHash-1-3 is not entirely limited to
> hashtable functions, with it now being used in the interrupt entropy
> accumulator." But in fact, random.c uses HalfSipHash-1, with no three
> round finalization (since we use BLAKE2s for that). So it's not
> _quite_ the same thing. If it were, we could have gotten away by just
> calling the actual hsiphash function, but instead it's just applying
> the round function as a permutation.
> 
> If you feel strongly that somebody might accidentally copy and paste
> that after grepping for halfsiphash and trying to figure out how to
> use it, I suppose we could keep this. But it strikes me as very much
> not the same thing as the hsiphash_* family of functions.

Well, this documentation starts out by introducing HalfSipHash, and then moves
on to the the hsiphash functions.  This part is still talking about HalfSipHash,
so in that context the mention of its use in random.c is relevant.  But I could
certainly reword it to make it all about the hsiphash functions, with
HalfSipHash being mentioned more as an implementation detail.

- Eric

  reply	other threads:[~2022-04-21 23:40 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-21 20:43 [PATCH] siphash: update the HalfSipHash documentation Eric Biggers
2022-04-21 23:08 ` Jason A. Donenfeld
2022-04-21 23:40   ` Eric Biggers [this message]
2022-04-21 23:42     ` Jason A. Donenfeld

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YmHrWy2o72k2cFLM@sol.localdomain \
    --to=ebiggers@kernel.org \
    --cc=Jason@zx2c4.com \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tytso@mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).