From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S941396AbcLVPwQ (ORCPT ); Thu, 22 Dec 2016 10:52:16 -0500 Received: from out3-smtp.messagingengine.com ([66.111.4.27]:43562 "EHLO out3-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S938986AbcLVPwN (ORCPT ); Thu, 22 Dec 2016 10:52:13 -0500 X-ME-Sender: X-Sasl-enc: ascMsymUbmzAV+TuvelWO7OULYD4mlALB1eDZMumLc36 1482421903 Message-ID: <1482421900.2673.3.camel@stressinduktion.org> Subject: Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5 From: Hannes Frederic Sowa To: "Jason A. Donenfeld" Cc: kernel-hardening@lists.openwall.com, "Theodore Ts'o" , Andy Lutomirski , Netdev , LKML , Linux Crypto Mailing List , David Laight , Eric Dumazet , Linus Torvalds , Eric Biggers , Tom Herbert , Andi Kleen , "David S. Miller" , Jean-Philippe Aumasson Date: Thu, 22 Dec 2016 16:51:40 +0100 In-Reply-To: References: <20161216030328.11602-1-Jason@zx2c4.com> <20161221230216.25341-1-Jason@zx2c4.com> <20161221230216.25341-4-Jason@zx2c4.com> <17bd0c70-d2c1-165b-f5b2-252dfca404e8@stressinduktion.org> <20161222054125.lzxhd6ctovm3wk4p@thunk.org> <1482410840.2472.2.camel@stressinduktion.org> <5c306c80-3499-8b92-21d0-c197f30ce326@stressinduktion.org> <1482420815.2673.1.camel@stressinduktion.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.22.3 (3.22.3-1.fc25) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 2016-12-22 at 16:41 +0100, Jason A. Donenfeld wrote: > Hi Hannes, > > On Thu, Dec 22, 2016 at 4:33 PM, Hannes Frederic Sowa > wrote: > > IPv6 you cannot touch anymore. The hashing algorithm is part of uAPI. > > You don't want to give people new IPv6 addresses with the same stable > > secret (across reboots) after a kernel upgrade. Maybe they lose > > connectivity then and it is extra work? > > Ahh, too bad. So it goes. If no other users survive we can put it into the ipv6 module. > > The bpf hash stuff can be changed during this merge window, as it is > > not yet in a released kernel. Albeit I would probably have preferred > > something like sha256 here, which can be easily replicated by user > > space tools (minus the problem of patching out references to not > > hashable data, which must be zeroed). > > Oh, interesting, so time is of the essence then. Do you want to handle > changing the new eBPF code to something not-SHA1 before it's too late, > as part of a new patchset that can fast track itself to David? And > then I can preserve my large series for the next merge window. This algorithm should be a non-seeded algorithm, because the hashes should be stable and verifiable by user space tooling. Thus this would need a hashing algorithm that is hardened against pre-image attacks/collision resistance, which siphash is not. I would prefer some higher order SHA algorithm for that actually. Bye, Hannes