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::
Attachment:
pgpEpl4I94Z_j.pgp
Description: OpenPGP digital signature
