Date: Tue, 22 Jul 2008 14:48:26 +0400 From: Andrey Chernov <ache@nagual.pp.ru> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/lib/libc/gen arc4random.c Message-ID: <20080722104826.GA76326@nagual.pp.ru> In-Reply-To: <37711.1216722891@critter.freebsd.dk> References: <200807221031.m6MAVe9I012301@repoman.freebsd.org> <37711.1216722891@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Jul 22, 2008 at 10:34:51AM +0000, Poul-Henning Kamp wrote: > In message <200807221031.m6MAVe9I012301@repoman.freebsd.org>, "Andrey A. = Cherno > v" writes: >=20 > > Increase initially dropped bytes from 512 to 768 (768 is also > > suggested in the Ilya Mironov's article). 768 taken from another > > research where it treats as default for RC4-drop(768): > > http://www.users.zetnet.co.uk/hopwood/crypto/scan/cs.html#RC4-drop >=20 > I've always wondered why the dropped number of bytes is constant, > wouldn't it be smarter to drop a constant number, and then pull > out the next byte and drop that many further bytes ? =46rom math point of view, small pseudo-random dropping fraction added will= =20 not increase distribution significantly. With good seeding from the kernel= =20 PRNG even 256 bytes is enough (as OpenBSD currently does). It is just for= =20 formal RC4-drop(768) implementation as it described and for rare corner=20 cases when /dev/urandom is unavailable. --=20 http://ache.pp.ru/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080722104826.GA76326>