[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKHXTQabRa8sB3-UvM=wEWaoDfnX2eU0Ph4OzObgS6_4SB2vHg@mail.gmail.com>
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.
