Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 27 Nov 2017 20:51:36 +0100
From: Szabolcs Nagy <>
Subject: Re: AES_CTR_DRBG / random numbers

* Darcy Parker <> [2017-11-27 11:39:00 -0500]:
> I learned about it from
> 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

leaks across fork were discussed in 2014 (when libressl was developed)

it's unreasonable to expect a security boundary between
parent and forked child without leaks into the child.
use exec in the child to get better isolation or avoid
sensitive state in the parent. (i think this should be
the goal)

it's unreasonable to expect library authors to fix up
their code using non-standard apis to correctly mark
all sensitive state. (i think this should not be the goal)

i don't think it's the job of a tls library to make library
use across fork safe, it cannot do that since the boundary
that needs protection can be huge and a library has no
business interfering with application level concerns
(maybe the fork semantics was used on purpose).

otoh there is a real practical security issue here and
the implemented madvise flag is a solution for it (but
i think it aims for the wrong goal and thus not a good
long term solution for the ecosystem).

> 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.

libc prng is another discussion: rand() has well defined semantics
that openbsd currently observably breaks in the name of security.
i don't think this is good behaviour: it breaks existing software
and changes user expectations in unrealistic ways.

libc has several prng apis, none of them are particularly well
designed, and certainly not for cryptographic use, if really
that's what users want then the standard should at least allow
that (currently it does not).

musl currently provides as good prng as possible given the
constraints of the apis.

what musl does not provide is a cprng, adding arc4random
(non-standard but existing practice) or waiting for the api
proposed for posix were discussed earlier as well as adding
getrandom syscall wrapper, maybe these can be considered

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.