Date: Mon, 12 Apr 2004 19:58:24 -0400 From: Richard Coleman <richardcoleman@mindspring.com> 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 randomdev.h randomdev_soft.c randomdev_soft.h yar Message-ID: <407B2D20.7050106@mindspring.com> In-Reply-To: <200404122235.aa56194@salmon.maths.tcd.ie> References: <200404122235.aa56194@salmon.maths.tcd.ie>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?407B2D20.7050106>