From owner-cvs-all@FreeBSD.ORG Mon Apr 12 14:47:03 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 66B3016A4CE; Mon, 12 Apr 2004 14:47:03 -0700 (PDT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id A4D7C43D31; Mon, 12 Apr 2004 14:47:02 -0700 (PDT) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.11/8.12.11) with ESMTP id i3CLkot6005476; Mon, 12 Apr 2004 23:46:50 +0200 (CEST) (envelope-from phk@phk.freebsd.dk) To: David Malone From: "Poul-Henning Kamp" In-Reply-To: Your message of "Mon, 12 Apr 2004 22:35:16 BST." <200404122235.aa56194@salmon.maths.tcd.ie> Date: Mon, 12 Apr 2004 23:46:50 +0200 Message-ID: <5475.1081806410@critter.freebsd.dk> cc: src-committers@FreeBSD.org cc: cvs-src@FreeBSD.org cc: cvs-all@FreeBSD.org cc: richardcoleman@mindspring.com cc: Mark Murray cc: Nate Lawson 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-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: Mon, 12 Apr 2004 21:47:03 -0000 In message <200404122235.aa56194@salmon.maths.tcd.ie>, David Malone writes: >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. Given that I'm one of the largest consumers of random bits in the kernel (in GBDE), I would like to chime in with a few observations: In most of cryptography, it is not about making things absolutely secure (which is impossible), it is about making things secure enough. Typically a good criteria for this is to pinpoint another vastly cheaper attack strategy. Even with the very limited randomness we provide to yarrow with the normal setup, any attacker who is able to manipulate or predict the random bits you get/got, would be in a position to inflict so much more harm on you in other ways that he would not care about your random bits. Still, we have to be weary of systematic errors, both in Yarrow, but more so in the output from RNG HW because otherwise it may not remain so. 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 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.