[RFC] RNG fixes

Yes, I'm aware of that, and that change isn't an issue for me (except
maybe that it might happen in a minor version). I was responding to
Richard (Fleshgrinder) who suggested to remove rand() and mt_rand()
alltogether, because there is random_int().

I understood how you mean it. :)

Call me ignorant but is this required in typical web applications?
Couldn't we move this functionality to PECL? I mean, it is required in
games but other than that.

Please correct me if that is wrong!

--
Richard "Fleshgrinder" Fussenegger

I think as this is a BC break it should require the 2/3 majority. I do
support fixing the RNGs though.

Have you done any checks on GitHub etc to see how widespread this usage is?
I'd like to get some data on that too.

​I don't have data, but a word of caution: Don't grep legacy crypto
libraries for use of rand() or mt_rand() for key/IV generation if you want
to feel any sense of optimism. Speaking from experience here! ;)​
​

Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises https://paragonie.com/​

I think as this is a BC break it should require the 2/3 majority. I do
support fixing the RNGs though.

Sure if there's a consensus on that, I have no problem with it.

Have you done any checks on GitHub etc to see how widespread this usage is?

I'd like to get some data on that too.

I have checked, but it's really difficult to find legitimate use cases of
srand and mt_srand. I spent some time stacking up "NOT xyz" terms in the
search, and still didn't find anything that actually relied on
deterministic streams of numbers.

Call me ignorant but is this required in typical web applications?

PHP is used for various things, not just web apps. I use it for various
other things because its the language in which I am most fluent.

PHP is and should remain: a pragmatic web-focused language

--- Rasmus Lerdorf

Please do not ignore our mission statement here. PHP is not a general
purpose language and even real general purpose languages do not offer
predictable RNGs.

And the requirements of typical apps using PHP should not be the basis
for removing functions that are in fact used in existing programs.

Moving to PECL is not considered a BC and people are easily able to get
the functions back in if they really need to.

It's possible to change programs so they don't use mt_rand() etc. but
most people won't thank you for forcing them to rewrite software that
works.

The applications and libraries who are using it incorrectly right now
will thank us for making it harder to use the language incorrectly.

Leigh, iiuc, is trying to fix bugs. Let's not change the discussion to
cleaning up PHP's API.

This is not what my proposal is about. I would move all the broken and
weak stuff to PECL and offer the already existing good alternatives to
the developers. At the same time we are able to fix the problems in the
PECL modules and release a new major version of those packages.

We do not need to fix password_hash() nor random_int() since they work
and they are what is needed in a web-focused language.

--
Richard "Fleshgrinder" Fussenegger

I don't know, but I can image that it is (test suites come to mind). Of
course, it might be an option to move the functionality to PECL, but on
the other hand, what would we gain? For users, however, that might be a
major pain; consider software which runs on shared hosting.

https://github.com/sebastianbergmann/phpunit/pull/1408#issuecomment-53163159

rand() will not work for them. ;)

And then there is https://packagist.org/packages/leigh/mt-rand as Leight
just pointed out.

I am sorry but this topic is clear as a crystal.

--
Richard "Fleshgrinder" Fussenegger

Can someone explain why I should need 'crypto safe' random numbers when
ALL I use rand for is to give a random order to content items on the
page. Something more in sync with the shuffle and array_rand without the
need to recode to actually use the array functions, or simply select an
entry at random from a list.

There are actually only two properties of an RNG that are of interest to
you and that is resource consumption and performance since you do not
rely on predictable sequences, a certain amount of randomness, nor
portability.

mt_rand() provided by PHP is the best choice here right now:

rand = https://3v4l.org/nIIdb/perf#tabs
mt_rand = https://3v4l.org/Wb3ZA/perf#tabs
random_int = https://3v4l.org/5SZHW/perf#tabs

But notice how super tiny the difference from random_int() to the others
is. Being a use'n'forget for almost all purposes (predictable sequences
is the only use case it does not cover). Especially note that
random_int() is pretty much as fast as rand() itself!

This led me to my initial question: why do we have so many random
functions in the first place?

