On Thu, Jan 02, 2014 at 12:43:04PM -0800, coderman wrote: > 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
Cool! I should also mention there's some annoying but interesting divergence of random devices out there. For example, only a few people have heard of erandom, a "provably secure" entropy harvester... http://www.subspacefield.org/security/security_concepts/#toc-Section-29 It was written by Seth Hardy: http://www.linkedin.com/pub/dir/Seth/Hardy And there's a fast random generator: http://www.billauer.co.il/frandom.html And then OpenBSD has the arandom which is based on arcfour... for TCP seg #'s and such. And so on. As mentioned in a previous post, there needs to be a cross-platform C library so that OpenSSL etc. can access it portably. We'd also need to figure out what kind of software needs what kind of guarantees vis-a-vis "completely unpredictable" vs "computationally unpredictable". As far as I know, most fall into the second camp but anything generating keys (which happens in some network protocols, during keygen, and when using OTPs) falls into the first. I think that's merely icing and should merely inform, not delay, an API. > 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. Agreed. > perhaps a bettercrypto.org like effort specifically for application > developers who need to be proficient users of crypto APIs (not all > devs applied cryptographers ;) Indeed. The OpenSSL crypto API is, in fact, both complex and nearly undocumented, plus there's a recent paper called "The Most Dangerous Code in the World" on validating SSL connections which is pretty interesting. > ideally this would cover openssl, polartls, gnutls, crypto++, > cryptlib, libnss, etc. Yes we have far too many of these, and few comparisons to even choose between the best options, much less actually use them securely. -- http://www.subspacefield.org/~travis/ Remediating... LIKE A BOSS
pgpKh6BixeqiF.pgp
Description: PGP signature
_______________________________________________ RNG mailing list [email protected] http://lists.bitrot.info/mailman/listinfo/rng
