From owner-cvs-all@FreeBSD.ORG Mon Apr 12 21:50:26 2004 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B1F9D16A50B for ; Mon, 12 Apr 2004 21:50:26 -0700 (PDT) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 2761343D2D for ; Mon, 12 Apr 2004 21:50:26 -0700 (PDT) (envelope-from silby@silby.com) Received: (qmail 10651 invoked from network); 13 Apr 2004 04:50:24 -0000 Received: from niwun.pair.com (HELO localhost) (209.68.2.70) by relay.pair.com with SMTP; 13 Apr 2004 04:50:24 -0000 X-pair-Authenticated: 209.68.2.70 Date: Tue, 13 Apr 2004 01:07:22 -0500 (CDT) From: Mike Silbersack To: Poul-Henning Kamp In-Reply-To: <5475.1081806410@critter.freebsd.dk> Message-ID: <20040413010417.U11578@odysseus.silby.com> References: <5475.1081806410@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: src-committers@FreeBSD.org cc: cvs-src@FreeBSD.org cc: cvs-all@FreeBSD.org cc: David Malone cc: richardcoleman@mindspring.com cc: Mark Murray cc: Nate Lawson Subject: Re: cvs commit: src/sys/modules/random Makefile src/sys/dev/random randomdev.h randomdev_soft.c randomdev_soft.h yar X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2004 04:50:26 -0000 On Mon, 12 Apr 2004, Poul-Henning Kamp wrote: > I therefore think that we should retain a crypto/yarrow afterburner > on all random sources, but it may make sense to have offer different > grades of random bits for performance reasons. > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 One thing that might make sense is to rename + wrap arc4random. In the TCP stack, we use arc4random because it's fast and good enough, not because RC4 has some particular importance. Therefore, if we instead called arc4random fast_random, Mark could feed minimally processed hardware entropy sources to fast_random, bypassing RC4 totally. However, the question I have is this: Is the C3's hardware PRNG actually faster than RC4 by a margin significant enough to make such an optimization worthwhile? Mike "Silby" Silbersack