[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20171127233428.GY1627@brightrain.aerifal.cx>
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.
