Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S266296AbUI0O4l (ORCPT ); Mon, 27 Sep 2004 10:56:41 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S266304AbUI0O4l (ORCPT ); Mon, 27 Sep 2004 10:56:41 -0400 Received: from [69.25.196.29] ([69.25.196.29]:22978 "EHLO thunker.thunk.org") by vger.kernel.org with ESMTP id S266296AbUI0O4g (ORCPT ); Mon, 27 Sep 2004 10:56:36 -0400 Date: Mon, 27 Sep 2004 10:55:55 -0400 From: "Theodore Ts'o" To: Jean-Luc Cooke Cc: linux-kernel@vger.kernel.org Subject: Re: [PROPOSAL/PATCH] Fortuna PRNG in /dev/random Message-ID: <20040927145555.GB15589@thunk.org> Mail-Followup-To: Theodore Ts'o , Jean-Luc Cooke , linux-kernel@vger.kernel.org References: <20040923234340.GF28317@certainkey.com> <20040927045828.GA13887@thunk.org> <20040927133203.GF28317@certainkey.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040927133203.GF28317@certainkey.com> User-Agent: Mutt/1.5.6+20040818i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1640 Lines: 32 On Mon, Sep 27, 2004 at 09:32:03AM -0400, Jean-Luc Cooke wrote: > > I'll read over this once I finish re-writing my patch to use your entropy > estimation. While you're at it, please re-read RFC 793 and RFC 1185. You still don't have TCP sequence generation done right. The global counter is being increased for every TCP connection, and with only eight bits, it can wrap very frequently. Encrypting the source/destination address/port tuple and using that as an offset to the global clock, and then only bumping the counter when you rekey would be much more in the spirit of RFC 1185, and would result in sequence numbers much less likely to cause stale packets to get mistakenly accepted. I'm still a bit concerned about whether doing AES is going to be a speed issue. Your comparisons against MD4 using openssl don't really prove much, because (a) the original code used a cut-down MD4, and (b) the openssl benchmark does a large number of encryptions and nothing else, so all of the AES key schedule and tables will be in cache. The only real way to settle this would be to ask Jamal and some of the other networking hackers to repeat their benchmarks and see if the AES encryption for every TCP SYN is a problem or not. CPU's have gotten faster (but then again so have networks, and memory has *not* gotten much faster), so only a real benchmark will tell us for sure. - Ted - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/