Hi
On 5/29/23 17:41, Nikita Popov wrote:
I don't think we should deprecate mt_rand().
There are plenty of use-cases that require neither a seedable (predictable) RNG
sequence, nor a cryptographically-secure RNG. For those use-cases (and
especially one-off uses), mt_rand() is perfect, and going through Randomizer is
an entirely unnecessary complication.
I think I could get on board with deprecating srand/mt_srand to make
rand/mt_rand non-seedable, directing people who need a seedable RNG to use
Randomizer, which is much better suited to that use-case. However, we should
retain rand/mt_rand themselves for non-seeded use-cases.
I disagree. One of the arguments that I made in favor of the removal is
basically that "defaults" matter:
Developers should be steered to the secure-by-default choice (i.e. the
CSPRNG), unless they have specific performance or reproduction
requirements. I believe the current API trio of rand(), mt_rand() and
random_int() fails at that, because rand() is the "most convenient"
function. The function name is short and it appears in a plethora of
existing tutorials.
The CSPRNG should be sufficiently fast for the vast majority of use
cases. My i5-2430M with Linux 5.4 can handle 1 million random_int(1,
100) calls in a second, with mt_rand(1, 100) taking 0.25 seconds for 1
million calls.
The PHP 8.2 OO API very intentionally defaults the \Random\Randomizer to
the Secure engine for that reason and this recommendation is also part
of the documentation I wrote for ext/random:
https://www.php.net/manual/en/class.random-engine-secure.php
The Random\Engine\Secure engine is the recommended safe default choice, unless
the application requires either reproducible sequences or very high performance.
https://www.php.net/manual/en/class.random-engine.php
The Random\Engine\Secure engine that is backed by a CSPRNG is the recommended
safe default choice, unless the application requires either reproducible
sequences or very high performance.
-
With srand/mt_srand removed, we also would not have to produce any particular
sequence, and would be free to switch the internal RNG to something other than
Mt19937.
In addition to the above reasoning, rand() and mt_rand() are also
functions with an overloaded signature which are problematic as per:
https://wiki.php.net/rfc/deprecate_functions_with_overloaded_signatures
Switching them to a different engine would not do anything about the
overloaded signature.
--------
I believe making a clean cut is preferable to each of the following:
1. Not changing anything.
2. Taking away seeding (and backing them by a different non-CSPRNG).
3. Making them effectively aliases to random_int().
However I also don't see a strong need for a removal in PHP 9. I am also
happy with removing them with PHP 10 at the very earliest to give folks
plenty of runway to migrate to something else on their preferred pace,
as long as they are not introduced in any new code without proper
consideration of their downsides.
Best regards
Tim Düsterhus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
