linux-kernel - linux-next: manual merge of the random tree with the jc

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 22 Apr 2022 13:59:27 +1000
From:   Stephen Rothwell <sfr@...b.auug.org.au>
To:     Theodore Ts'o <tytso@....edu>,
        "Jason A. Donenfeld" <Jason@...c4.com>,
        Jonathan Corbet <corbet@....net>
Cc:     Bagas Sanjaya <bagasdotme@...il.com>,
        Eric Biggers <ebiggers@...gle.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux Next Mailing List <linux-next@...r.kernel.org>
Subject: linux-next: manual merge of the random tree with the jc_docs tree

Hi all,

Today's linux-next merge of the random tree got a conflict in:

  Documentation/security/siphash.rst

between commits:

  dc701cfc5b26 ("Documentation: siphash: convert danger note to warning for HalfSipHash")
  561fb3cd5ec2 ("Documentation: siphash: enclose HalfSipHash usage example in the literal block")

from the jc_docs tree and commit:

  91afe794c070 ("siphash: update the hsiphash documentation")

from the random tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc Documentation/security/siphash.rst
index 06d793e68086,79ac8101406c..000000000000
--- a/Documentation/security/siphash.rst
+++ b/Documentation/security/siphash.rst
@@@ -121,15 -121,23 +121,25 @@@ even scarier, uses an easily brute-forc
  instead of SipHash's 128-bit key. However, this may appeal to some
  high-performance `jhash` users.
  
+ HalfSipHash support is provided through the "hsiphash" family of functions.
+ 
 -**Danger!** Do not ever use the hsiphash functions 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.
 +.. warning::
 +   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.
  
- Generating a HalfSipHash key
- ============================
+ On 64-bit kernels, the hsiphash functions actually implement SipHash-1-3, a
+ reduced-round variant of SipHash, instead of HalfSipHash-1-3. This is because in
+ 64-bit code, SipHash-1-3 is no slower than HalfSipHash-1-3, and can be faster.
+ Note, this does *not* mean that in 64-bit kernels the hsiphash functions are the
+ same as the siphash ones, or that they are secure; the hsiphash functions still
+ use a less secure reduced-round algorithm and truncate their outputs to 32
+ bits.
+ 
+ Generating a hsiphash key
+ =========================
  
  Keys should always be generated from a cryptographically secure source of
  random numbers, either using get_random_bytes or get_random_once::

Content of type "application/pgp-signature" skipped