Re: [RFC] [VOTE] Vote open for reliable user-land CSPRNG
| From: | Leigh | Date: | Sun, 15 Mar 2015 20:09:36 +0000 |
| Subject: | Re: [RFC] [VOTE] Vote open for reliable user-land CSPRNG | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-84895@lists.php.net to get a copy of this message | ||
On 15 March 2015 at 10:29, Matteo Beccati <php@beccati.com> wrote:
>
> I want to vote yes, but naming is something that scares me a bit. Without
> any indication that it's CSPRNG, people might start using it even when
> unnecessary, and I'd be worried about potential negative effects, such as
> exhausting the entropy pool. It's probably more of a documentation problem,
> but we know many won't read the docs and a "hint" in the function name
> could help guiding users.
>
I wouldn't worry about exhausting the entropy pool, on systems like Linux
there is kind of a feedback system where data is mixed back into the pool
when you request data. You can pipe /dev/urandom into /dev/null for hours
and not suffer any problems.
> For example, it would be overkill to use random_int() to randomly pick the
> content of a boxes at each reload of a web page, but if what I need is a
> *random int*, then random_int() seems a far better choice than some obscure
> rand() or mt_rand().
>
Of course it would, but that's something that needs to be done through
education and via the manual. I understand the concern, but I'm not sure
how much I'll worry about it.
Or in the poker deck example, wouldn't it be enough just to seed mt_srand
> with a crypto-secure number to remove the biasing and using mt_rand to
> shuffle the deck?
>
The biasing comes from how the result is restricted to a certain range of
numbers, it's not related to the quality of the seed. We avoid that by
throwing away numbers that would give a biased result, and picking a new
number.
The poker deck example isn't a brilliant one, because the effects of
biasing become more apparent the closer you get to the maximum upper bound,
but it's still important to cater for the unlikely-but-possible scenarios.