[RFC] [VOTE] Vote open for reliable user-land CSPRNG

Hi Matteo,

Disclaimer: I do know a little about security, but I am not a crypto-expert
by any means. If I'm saying something silly, just let me know ;)

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.

Were folk to use random_int() by default, it would be actually be
considerably better than the situation today where many reach for
mt_rand() without really considering the use case. Using a strong
source of ints instead of a weak source still ends up with you getting
the requested ints. There's no downside unless the source is blocking.
Using the weak source over a strong source will also get you ints, but
without knowing the use, it has the immediate downside risk of being
from a weak source which shouldn't be used for anything requiring
strong randomness.

So random_int() really is the best first default option to go for when
in doubt, with some careful consideration before switching to
mt_rand().

As for exhausting the entropy pool, this is something of a
misconception. The sources in the RFC are pseudorandom generators
which won't exhaust the entropy pool by design.

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

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?

In essence, this is what the functions are already providing an
interface to: systems which take a truly random seed and output
pseudorandom values. The difference is that the underlying system is
designed to be cryptographically secure (for most uses). mt_rand(), on
the other hand, is not.

Paddy

--
Pádraic Brady

http://blog.astrumfutura.com
http://www.survivethedeepend.com

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.

A two week discussion period has been held for the reliable user-land
CSPRNG RFC to add random_bytes() and random_int(). The RFC has now
been
moved into voting.

https://wiki.php.net/rfc/easy_userland_csprng

There was some discussion of prefixing the function names with
crypto_*()
but there are a few reasons we decided against this:

1. There is a crypto pecl extension, so the pseudo-namespace might cause
   confusion.
2. We want to work on a fully featured crypto framework for 7.1, and
   crypto_* is a good prefix for that, so again, we don't want to mix things
   up.

[...]

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 problem is that when using mt_rand - even if you seeded it with a
cryptographic random number - you will be able to predict all future random
numbers based on the first few. The tiny 32bit seed space can be easily
brute forced. MT also allows directly recovering the full internal state
from the output, though that requires a relatively large amount of values
(624 if not truncated) and as such isn't practical for the Poker case.

Nikita

Hi!

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

After reading http://www.2uo.de/myths-about-urandom/, I have hard time
seeing how "exhausting entropy pool" would be a real problem.I mean, if
running PRNG for "too long" is dangerous, wouldn't we already have much
more serious problem with encryption routines based on them which
basically do it all the time? Maybe I don't understand the crypto
theory under this enough, in which case it may be interesting to read
something that explains how that happens and what is the actual problem
there.

Stas Malyshev
smalyshev@gmail.com

Hi all,

Voting has now closed on this RFC. The feature has been accepted for PHP 7
with votes of 41 - 0.

Thanks to all who participated in the discussion and gave feedback.

Regards,

Leigh.