From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jason A. Donenfeld" Subject: Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF Date: Fri, 16 Dec 2016 16:51:35 +0100 Message-ID: References: <20161216034618.28276.qmail@ns.sciencehorizons.net> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Cc: George Spelvin , Andi Kleen , David Miller , David Laight , Eric Biggers , Hannes Frederic Sowa , kernel-hardening@lists.openwall.com, Linux Crypto Mailing List , LKML , Andy Lutomirski , Netdev , Tom Herbert , Linus Torvalds , "Theodore Ts'o" , vegard.nossum@gmail.com, "Daniel J . Bernstein" To: Jean-Philippe Aumasson Return-path: Received: from frisell.zx2c4.com ([192.95.5.64]:53672 "EHLO frisell.zx2c4.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755883AbcLPPvl (ORCPT ); Fri, 16 Dec 2016 10:51:41 -0500 In-Reply-To: Sender: linux-crypto-owner@vger.kernel.org List-ID: 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Reply-To: kernel-hardening@lists.openwall.com MIME-Version: 1.0 In-Reply-To: References: <20161216034618.28276.qmail@ns.sciencehorizons.net> From: "Jason A. Donenfeld" Date: Fri, 16 Dec 2016 16:51:35 +0100 Message-ID: Content-Type: text/plain; charset=UTF-8 Subject: [kernel-hardening] Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF To: Jean-Philippe Aumasson Cc: George Spelvin , Andi Kleen , David Miller , David Laight , Eric Biggers , Hannes Frederic Sowa , kernel-hardening@lists.openwall.com, Linux Crypto Mailing List , LKML , Andy Lutomirski , Netdev , Tom Herbert , Linus Torvalds , Theodore Ts'o , vegard.nossum@gmail.com, "Daniel J . Bernstein" List-ID: 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