[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 22 Dec 2016 16:41:59 +0100
From: "Jason A. Donenfeld" <Jason@...c4.com>
To: Hannes Frederic Sowa <hannes@...essinduktion.org>
Cc: kernel-hardening@...ts.openwall.com, "Theodore Ts'o" <tytso@....edu>,
Andy Lutomirski <luto@...capital.net>, Netdev <netdev@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>,
Linux Crypto Mailing List <linux-crypto@...r.kernel.org>, David Laight <David.Laight@...lab.com>,
Eric Dumazet <edumazet@...gle.com>, Linus Torvalds <torvalds@...ux-foundation.org>,
Eric Biggers <ebiggers3@...il.com>, Tom Herbert <tom@...bertland.com>,
Andi Kleen <ak@...ux.intel.com>, "David S. Miller" <davem@...emloft.net>,
Jean-Philippe Aumasson <jeanphilippe.aumasson@...il.com>
Subject: Re: Re: [PATCH v7 3/6] random: use SipHash in
place of MD5
Hi Hannes,
On Thu, Dec 22, 2016 at 4:33 PM, Hannes Frederic Sowa
<hannes@...essinduktion.org> 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.
> 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.
Jason
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
