From: "Jason A. Donenfeld" <Jason@zx2c4.com> To: Jean-Philippe Aumasson <jeanphilippe.aumasson@gmail.com> Cc: George Spelvin <linux@sciencehorizons.net>, Andi Kleen <ak@linux.intel.com>, David Miller <davem@davemloft.net>, David Laight <David.Laight@aculab.com>, Eric Biggers <ebiggers3@gmail.com>, Hannes Frederic Sowa <hannes@stressinduktion.org>, kernel-hardening@lists.openwall.com, Linux Crypto Mailing List <linux-crypto@vger.kernel.org>, LKML <linux-kernel@vger.kernel.org>, Andy Lutomirski <luto@amacapital.net>, Netdev <netdev@vger.kernel.org>, Tom Herbert <tom@herbertland.com>, Linus Torvalds <torvalds@linux-foundation.org>, "Theodore Ts'o" <tytso@mit.edu>, vegard.nossum@gmail.com, "Daniel J . Bernstein" <djb@cr.yp.to> Subject: Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF Date: Fri, 16 Dec 2016 16:51:35 +0100 [thread overview] Message-ID: <CAHmME9rxCYfwyF6EADWqpAEt+yqCPgCLUVH0FPdAy7r-oPnrRg@mail.gmail.com> (raw) In-Reply-To: <CAGiyFddB_HT3H2yhYQ5rprYZ487rJ4iCaH9uPJQD57hiPbn9ng@mail.gmail.com> Hi JP & George, My function names: - SipHash -> siphash - HalfSipHash -> hsiphash It appears that hsiphash can produce either 32-bit output or 64-bit output, with the output length parameter as part of the hash algorithm in there. When I code this for my kernel patchset, I very likely will only implement one output length size. Right now I'm leaning toward 32-bit. Questions: - Is this a reasonable choice? - When hsiphash is desired due to its faster speed, are there any circumstances in which producing a 64-bit output would actually be useful? Namely, are there any hashtables that could benefit from a 64-bit functions? - Are there reasons why hsiphash with 64-bit output would be reasonable? Or will we be fine sticking with 32-bit output only? With both hsiphash and siphash, the division of usage will probably become: - Use 64-bit output 128-bit key siphash for keyed RNG-like things, such as syncookies and sequence numbers - Use 64-bit output 128-bit key siphash for hashtables that must absolutely be secure to an extremely high bandwidth attacker, such as userspace directly DoSing a kernel hashtable - Use 32-bit output 64-bit key hsiphash for quick hashtable functions that still must be secure but do not require as large of a security margin Sound good? Jason
WARNING: multiple messages have this Message-ID (diff)
From: "Jason A. Donenfeld" <Jason@zx2c4.com> To: Jean-Philippe Aumasson <jeanphilippe.aumasson@gmail.com> Cc: George Spelvin <linux@sciencehorizons.net>, Andi Kleen <ak@linux.intel.com>, David Miller <davem@davemloft.net>, David Laight <David.Laight@aculab.com>, Eric Biggers <ebiggers3@gmail.com>, Hannes Frederic Sowa <hannes@stressinduktion.org>, kernel-hardening@lists.openwall.com, Linux Crypto Mailing List <linux-crypto@vger.kernel.org>, LKML <linux-kernel@vger.kernel.org>, Andy Lutomirski <luto@amacapital.net>, Netdev <netdev@vger.kernel.org>, Tom Herbert <tom@herbertland.com>, Linus Torvalds <torvalds@linux-foundation.org>, Theodore Ts'o <tytso@mit.edu>, vegard.nossum@gmail.com, "Daniel J . Bernstein" <djb@cr.yp.to> Subject: [kernel-hardening] Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF Date: Fri, 16 Dec 2016 16:51:35 +0100 [thread overview] Message-ID: <CAHmME9rxCYfwyF6EADWqpAEt+yqCPgCLUVH0FPdAy7r-oPnrRg@mail.gmail.com> (raw) In-Reply-To: <CAGiyFddB_HT3H2yhYQ5rprYZ487rJ4iCaH9uPJQD57hiPbn9ng@mail.gmail.com> Hi JP & George, My function names: - SipHash -> siphash - HalfSipHash -> hsiphash It appears that hsiphash can produce either 32-bit output or 64-bit output, with the output length parameter as part of the hash algorithm in there. When I code this for my kernel patchset, I very likely will only implement one output length size. Right now I'm leaning toward 32-bit. Questions: - Is this a reasonable choice? - When hsiphash is desired due to its faster speed, are there any circumstances in which producing a 64-bit output would actually be useful? Namely, are there any hashtables that could benefit from a 64-bit functions? - Are there reasons why hsiphash with 64-bit output would be reasonable? Or will we be fine sticking with 32-bit output only? With both hsiphash and siphash, the division of usage will probably become: - Use 64-bit output 128-bit key siphash for keyed RNG-like things, such as syncookies and sequence numbers - Use 64-bit output 128-bit key siphash for hashtables that must absolutely be secure to an extremely high bandwidth attacker, such as userspace directly DoSing a kernel hashtable - Use 32-bit output 64-bit key hsiphash for quick hashtable functions that still must be secure but do not require as large of a security margin Sound good? Jason
next prev parent reply other threads:[~2016-12-16 15:51 UTC|newest] Thread overview: 182+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-12-15 20:29 [PATCH v5 0/4] The SipHash Patchset Jason A. Donenfeld 2016-12-15 20:29 ` [kernel-hardening] " Jason A. Donenfeld 2016-12-15 20:30 ` [PATCH v5 1/4] siphash: add cryptographically secure PRF Jason A. Donenfeld 2016-12-15 20:30 ` [kernel-hardening] " Jason A. Donenfeld 2016-12-15 22:42 ` George Spelvin 2016-12-15 22:42 ` [kernel-hardening] " George Spelvin 2016-12-15 23:00 ` Jean-Philippe Aumasson 2016-12-15 23:00 ` [kernel-hardening] " Jean-Philippe Aumasson 2016-12-15 23:28 ` George Spelvin 2016-12-15 23:28 ` [kernel-hardening] " George Spelvin 2016-12-16 17:06 ` David Laight 2016-12-16 17:06 ` [kernel-hardening] " David Laight 2016-12-16 17:06 ` David Laight 2016-12-16 17:09 ` Jason A. Donenfeld 2016-12-16 17:09 ` [kernel-hardening] " Jason A. Donenfeld 2016-12-16 17:09 ` Jason A. Donenfeld 2016-12-16 3:46 ` George Spelvin 2016-12-16 3:46 ` [kernel-hardening] " George Spelvin 2016-12-16 8:08 ` Jean-Philippe Aumasson 2016-12-16 8:08 ` [kernel-hardening] " Jean-Philippe Aumasson 2016-12-16 12:39 ` Jason A. Donenfeld 2016-12-16 12:39 ` [kernel-hardening] " Jason A. Donenfeld 2016-12-16 13:22 ` Jean-Philippe Aumasson 2016-12-16 13:22 ` [kernel-hardening] " Jean-Philippe Aumasson 2016-12-16 15:51 ` Jason A. Donenfeld [this message] 2016-12-16 15:51 ` Jason A. Donenfeld 2016-12-16 17:36 ` George Spelvin 2016-12-16 17:36 ` [kernel-hardening] " George Spelvin 2016-12-16 18:00 ` Jason A. Donenfeld 2016-12-16 18:00 ` [kernel-hardening] " Jason A. Donenfeld 2016-12-16 20:17 ` George Spelvin 2016-12-16 20:17 ` [kernel-hardening] " George Spelvin 2016-12-16 20:43 ` Theodore Ts'o 2016-12-16 20:43 ` [kernel-hardening] " Theodore Ts'o 2016-12-16 22:13 ` George Spelvin 2016-12-16 22:13 ` [kernel-hardening] " George Spelvin 2016-12-16 22:15 ` Andy Lutomirski 2016-12-16 22:15 ` [kernel-hardening] " Andy Lutomirski 2016-12-16 22:15 ` Andy Lutomirski 2016-12-16 22:18 ` Jason A. Donenfeld 2016-12-16 22:18 ` [kernel-hardening] " Jason A. Donenfeld 2016-12-16 23:44 ` George Spelvin 2016-12-16 23:44 ` [kernel-hardening] " George Spelvin 2016-12-17 1:39 ` Jason A. Donenfeld 2016-12-17 1:39 ` [kernel-hardening] " Jason A. Donenfeld 2016-12-17 2:15 ` George Spelvin 2016-12-17 2:15 ` [kernel-hardening] " George Spelvin 2016-12-17 15:41 ` Theodore Ts'o 2016-12-17 15:41 ` [kernel-hardening] " Theodore Ts'o 2016-12-17 16:14 ` Jeffrey Walton 2016-12-17 16:14 ` [kernel-hardening] " Jeffrey Walton 2016-12-19 17:21 ` Jason A. Donenfeld 2016-12-17 12:42 ` George Spelvin 2016-12-17 12:42 ` [kernel-hardening] " George Spelvin 2016-12-16 20:39 ` Jason A. Donenfeld 2016-12-16 20:39 ` [kernel-hardening] " Jason A. Donenfeld 2016-12-16 19:47 ` Tom Herbert 2016-12-16 19:47 ` [kernel-hardening] " Tom Herbert 2016-12-16 20:41 ` George Spelvin 2016-12-16 20:41 ` [kernel-hardening] " George Spelvin 2016-12-16 20:57 ` Tom Herbert 2016-12-16 20:57 ` [kernel-hardening] " Tom Herbert 2016-12-16 20:44 ` Daniel Micay 2016-12-16 20:44 ` [kernel-hardening] " Daniel Micay 2016-12-16 21:09 ` Jason A. Donenfeld 2016-12-17 15:21 ` George Spelvin 2016-12-17 15:21 ` [kernel-hardening] " George Spelvin 2016-12-19 14:14 ` David Laight 2016-12-19 14:14 ` [kernel-hardening] " David Laight 2016-12-19 14:14 ` David Laight 2016-12-19 18:10 ` George Spelvin 2016-12-19 18:10 ` [kernel-hardening] " George Spelvin 2016-12-19 20:18 ` Jean-Philippe Aumasson 2016-12-19 20:18 ` [kernel-hardening] " Jean-Philippe Aumasson 2016-12-16 2:14 ` kbuild test robot 2016-12-16 2:14 ` [kernel-hardening] " kbuild test robot 2016-12-17 14:55 ` Jeffrey Walton 2016-12-17 14:55 ` [kernel-hardening] " Jeffrey Walton 2016-12-19 17:08 ` Jason A. Donenfeld 2016-12-19 17:08 ` [kernel-hardening] " Jason A. Donenfeld 2016-12-19 17:19 ` Jean-Philippe Aumasson 2016-12-19 17:19 ` [kernel-hardening] " Jean-Philippe Aumasson 2016-12-15 20:30 ` [PATCH v5 2/4] siphash: add Nu{32,64} helpers Jason A. Donenfeld 2016-12-15 20:30 ` [kernel-hardening] " Jason A. Donenfeld 2016-12-16 10:39 ` David Laight 2016-12-16 10:39 ` [kernel-hardening] " David Laight 2016-12-16 10:39 ` David Laight 2016-12-16 15:44 ` George Spelvin 2016-12-16 15:44 ` [kernel-hardening] " George Spelvin 2016-12-15 20:30 ` [PATCH v5 3/4] secure_seq: use SipHash in place of MD5 Jason A. Donenfeld 2016-12-15 20:30 ` [kernel-hardening] " Jason A. Donenfeld 2016-12-16 9:59 ` David Laight 2016-12-16 9:59 ` [kernel-hardening] " David Laight 2016-12-16 9:59 ` David Laight 2016-12-16 15:57 ` Jason A. Donenfeld 2016-12-16 15:57 ` [kernel-hardening] " Jason A. Donenfeld 2016-12-16 15:57 ` Jason A. Donenfeld 2016-12-15 20:30 ` [PATCH v5 4/4] random: " Jason A. Donenfeld 2016-12-15 20:30 ` [kernel-hardening] " Jason A. Donenfeld 2016-12-16 3:03 ` [PATCH v6 0/5] The SipHash Patchset Jason A. Donenfeld 2016-12-16 3:03 ` [kernel-hardening] " Jason A. Donenfeld 2016-12-16 3:03 ` [PATCH v6 1/5] siphash: add cryptographically secure PRF Jason A. Donenfeld 2016-12-16 3:03 ` [kernel-hardening] " Jason A. Donenfeld 2016-12-16 3:03 ` [PATCH v6 2/5] secure_seq: use SipHash in place of MD5 Jason A. Donenfeld 2016-12-16 3:03 ` [kernel-hardening] " Jason A. Donenfeld 2016-12-16 3:03 ` [PATCH v6 3/5] random: " Jason A. Donenfeld 2016-12-16 3:03 ` [kernel-hardening] " Jason A. Donenfeld 2016-12-16 21:31 ` Andy Lutomirski 2016-12-16 21:31 ` [kernel-hardening] " Andy Lutomirski 2016-12-16 21:31 ` Andy Lutomirski 2016-12-16 3:03 ` [PATCH v6 4/5] md5: remove from lib and only live in crypto Jason A. Donenfeld 2016-12-16 3:03 ` [kernel-hardening] " Jason A. Donenfeld 2016-12-16 3:03 ` [PATCH v6 5/5] syncookies: use SipHash in place of SHA1 Jason A. Donenfeld 2016-12-16 3:03 ` [kernel-hardening] " Jason A. Donenfeld 2016-12-21 23:02 ` [PATCH v7 0/6] The SipHash Patchset Jason A. Donenfeld 2016-12-21 23:02 ` [kernel-hardening] " Jason A. Donenfeld 2016-12-21 23:02 ` [PATCH v7 1/6] siphash: add cryptographically secure PRF Jason A. Donenfeld 2016-12-21 23:02 ` [kernel-hardening] " Jason A. Donenfeld 2016-12-22 1:40 ` Stephen Hemminger 2016-12-22 1:40 ` [kernel-hardening] " Stephen Hemminger 2016-12-21 23:02 ` [PATCH v7 2/6] secure_seq: use SipHash in place of MD5 Jason A. Donenfeld 2016-12-21 23:02 ` [kernel-hardening] " Jason A. Donenfeld 2016-12-21 23:02 ` [PATCH v7 3/6] random: " Jason A. Donenfeld 2016-12-21 23:02 ` [kernel-hardening] " Jason A. Donenfeld 2016-12-21 23:13 ` Jason A. Donenfeld 2016-12-21 23:13 ` [kernel-hardening] " Jason A. Donenfeld 2016-12-21 23:42 ` Andy Lutomirski 2016-12-21 23:42 ` [kernel-hardening] " Andy Lutomirski 2016-12-21 23:42 ` Andy Lutomirski 2016-12-22 2:07 ` Hannes Frederic Sowa 2016-12-22 2:07 ` [kernel-hardening] " Hannes Frederic Sowa 2016-12-22 2:07 ` Hannes Frederic Sowa 2016-12-22 2:09 ` Andy Lutomirski 2016-12-22 2:09 ` [kernel-hardening] " Andy Lutomirski 2016-12-22 2:09 ` Andy Lutomirski 2016-12-22 2:49 ` Jason A. Donenfeld 2016-12-22 2:49 ` [kernel-hardening] " Jason A. Donenfeld 2016-12-22 2:49 ` Jason A. Donenfeld 2016-12-22 3:12 ` Jason A. Donenfeld 2016-12-22 3:12 ` [kernel-hardening] " Jason A. Donenfeld 2016-12-22 3:12 ` Jason A. Donenfeld 2016-12-22 5:41 ` Theodore Ts'o 2016-12-22 5:41 ` [kernel-hardening] " Theodore Ts'o 2016-12-22 6:03 ` Jason A. Donenfeld 2016-12-22 15:58 ` Theodore Ts'o 2016-12-22 15:58 ` [kernel-hardening] " Theodore Ts'o 2016-12-22 16:16 ` Jason A. Donenfeld 2016-12-22 16:16 ` [kernel-hardening] " Jason A. Donenfeld 2016-12-22 16:30 ` Theodore Ts'o 2016-12-22 16:36 ` Jason A. Donenfeld 2016-12-22 12:47 ` Hannes Frederic Sowa 2016-12-22 12:47 ` [kernel-hardening] " Hannes Frederic Sowa 2016-12-22 13:10 ` Jason A. Donenfeld 2016-12-22 15:05 ` Hannes Frederic Sowa 2016-12-22 15:12 ` Jason A. Donenfeld 2016-12-22 15:29 ` Jason A. Donenfeld 2016-12-22 15:33 ` Hannes Frederic Sowa 2016-12-22 15:33 ` [kernel-hardening] " Hannes Frederic Sowa 2016-12-22 15:41 ` Jason A. Donenfeld 2016-12-22 15:51 ` Hannes Frederic Sowa 2016-12-22 15:51 ` [kernel-hardening] " Hannes Frederic Sowa 2016-12-22 15:53 ` Jason A. Donenfeld 2016-12-22 15:54 ` Theodore Ts'o 2016-12-22 15:54 ` [kernel-hardening] " Theodore Ts'o 2016-12-22 18:08 ` Hannes Frederic Sowa 2016-12-22 18:13 ` Jason A. Donenfeld 2016-12-22 18:13 ` [kernel-hardening] " Jason A. Donenfeld 2016-12-22 19:50 ` Theodore Ts'o 2016-12-22 2:31 ` Jason A. Donenfeld 2016-12-22 2:31 ` [kernel-hardening] " Jason A. Donenfeld 2016-12-22 2:31 ` Jason A. Donenfeld 2016-12-21 23:02 ` [PATCH v7 4/6] md5: remove from lib and only live in crypto Jason A. Donenfeld 2016-12-21 23:02 ` [kernel-hardening] " Jason A. Donenfeld 2016-12-21 23:02 ` [PATCH v7 5/6] syncookies: use SipHash in place of SHA1 Jason A. Donenfeld 2016-12-21 23:02 ` [kernel-hardening] " Jason A. Donenfeld 2016-12-21 23:02 ` [PATCH v7 6/6] siphash: implement HalfSipHash1-3 for hash tables Jason A. Donenfeld 2016-12-21 23:02 ` [kernel-hardening] " Jason A. Donenfeld 2016-12-22 0:46 ` Andi Kleen 2016-12-22 0:46 ` [kernel-hardening] " Andi Kleen 2016-12-16 20:43 [PATCH v5 1/4] siphash: add cryptographically secure PRF Jason A. Donenfeld 2016-12-16 20:49 Jason A. Donenfeld 2016-12-16 21:25 ` George Spelvin
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=CAHmME9rxCYfwyF6EADWqpAEt+yqCPgCLUVH0FPdAy7r-oPnrRg@mail.gmail.com \ --to=jason@zx2c4.com \ --cc=David.Laight@aculab.com \ --cc=ak@linux.intel.com \ --cc=davem@davemloft.net \ --cc=djb@cr.yp.to \ --cc=ebiggers3@gmail.com \ --cc=hannes@stressinduktion.org \ --cc=jeanphilippe.aumasson@gmail.com \ --cc=kernel-hardening@lists.openwall.com \ --cc=linux-crypto@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux@sciencehorizons.net \ --cc=luto@amacapital.net \ --cc=netdev@vger.kernel.org \ --cc=tom@herbertland.com \ --cc=torvalds@linux-foundation.org \ --cc=tytso@mit.edu \ --cc=vegard.nossum@gmail.com \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.