On Thu, Jan 2, 2014 at 10:29 AM, <[email protected]> wrote: > ... > As suggested by the FreeBSD 10 response of feeding all HWRNG into > Yarrow, as a BCP, should defensively written code whiten all RNG > sources? IOW, should we establish new trust boundaries and where?
i've been wondering about this as well. some things come to mind: 1) we should promote OS entropy sources (/dev/random, /dev/urandom), as this is the "best solution". it avoids issues with fork() safety in internal application pools, has better protections, etc. the latest Linux random() improved on random pool integrity in summer 2013. see http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/char/random.c#n1021 2) we should promote hardware entropy sources with access to raw samples. Intel should release an RDRAW mode, and every other processor vendor who doesn't have one, should include a physical entropy source. 3) perhaps a "best practice random" library is needed for applications. it would keep a thread-specific-storage pool, mix multiple sources into it, combine with OS entropy where available, and then finally mix and fold before use. this way, even if the OS or framework entropy is horribly broken, you've got a source that is much more resilient in application. perhaps a bettercrypto.org like effort specifically for application developers who need to be proficient users of crypto APIs (not all devs applied cryptographers ;) ideally this would cover openssl, polartls, gnutls, crypto++, cryptlib, libnss, etc. _______________________________________________ RNG mailing list [email protected] http://lists.bitrot.info/mailman/listinfo/rng
