From owner-cvs-src@FreeBSD.ORG Mon Apr 12 16:58:09 2004 Return-Path: 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 5712A16A4CE; Mon, 12 Apr 2004 16:58:09 -0700 (PDT) Received: from saturn.criticalmagic.com (saturn.criticalmagic.com [68.213.16.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id E775443D2D; Mon, 12 Apr 2004 16:58:08 -0700 (PDT) (envelope-from richardcoleman@mindspring.com) Received: from mindspring.com (titan.criticalmagic.com [68.213.16.23]) by saturn.criticalmagic.com (Postfix) with ESMTP id 121EC3BD2A; Mon, 12 Apr 2004 19:58:08 -0400 (EDT) Message-ID: <407B2D20.7050106@mindspring.com> Date: Mon, 12 Apr 2004 19:58:24 -0400 From: Richard Coleman Organization: Critical Magic, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Malone References: <200404122235.aa56194@salmon.maths.tcd.ie> In-Reply-To: <200404122235.aa56194@salmon.maths.tcd.ie> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: cvs-src@FreeBSD.ORG cc: src-committers@FreeBSD.ORG cc: cvs-all@FreeBSD.ORG 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-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: richardcoleman@mindspring.com List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2004 23:58:09 -0000 David Malone wrote: >>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. Well, the original Yarrow-160 paper was based on using 3DES and SHA1 (hence the 160). But the version of Yarrow called Fortuna (chapter 10 of Practical Cryptography) uses AES with 256-bit key, and SHA-256. A quick check of the /dev/random code seems to indicate that Mark is using something similar (although it looks like he is using Yarrow style entropy estimation). But I see what you are saying. The internal state of the generator never has more than 256 bits of entropy. So, you cannot create something with more entropy than that. There are probably ways you could up this limit by keeping multiple key schedules (think of it as interleaving multiple OFB streams). But this is overkill for most practical situations. As to the question of how to integrate high speed entropy sources, I can't really give any suggestions there. I'm interested to see what is the final outcome. Richard Coleman richardcoleman@mindspring.com