Date: Mon, 27 Nov 2017 18:34:28 -0500 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Subject: Re: AES_CTR_DRBG / random numbers On Mon, Nov 27, 2017 at 11:39:00AM -0500, Darcy Parker wrote: > Hi, > > Have musl developers considered AES_CTR_DRBG like glibc project has? > > I learned about it from > https://aws.amazon.com/blogs/opensource/better-random-number-generation-for-openssl-libc-and-linux-mainline/. > My understanding of it is limited, but enough to be concerned about claimed > risk of how fork() may copy memory used by an initialized random number > generator. It looks like s2n and linux have or will adopt AES_CTR_DRBG. > My concern is other software that may depend on libc's rand() rather than > implement their own secure pseudo random number generator. > > I appreciate musl for its reputation of correctness and performance. And > although I saw glibc is moving to it, a quick set of searches with Google > didn't uncover discussion about AES_CTR_DRBG being implemented in musl. > > Is musl's pseudo random number generator methods vulnerable in the same way > glibc is? My hope is that it is not vulnerable, but if it is, I'd like to > know musl developers are already on top of this. rand() is fundamentally not usable for cryptographic purposes or anything where even moderately high-quality pseudorandom sequences are needed, since it is fundamentally only capable of producing 2^32 possible sequences (one for each seed). There are not any cryptographic random number APIs in musl, but the proposed posix_random and/or arc4random are under consideration. If one is chosen, a secure backend algorithm will of course be used. Most of the hype about this topic is a matter of choosing fast ones while minimizing the security tradeoffs; otherwise unless you intentionally choose some backdoored rube-goldberg-esque one, there's not a lot to worry about. The fork() topic is also over-hyped. Switching to a new security context after fork() without exec*() is fundamentally a security bug; it leaks all sorts of potentially-sensitive information beyond just csPRNG state. Modern design is to exec after forking (or preferably, use posix_spawn instead of fork+exec to avoid this issue, get much better performance, and be compatible with targets without fork). Ensuring that the fork child gets a new csPRNG sequence distinct from the parent's is just a one-line change to the fork function; it does not need the fancy kernel help (madvise stuff). This also serves to reduce the likelihood that child will get access to sensitive state. But ensuring that no state that could be used to partly or fully recover the csPRNG state leaks to the child is essentially impossible without assistance at all stages of the toolchain and runtime. Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.