Re: [RFC] [Discussion] PHP 8.3 deprecations

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