Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757582AbcLOH7N (ORCPT ); Thu, 15 Dec 2016 02:59:13 -0500 Received: from helcar.hengli.com.au ([209.40.204.226]:34407 "EHLO helcar.apana.org.au" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753387AbcLOH7D (ORCPT ); Thu, 15 Dec 2016 02:59:03 -0500 Date: Thu, 15 Dec 2016 15:57:46 +0800 From: Herbert Xu To: "Jason A. Donenfeld" Cc: hannes@stressinduktion.org, netdev@vger.kernel.org, kernel-hardening@lists.openwall.com, linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org, jeanphilippe.aumasson@gmail.com, djb@cr.yp.to, torvalds@linux-foundation.org, ebiggers3@gmail.com Subject: Re: [PATCH v2 1/4] siphash: add cryptographically secure hashtable function Message-ID: <20161215075746.GA14699@gondor.apana.org.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Newsgroups: apana.lists.os.linux.cryptoapi,apana.lists.os.linux.kernel,apana.lists.os.linux.netdev Organization: Core User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 692 Lines: 17 Jason A. Donenfeld wrote: > > Siphash needs a random secret key, yes. The point is that the hash > function remains secure so long as the secret key is kept secret. > Other functions can't make the same guarantee, and so nervous periodic > key rotation is necessary, but in most cases nothing is done, and so > things just leak over time. Actually those users that use rhashtable now have a much more sophisticated defence against these attacks, dyanmic rehashing when bucket length exceeds a preset limit. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt