[RFC] Object-scope RNG implementation

What does rng stand for? Is it short for range or acronym of random number
generator?

RFC and implementation updated.

https://wiki.php.net/rfc/object_scope_prng
https://github.com/php/php-src/pull/6568

MT19937 returns a signed 32bit number as a result of the next() method;
the mt_rand() function returns a bit-shifted unsigned 31bit number, so the
results are not identical.

The rng_range() function has been renamed to rng_rand() and returns an
unsigned 31-bit integer like the mt_rand() function if only the $rng
argument is received.

mt_srand(1234);
`mt_rand()` === rng_rand(new \RNG\MT19937(1234)); // true

This allows to completely replace the mt_rand() function with the
RNG\MT19937.

I said I wanted to initiate a vote, but there seems to be too much
discussion missing for that.
I'd like to wait and see for a while.

Regards,
Go Kudo

2021年1月17日(日) 20:02 Go Kudo zeriyoshi@gmail.com:

Updated the RFC and fixed the implementation.
Also made some additions to the RFC about when this feature might be
useful.

RFC: https://wiki.php.net/rfc/object_scope_prng
Implementation PR: https://github.com/php/php-src/pull/6568 (All CI
passed)

The main points are as follows:

• The implementation now meets all requirements. (maybe)
• Implemented MT19937, which is compatible with PHP standard MT. The
  consistency of these is ensured by tests.
• The implementation is now what we used to call TypeII.
• All RNG implementations can now be inherited like regular classes. Use
  faster calls only if the class is an internal class.
• The implementation has been heavily modified and the quality of the
  code
  has been improved.

Currently, there are a few concerns:

• MT19937 returns a signed 32bit number as a result of the next()
  method; the mt_rand() function returns a bit-shifted unsigned 31bit
  number,
  so the results are not identical.
  • You can get the equivalent result with $rng->next() << 1 & PHP_INT_MAX, but maybe you should have a nextUnsigned31() method.
  • Currently, the test uses $rng->next() << 1 & PHP_INT_MAX.
• The implementation of MT19937 is redundant. This can be merged.

Anyway, I think the code is finally ready for review.
Once that is done, we will start voting on RFCs.

Regards,
Go Kudo

Overall I like the proposal. Some notes:

• I know you only just changed it, but I don't think rng_rand() should
  support calling without arguments. This is a backwards-compatibility
  leftover in mt_rand() and we should not carry it over into a new API.

• You should probably mention that the classes can be serialized in the
  RFC. Maybe you want to write out all the methods so it's also visible how
  the constructors for the classes look like.

• Naming: RNG\RNGInterface seems a bit redundant. Of course, we can't make
  it RNG\Interface. RNG\Generator would be an option. I'm not sure about
  this. Maybe RNG\RNGInterface is fine.

• 64-bit: I looked over your implementation, and I think your approach to
  handling 64-bits is correct. You only call next64() if the requested range
  is larger than 32-bit, and that can only happen on 64-bit systems, thus
  guaranteeing consistency of results (where they can be consistent at all).
  What I'm unsure about is the way this gets exposed to userland via next()
  and next64() methods. I think fetching of 64-bit values is mainly
  interesting as an internal optimization, and not so much important to be
  part of the RNGInterface API. The user is intended to get numbers via
  rng_rand(), not by directly calling next(). A possibility here would be to
  drop the RNG64Interface and next64() method, have next() always return
  32-bit, but retain the internal next64 API. For this to make sense, we'd
  need two subsequent internal next() calls to return the same data as a
  single next64() call (i.e. store the result and first return one half then
  the other). Would this make sense to you?

Regards,
Nikita

Hi Alex

First, let me apologize for my poor English skills. It may contain rude
expressions, but it is not s intentional.

The closest library I know and used when I had that need you mentioned is
a userland implementation: https://github.com/paragonie/RandomLib

This seems to be actively maintained, but is a fairly object-oriented-like
implementation.

The library is organized nicely with a Generator class that depends on
constructor of a source for randomness.

This seems to be a more object-oriented implementation.

