Ken Moffat wrote:
Reading the Release Notes for nss-3.31 (most of which goes way over
my head) I noticed one item in the Notable Changes:
NSS supports a clean seeding mechanism for *NIX systems now using
only /dev/urandom. This is used only when SEED_ONLY_DEV_URANDOM is
set at compile time.
Should we use that, or is there some reason not to ?
I wasn't aware that nss-3.31 has been released. It got confused with the
unrelated ticket #9345.
Doing 'grep -r SEED_ONLY *' on the source only yields two hits:
lib/freebl/freebl_base.gypi: 'SEED_ONLY_DEV_URANDOM',
lib/freebl/sysrand.c:#if (defined(XP_UNIX) || defined(XP_BEOS)) &&
defined(SEED_ONLY_DEV_URANDOM)
Aside: I really dislike packages that do not include their release
notes/NEWS in their source tarballs.
Google sez:
"/dev/random should be suitable for uses that need very high quality
randomness such as one-time pad or key generation. When the entropy pool
is empty, reads from /dev/random will block until additional environmental
noise is gathered. A read from the /dev/urandom device will not block
waiting for more entropy."
What sysrand.c does is include either "unix_urandom.c" or "unix_rand.c".
Personally I don't think we should worry about the difference. The best I
can tell, the need for random numbers in nss is only needed when creating
a certificate. Using urandom seems to merely sacrifice randomness for speed.
-- Bruce
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
