Date: Mon, 27 Nov 2017 18:13:03 +0100 From: Markus Wichmann <nullplan@....net> 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. > That's retarded! Sorry, I should contain my vitriol. The fact that rand() is insufficient for cryptohraphic applications should be well known to any programmer attempting to write such a thing. As is the fact that fork() copies your address space (or at least that's the observable effect). It might, of course, be less well known to the programmers actually putting an SSL library into their forking server, but in that case the documentation is insufficient. It would probably be better to not fork, but spawn a thread instead. That way, PRNG state would be shared with the parent and all siblings, meaning that no two threads would generate the same sequence of random numbers. > 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. > It is, and it could not work any other way. The state of all PRNGs is copied upon fork(). The only way to get around this is to reseed the PRNGs in either process after forking. (Or, alternatively, exec()ing in either process will also wipe the PRNG state). A process that needs secure random numbers will have to read from /dev/urandom anyway. > Thanks > Darcy Ciao, Markus
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.