Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 30 Nov 1999 13:42:26 -0800 (PST)
From:      Kris Kennaway <kris@hub.freebsd.org>
To:        Mark Murray <mark@grondar.za>
Cc:        Brad Knowles <blk@skynet.be>, security@FreeBSD.ORG
Subject:   Re: cvs commit: src/sys/i386/conf files.i386 src/sys/kern kern_fork.c src/sys/libkern arc4random.c src/sys/sys libkern.h 
Message-ID:  <Pine.BSF.4.21.9911301333210.31430-100000@hub.freebsd.org>
In-Reply-To: <199911301942.VAA17801@gratis.grondar.za>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 30 Nov 1999, Mark Murray wrote:

> [ Moved to security. Off-topic for -audit ]
> 
> > 	While T'so may not be a cryptographer by trade, it is my 
> > understanding that he has quite a bit of understanding of how crypto 
> > works (due to his involvement in PGP), and is a rather good 
> > programmer.
> 
> He's big in MIT kerberos. I think I trust him.

Maybe I was ambiguous in my initial method. I wasn't calling his abilities
into question, just raising the point that if the choice was between
something designed by an amateur cryptographer, and something designed by
a professional, I'd pick the latter, all other things being equal.

For the benefit of the newcomers to this thread (now that it's been moved
where it probably should have been sent in the first place :) the
discussion was in regard to the relative merits of our current PRNG
{/dev/random, /dev/urandom} vs. the OpenBSD variant {/dev/random,
/dev/arandom} and a third alternative, the Yarrow algorithm by Schneier.

My conclusion is that what we have now is "good enough" not to worry about
it excessively, and urandom is better than the OpenBSD variant arandom
because it doesn't propagate state compromises deterministically (based on
my reading of the code, if you break the state of the OpenBSD
/dev/arandom, then you get on average the next 64 (up to 128) free
"random" numbers with perfect certainty, and probabilistically thereafter,
with a decay time 128 times longer than ours, which effectively reseeds
every access). The downside is that ours is slower and consumes more
entropy. If anyone has anything to add here I'd welcome the discussion..

Kris



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.9911301333210.31430-100000>