This RFC also initially proposed an object-oriented implementation, but due
to the redundancy of the implementation and interoperability issues with
existing code, it was changed to a procedural-based implementation. (But it
is not as elegant as this library.)

https://wiki.php.net/rfc/object_scope_prng?rev=1610185985

And perhaps, if we want to provide an object-oriented implementation, it
would be preferable to separate it into a new dedicated module instead of a
standard module. Currently, it is implemented in the standard module for
the convenience of modifying existing functions.

Is this what you envision the whole thing to look like in the end?

final class RandomGenerator
{
    public function __constrct(RandomSourceInterface $source): void {}
    public function randomInt(int $min, int $max): int {}
    public function randomFloat(): float {}
    public function randomBytes(int $size): string {}
    public function randomString(int $size, string $characters): striing {}
    // compatibility for some functions.
    public function arrayShuffle(array &$array): bool {}
    public function stringShuffle(string $string): string {}
    public function arrayRandom(array $array, int $num = 1):
int|string|array {}
}

interface RandomSourceInterface
{
    public function getBytes(int $size): string;
}

class RandomXorShift128PlusSource implements RandomSourceInterface {}
class RandomMT19937Source implements RandomSourceInterface {}
class RandomLibsodiumSource implements RandomSourceInterface {}
class SecureOsSpecificSource implements RandomSourceInterface {}

While this is certainly an appropriate object-oriented implementation, it
raises the following concerns.

• This implementation is much more complex than the PHP built-in random
  number generator implementation.

Probably, many users will continue to use mt_srand() / mt_rand() in the
future. This can lead to dangerous implementations that rely on global
state.
This RFC does not go that far, but we are considering deprecating
mt_srand() and mt_rand() in the future (much further down the road).
In order to achieve this, I believe it is necessary to implement it in a
way that does not compromise usability.

• There are interoperability problems with existing functions.

It is difficult to notice that shuffle(), str_shuffle(), and
array_rand() rely on dangerous internal MT states, and it becomes
difficult to fix them.

I hope this RFC will move forward. Thanks for your input.

Regards,
Go Kudo

2021年1月27日(水) 22:24 Alexandru Pătrănescu drealecs@gmail.com:

RFCs have been reorganized and radically rewritten.
https://wiki.php.net/rfc/object_scope_prng

The implementation is unchanged, but the background has been explained in
more detail and the execution speed has been re-verified with PHP 8.1-dev.

The proposal seems to have been received relatively positively by
externals, but there hasn't been much reaction. I'm unsure when I should
start voting on this RFC.

Regards,
Go Kudo

2021年1月9日(土) 19:00 Go Kudo zeriyoshi@gmail.com:

Hi internals.

I think I'm ready to discuss this RFC.
https://wiki.php.net/rfc/object_scope_prng

Previous internals thread: https://externals.io/message/112525

Now is the time to let me know what you think.

Regards,
Go Kudo

Hi Go Kudo,

The closest library I know and used when I had that need you mentioned is
a userland implementation: https://github.com/paragonie/RandomLib,
created by Anthony Ferrara and not maintained by Paragon Initiative
Enterprises.
The library is organized nicely with a Generator class that depends on
constructor of a source for randomness. The source has just a simple method
to obtain a specific number of bytes and that's all.

I think the naming is what needs more input here. I'm thinking we can also
have:

• a random bytes source/generator that can be very similar with what you
  propose: an interface, multiple internal classes, allowing userland extra
  classes.
• a random generator class that would have multiple useful methods like:
  randomInt($min, $max), randomFloat(), randomBytes($size),
  randomString($size, $possibleCharacters) etc.

As for namings, calling them

• RandomGenerator final class that accepts at constructor a
• RandomSource interface with one method getBytes($size) implemented by
  RandomXorShift128PlusSource, RandomMT19937Source, RandomLibsodiumSource,
  SecureOsSpecificSource etc.
  is a quick idea from me.

State, when is the case, sits in the random source object and can be of
course serialized.

Other than this, initiative looks good.
I apologize if I provided the feedback a bit late.

Regards,
Alex