Date: Mon, 27 Nov 2017 12:25:23 -0500 From: Darcy Parker <darcyparker@...il.com> To: musl@...ts.openwall.com Subject: Re: AES_CTR_DRBG / random numbers Thanks - that's what I wanted to hear. Sorry for the retarded question... I wrote this as a user and not a developer who knows about these things. When I read in the article that glibc was changing their PRNG, it raised alarms of what else (other than SSL) could be vulnerable. I accept that if a developer didn't know it is a documentation problem. Maybe its not as big a deal for libc implementations as it sounded in that article. On Mon, Nov 27, 2017 at 12:13 PM, Markus Wichmann <nullplan@....net> wrote: > 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 > Content of type "text/html" skipped
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.