Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83820
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.53 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <D1138D6D.5DCE0%fsb@thefsb.org>
References: <D1138D6D.5DCE0%fsb@thefsb.org>
Date: Wed, 25 Feb 2015 15:22:30 -0500
Message-ID: <CAAyV7nHGSPAFW28U2YRLQqYnPDP5s-Yy6PLHkbKmPkAnugiK4w@mail.gmail.com>
To: Tom Worster <fsb@thefsb.org>
Cc: php-internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] [RFC] [DISCUSSION] Reliable user-land CSPRNG
From: ircmaxell@gmail.com (Anthony Ferrara)

Tom,

On Wed, Feb 25, 2015 at 2:39 PM, Tom Worster <fsb@thefsb.org> wrote:
> I welcome the proposal for an easy-to-use PHP function for obtaining
> crypto-secure randomness. I have a number of comments and suggestions.
>
> I think the function name(s) should indicate that these functions are
> for getting crypto-secure randomness. I proposed cs_random_bytes()
> previously (https://wiki.php.net/rfc/csrandombytes) and I still it
> works. First, it's important that users understand this distinction.
> Second, given all the shared environments, it's good for the world at
> large if people aren't draining the operating system's "entropy pool"
> for work that doesn't need crypto-secure randomness, e.g. Monte Carlo
> simulations that are better served with a different source.
>
> CS random strings are often required but I haven't ever seen
> requirements for arbitrary alphabets, charsets and encodings. In Yii
> we provided a method that returns a string using the 64-character set
> [a-zA-Z0-9_-] which is nice because they are all transparent in URLs.
> There are many uses for such strings and it seems to meet the needs of
> most users, as they haven't requested more flexibility.
>
> I don't understand the requirement for crypto-secure random integers.
> I have never encountered this requirement. [Btw: the proposed patch
> implements this function using a loop that's not guaranteed to
> terminate in any given amount of time.]
>
> I believe that simplicity is of *paramount importance*. I also believe
> in only addressing the requirements of 90% of the users if addressing
> the 10% specialists means complicating the API and adding potential
> footguns.
>
> For example, the number of users that actually need to do something
> better than read from /dev/urandom is small. A user that is concerned
> about the status of the system's "entropy pool" (whatever that might
> mean) or that feels the need to check the "degree of seededness"
> of the system's CSPRNG (again, whatever that might mean) is a very
> specialized user. There's no need to cater to them in these "Reliable,
> userfriendly RNG APIs". The (metaphorical) 1% can look after
> themselves. Whatever its size, it's a small minority that genuinely
> cannot accept the kind of randomness that /dev/urandom on Linux or
> /dev/random on FreeBSD or OS X offer.
>
> Further, the concepts of seededness of an RNG are very advanced
> matters that are not well understood and that vary from one system to
> another. Standardizing these semantics across platforms is hard. So
> making these complications portable over different operating systems
> is, I imagine, beyond difficult.
>
> And if you aim to make an API that exposes such subtleties, you need
> to be able to clearly explain in the manual what it means in both
> technically accurate terms and in practical terms that a non-
> specialist application developer can base a design decision on. I
> certainly couldn't do that.
>
> To, to summarize.
>
> - The requirement for a easy-to-use function to obtain crypto-secure
>   randomness is very clear. Has been for years in my view.

Agree 100%.

> - Name the functions so the crypto-secure feature is obvious, e.g.
>   cs_random_bytes()

I'm less sure on this point. I think people will get confused "what's
the difference between mt_rand and cs_random?" and then just use
rand() anyway.

I think the way we solve this is though documentation instead. Keep
the name simple, and document it well...

> - The functions should not expose or allow selection of degrees of
>   "strength" of crypto-secureness (it's both a footgun and a semantic
>   tar pit). Just use the non-blocking system source and make a note in
>   the manual so the specialist users know what's going on.

Agree 100%

> - A function to get a random text string drawn from the 64-byte
>   alphabet of URL-transparent chars is very useful.
>
> - Don't complicate the random string getter without first establishing
>   the requirement for such complication.
>
> - Don't offer a crypto-secure random integer getter unless the
>   requirement for such a thing is clear.

Well, there are cases such as UUID generation, contests, etc which
need to pick numbers in a defined range.

Also, if it's a drop-in replacement for mt_rand, so existing could
could be migrated without having to be rewritten (a bonus for legacy
users).

Anthony