Historical? Yes!

Needed?

--
Richard "Fleshgrinder" Fussenegger

Can someone explain why I should need 'crypto safe' random numbers when
ALL I use rand for is to give a random order to content items on the
page.

I cannot.

Something more in sync with the shuffle and array_rand without the
need to recode to actually use the array functions, or simply select an
entry at random from a list.

Similarly, when I randomize the time before a daemon next wakes up, I
don't think random_int() is appropriate. mt_rand() is entirely suitable.
And upgrading to a more efficient RNG like PCG would be daft.

Tom

Hi!

https://news.ycombinator.com/item?id=9941364

I am sorry, what this link is supposed to illustrate? That if one
doesn't read the docs and uses mt_rand wrong they'd get exactly what it
is supposed to do? Ok, true, and?

The PHP approach seems to be that any crazy behavior is acceptable
as long as it's documented.

This is an obviously false statement, so obviously that I am confused
about the purpose which could drive you to quote it. Unless it claims
that this is not actual approach but just "seems" to be to some person
on the internet. In which case I wonder why should I care about
obviously false impression of some person on the internet.

There is plenty more of this stuff to be found on the Internet and
the

There's plenty of any stuff found on the Internet. So what? If I fancied
to read only "PHP sucks" articles every day, I could probably occupy
myself full-time for months without reading any of them twice. 90% of it
is hair-splitting and "I didn't read the manual and it's your fault"
kind of stuff, 10% of it are real issues. Which are known to us and none
of them requires removal of functions and syntax.

only thing I want to show is that it is faulty. It is not broken,
yes, but faulty and hard to use right for many people out there. This
is

No, it's not hard to use for most people out there. In fact, it is
extremely easy to use to most people out there, which is easily proven
by people actually using it in millions.

usually reason enough to react and try to do better.

Nobody argues with doing better. But "let's remove this function
altogether because it has a corner case" is not doing better, that's
exactly my point.

Why is it faulty? Well, it has many weird edge cases that people need
to learn about. Reading the manual is however not something people
actually do and this results in constant education being necessary.
The question is, why can't we fix that? The answer here seems to be:
because of legacy support. You are saying yourself that nobody is
upgrading anyways

If you want to create a random function that would not require knowing
anything about randomness and how to use random functions, and still be
crypto-strong, and will have no corner cases at all, you will fail. If
you want to create a random function that would not have that particular
corner case, you will succeed easily. So what? It will have different
corner cases. The fact that some guy wrote on HN about this corner case
and didn't write about another one changes nothing.

We can and should have better random functions. It is not the reason to
remove ones that work. Even if they have corner cases which people once
talked about on HN.

Not within 7.x because that would be a serious BC within a non-major
version. Of course we would remove rand() in 8.0 in favor of
mt_rand() or a better alternative if readily available within the
versions of PHP that were releases before 8.0.

So all the code that uses *rand() is broken, and we have nobody that
uses that code upgrading to 8.0 until they have a budget to rewrite and
re-test and re-audit all their code, which is probably sometime in the
next 20 years. And at the price of that we achieved... what
exactly? We certainly didn't help people that used rand() - they are now
using unsupported PHP version with all bugs and security issues and
can't upgrade. We didn't help people starting new development - they
don't need rand() removed, they can just use new stuff.
But now we can go back to that HN thread and say "looks at us, we have
no cruft anymore!" Big achievement unlocked?

The users that do not wish to upgrade just won't upgrade. Making
them jump through hoops just to have what they already have makes
no sense.

If they don't upgrade, they don't mind it being removed. ;)

True. But we want them to upgrade. And needlessly removing stuff
prevents that.

Yes, cruft is a generic term: https://en.wikipedia.org/wiki/Cruft

Generic and thus meaningless in the specific context, without
qualification at least. It's just a pejorative. "It needs to be removed
because it's bad". It's not argument for removal, it's just
restating the same.

It specifically contains "redundant" which is more than appropriate
to the current discussion since we have two random functions that do
literally the same but one worse than the other.

It doesn't have to be worse.

