[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20171127171303.yze3mljz3mhg433u@voyager>
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.
