Date: Mon, 12 Apr 2004 23:46:50 +0200 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: David Malone <dwmalone@maths.tcd.ie> 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 Message-ID: <5475.1081806410@critter.freebsd.dk> In-Reply-To: Your message of "Mon, 12 Apr 2004 22:35:16 BST." <200404122235.aa56194@salmon.maths.tcd.ie>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5475.1081806410>