Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932917AbcLPVba (ORCPT ); Fri, 16 Dec 2016 16:31:30 -0500 Received: from frisell.zx2c4.com ([192.95.5.64]:35443 "EHLO frisell.zx2c4.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756235AbcLPVbV (ORCPT ); Fri, 16 Dec 2016 16:31:21 -0500 MIME-Version: 1.0 In-Reply-To: <20161216212528.26003.qmail@ns.sciencehorizons.net> References: <20161216212528.26003.qmail@ns.sciencehorizons.net> From: "Jason A. Donenfeld" Date: Fri, 16 Dec 2016 22:31:15 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [kernel-hardening] Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF To: kernel-hardening@lists.openwall.com Cc: George Spelvin , Andi Kleen , David Miller , David Laight , "Daniel J . Bernstein" , Eric Biggers , Hannes Frederic Sowa , Jean-Philippe Aumasson , Linux Crypto Mailing List , LKML , Andy Lutomirski , Netdev , Tom Herbert , Linus Torvalds , "Theodore Ts'o" , Vegard Nossum Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1372 Lines: 29 Hi George, On Fri, Dec 16, 2016 at 10:25 PM, George Spelvin wrote: > But yes, the sequence number is supposed to be (random base) + (timestamp). > In the old days before Canter & Siegel when the internet was a nice place, > people just used a counter that started at boot time. > > But then someone observed that I can start a connection to host X, > see the sequence number it gives back to me, and thereby learn the > seauence number it's using on its connections to host Y. > > And I can use that to inject forged data into an X-to-Y connection, > without ever seeing a single byte of the traffic! (If I *can* observe > the traffic, of course, none of this makes the slightest difference.) > > So the random base was made a keyed hash of the endpoint identifiers. > (Practically only the hosts matter, but generally the ports are thrown > in for good measure.) That way, the ISN that host X sends to me > tells me nothing about the ISN it's using to talk to host Y. Now the > only way to inject forged data into the X-to-Y connection is to > send 2^32 bytes, which is a little less practical. Oh, okay, that is exactly what I thought was going on. I just thought you were implying that jiffies could be moved inside the hash, which then confused my understanding of how things should be. In any case, thanks for the explanation. Jason