From owner-freebsd-current Sun Jul 23 1: 6: 1 2000 Delivered-To: freebsd-current@freebsd.org Received: from grimreaper.grondar.za (grimreaper.grondar.za [196.7.18.138]) by hub.freebsd.org (Postfix) with ESMTP id 3414937B96F; Sun, 23 Jul 2000 01:05:52 -0700 (PDT) (envelope-from mark@grondar.za) Received: from grimreaper.grondar.za (localhost [127.0.0.1]) by grimreaper.grondar.za (8.9.3/8.9.3) with ESMTP id KAA02107; Sun, 23 Jul 2000 10:05:41 +0200 (SAST) (envelope-from mark@grimreaper.grondar.za) Message-Id: <200007230805.KAA02107@grimreaper.grondar.za> To: Kris Kennaway Cc: current@FreeBSD.org Subject: Re: randomdev entropy gathering is really weak References: In-Reply-To: ; from Kris Kennaway "Sun, 23 Jul 2000 00:40:44 MST." Date: Sun, 23 Jul 2000 10:05:41 +0200 From: Mark Murray Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > This is basically the model I am advocating for /dev/random. It's also the > alternative "basic design philosophy" described in the yarrow paper. Erm, read 4.1 again :-). The paragraph that begins "One approach..." is the old approach. It is also the approach that you are advocating. The next paragraph "Yarrow takes..." is Yarrow, and the current implementation. > See "important issue" number 2 on p6. Yarrow-derived numbers are only > "good for" 256 bits of strength. Modulo reseeds, Yarrow never accumulates > more than 256 bits of entropy. Therefore you are silly to use it for > applications which require more than 256 bits of randomness. > > > Where do you draw the line? I could make it Yarrow-N, only to have > > someone insist on $((N+1)) in the very next breath. > > Precisely, which is why /dev/random shouldn't use Yarrow, or any other > seeded-cipher PRNG. It should not use the old method, which is attackable for many reasons that Schneier makes clear. (Effectively a 128 bit hash with a reseed ("stir") every read. Can you spell "Iterative attack"? :-) ). Where does that leave us? How good were our old numbers? How many users have I screwed by implementing that system? How do we fix it? What accumulation algorithm do we use that does not clue the reader into what the internal state is? > > With what we have, I am staking my career on the "uncrackability" > > of Blowfish-256. If that holds then Yarrow is safe. (The old one > > I'm not bothered about this. My point is that, by design, Yarrow is not > suitable as a replacement for /dev/random (/dev/urandom, yes). _My_ point is that the old system is broken, and that IMO Yarrow is a good replacement. (I support my point by noting that Schneier is a far better cryptographer than I, and he designed the algorithm that I implemented). M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message