No since most (mt_)rand() calls are broken crypto crap. Just go out
and

That is based on what? I certainly have seen a lot of rand usage having
little to nothing to do with cryptography.

search for yourself like I did. It is pretty much impossible to find
any other usage ... Not saying that there are not legitimate usages
of any of those functions but they are super rare.

I found three usages within 5 minutes having nothing to do with crypto:

https://github.com/zendframework/zf1/blob/210190dab599e2897220648c9040bce9ff76f21f/library/Zend/Captcha/Image.php#L407
https://github.com/zendframework/zf1/blob/210190dab599e2897220648c9040bce9ff76f21f/library/Zend/Amf/Value/Messaging/AbstractMessage.php#L82
https://github.com/zendframework/zend-cache/blob/bb8a75c62d3e1c75b8d8bc53f8b2db98314d3a17/src/Storage/Plugin/OptimizeByFactor.php#L42

That's not the meaning of "impossible" I'm used to.

The very fact that you claim rand is not used by anything but crypto
suggests to me that you are overfocusing on one issue - which is a real
issue, no doubt about it - of using non-crypto-strong randomness in
crypto context and ignoring other aspects where randomness is in play.
Solving your problem neither requires removing mt_rand nor is achieved
by it. The solution would be better crypto API and education about which
randomness to use in which context.

It is hard to judge whether the hidden BCs that are silently being
introduced by some RFCs are more harmful than a proper deprecate and
remove approach with proper version numbers. I would argue that the
last approach is better, at least other programming languages have
more success with it (Java).

Java pretty much never removes APIs. And I don't remember any instance
of Java syntax being removed. See for example:

https://www.quora.com/Has-Sun-or-Oracle-ever-removed-a-deprecated-Java-method-in-an-official-API/
Oracle people say they consider to maybe remove some com.sun.*
internal APIs that aren't even part of official documented API. From
what I know, these considerations are still just talk. Somehow they are
not worried about articles on HN and nobody wanting to use Java because
they have "cruft".
Also, Java never generates runtime messages on deprecated items.

PHP has a bad reputation among the industry especially in
Europe/Germany because of "the various complains that we all know of
and are already fed up with". This (mt_)rand() situation is just a
super tiny part of the whole.

PHP has millions of users and servers, including in Europe, including in
Germany. So whoever considers it beneath them because it has mt_rand can
use whatever language they see fit, but I am not very impressed by the
argument that somehow PHP is in a huge crisis and removing stuff that
works somehow is going to help solve it.

Stas Malyshev
smalyshev@gmail.com

My favorite:

The PHP approach seems to be that any crazy behavior is acceptable as
long as it's documented.

People love raggin' on PHP.

It's a virulent meme. It propagates so well in our coder culture because
it's easy, it's just provocative enough to attract attention but it's
pretty safe because you can always find people to agree with you.
Participants can feel smart and superior even if their contribution
amounts to "me too".

It's like people raggin' on C++. "They named the language after the
worst feature in C: pointer arithmetic!" Knowingly superior chuckles. I
wonder how many of the people who pile on (propagating the meme) have
the understanding of real experience. My own history with C++ was short
but so miserable that I sometimes join in with this one.

Same thing with Perl. Before that it was COBOL. Raggin' on COBOL is
legit even if you've no idea what COBOL code looks like.

It's a form social behavior for establishing groups and belonging. It
works by using people's need for a sense of identity and validation.
Computer people at a party can use these memes as small-talk to develop
relations, either friendly or not. Our modern comms platforms'
gamification literally rewards this behavior.

But once you're aware of it, it's like American stand-up comics raggin'
on New Jersey. Usually good for a cheap laugh but in reality it's tired
out, past its due date, old, utterly unimaginative, very, very boring,
and, in the Frankfurtian sense[1], bullshit.

There. I finally said it. I've wanted to get it off my chest for years.
I apologize that I rely too much on America vernacular and culture. And
for totally hijacking Leigh's RFC thread.

Richard, nothing internals could do will stop PHP being the butt of
these dreary jokes and insults. And there are more effective ways to
push your agenda. Please consider using them.

