From owner-cvs-src@FreeBSD.ORG  Mon Apr 12 14:35:21 2004
Return-Path: <owner-cvs-src@FreeBSD.ORG>
Delivered-To: cvs-src@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP
	id EE47616A4CE; Mon, 12 Apr 2004 14:35:21 -0700 (PDT)
Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11])
	by mx1.FreeBSD.org (Postfix) with SMTP
	id B864F43D5F; Mon, 12 Apr 2004 14:35:20 -0700 (PDT)
	(envelope-from dwmalone@maths.tcd.ie)
Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP
          id <aa56194@salmon>; 12 Apr 2004 22:35:19 +0100 (BST)
To: richardcoleman@mindspring.com
In-reply-to: Your message of "Mon, 12 Apr 2004 08:07:43 EDT."
             <407A868F.8040108@mindspring.com> 
X-Request-Do: 
Date: Mon, 12 Apr 2004 22:35:16 +0100
From: David Malone <dwmalone@maths.tcd.ie>
Message-ID: <200404122235.aa56194@salmon.maths.tcd.ie>
cc: cvs-src@FreeBSD.ORG
cc: src-committers@FreeBSD.ORG
cc: cvs-all@FreeBSD.ORG
cc: Mark Murray <mark@grondar.org>
cc: Nate Lawson <nate@root.org>
Subject: Re: cvs commit: src/sys/modules/random Makefile src/sys/dev/random
	harvest.c hash.c hash.h nehemiah.c nehemiah.h probe.c randomdev.c
	randomdev.h randomdev_soft.c randomdev_soft.h yar 
X-BeenThere: cvs-src@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: CVS commit messages for the src tree <cvs-src.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/cvs-src>,
	<mailto:cvs-src-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/cvs-src>
List-Post: <mailto:cvs-src@freebsd.org>
List-Help: <mailto:cvs-src-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/cvs-src>,
	<mailto:cvs-src-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Apr 2004 21:35:22 -0000

> I think the old /dev/random caused more problems than it solved.  Most 
> apps just used /dev/urandom to avoid all the end-user questions about 
> the blocking.

I largely agree.

> And the beauty of the Yarrow PRNG is that as long as you have enough 
> initial entropy to get started, you can pull as many bytes as you want 
> and still remain cryptographically strong (within some very high limit 
> of like 2^120 bytes before the next re-keying).

It is still no good for generating keys that have more unpredictable
bits than Yarrow's internal state, unless you can be sure that it
has reseeded. For example, the Yarrow paper notes that there is no
point using Yarrow-160 for generating 256 bit block cipher keys and
that using it for things like one time pads are right out.

	David.