Date: Mon, 7 Oct 2002 15:19:52 -0300 (ART) From: Fernando Gleiser <fgleiser@cactus.fi.uba.ar> To: Kevin Oberman <oberman@es.net> Cc: parv <parv_fm@emailgroups.net>, FreeBSD Questions LIST <FreeBSD-Questions@FreeBSD.Org> Subject: Re: dilution of /dev/urandom Message-ID: <20021007151207.B8992-100000@cactus.fi.uba.ar> In-Reply-To: <20021007170113.5C7EE5D06@ptavv.es.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 7 Oct 2002, Kevin Oberman wrote: > > Obviously I would suggest the man pages (man 4 random). /dev/urandom > will never be exhausted. The numbers returned will simply become > progressively less random. (Random enough for most things, but I always > use /dev/random to make keys.) Yes, it is true that urandom reverts back to a pnrg when the entropy pool gets low. *But* IIRC there is only one entrophy pool in the kernel, so /dev/random will stall until the entropy pool get replenished even if you read from urandom only. I need to read the source to be sure, but better safe than sorry :) This means you can DoS some app which *needs* the randomness and reads from /dev/random just by messing around with /dev/urandom. If both devices have separate entrpy pools, this is not an issue (just remember: dont play with /dev/random unless you know what you're doing) > > Both use truly random, external events to generate the entropy > pool. By default, these are generated fairly slowly and the pool is > easily exhausted. This is because the default is VERY paranoid about > your system. Agreed. Fer To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021007151207.B8992-100000>