Tom

[1] https://en.wikipedia.org/wiki/On_Bullshit

Maybe we could do some name brain storming?

I would strongly recommend instead of that, sending fewer emails to
this list, with each email containing well thought through ideas.

Throwing out random ideas into this mailing list does not seem to lead
to a productive outcome. Other mediums, like IRC, chat-rooms, forums,
and even Reddit, seem better suited at pulling ideas together into a
coherent proposal to be discussed.

cheers
Dan

Hi,

I already wrote this message once, but it seems to have evaporated into
the ether. So apologies if it reappears and this is revealed as a poor
duplicate of it!

I think the push to remove "cruft" would make more sense if the
replacements were less obviously "cruft" in their own right. If I have
to polyfill pcg_rand() on old servers and mt_rand() on new ones, I'd be
tempted to just implement wtfbbq_rand() and have done with it, because
the names, and even the algorithms they represent, are pretty
meaningless to me.

As with libsodium, I think we should avoid replacing one set of
overly-specific implementations with another, and saying "this time
we've got it right". Instead, we should look at what people actually
want the functions for, and hide the implementation as much as
possible.

For instance, for reproducible (seedable) random sequences, how about a
function random_int_sequence($seed, $min, $max) which returns a
generator, so you could write "$user_seq =
random_int_sequence($user_seed, 0, 10); $user_pick = $user_seq();" Or
maybe it could return a closure, or an object - either way, something to
replace the global state of (mt_)srand.

Perhaps a random_int_fast() function with big warnings that it's not to
be trusted for crypto, but performs really well if all you're doing is
picking which image banner to show on your home page.

Use whatever RNG you want under the hood, make a declaration of whether
or not it's stable cross-platform and cross-version, and give users an
actual reason to change their code. Then consider other use cases: a
better uniqid(), shuffling, maybe built-in UUID support...

Then, IF the new APIs become popular, we can come back to talking about
removing rand() and mt_rand(), because we'll have replaced them with
something substantially better, not just another variant on the same
thing.

Regards,

Yes, yes, yes! :)

I would still like to deprecate rand() but probably leave it to Nikic
because people actually listen to him. ;)

I haven't been following this thread, just jumping in to comment on this
point. My suggestion to deprecate rand() was motivated by the fact that
rand() produces extremely low quality random numbers on Windows, while at
the same time having the name people are most likely to try first if they
want to have a random number. It's a bad state of things if there's a
rand() and an mt_rand() function and the latter is preferable in all
situations, while the former is more likely to be used. However, this
concern is completely alleviated by aliasing rand() to mt_rand(). If we do
this, I see no reason to deprecate rand(), at least in the short term.

Btw, I fully support this RFC.

Nikita

@Tom Worster: I will not answer to any other message in this thread
today but I think we are essentially on the same page regarding PCG and
its suitability for PHP, it just needs time to mature. I think we also
agree regarding the MT situation.

However, I think that it makes sense to tackle the problem that people
use mt_rand() incorrectly and Rowan's proposal here matches the last
proposal I made: it's just even better and he is as always much better
in summing things up. :)

Maybe we could do some name brain storming?

1. random_int_sequence()
2. random_int_fast()
3. random_int_seedable()
4. random_pseudo_int()
5. pseudorandom_int()
6. random_deterministic_int()
7. deterministic_random_int()
8. ????

[1] Somehow unclear what sequence means here if you just want to
randomly pick an entry from an array.

[2] This might still suggest to people that they can use it for crypto,
just faster. I really like it but I don't think its perfect.

[3] Sounds nice to me.

[4] What is a pseudo int?

[5] Would create a new prefix and probably not show up in some code
completions together with the other random functions. :( Other than that
it would describe it best.

[6] Long but to the point.

[7] Again too long and it creates a shitty new prefix.

The signature is clear in my opinion and exactly as Rowan had it:

prng(int $seed, ?int $min = 0, ?int $max = PHP_INT_MAX): int;

--
Richard "Fleshgrinder" Fussenegger