random_seed()

Just to know, can we have a random_seed() for random_int()/random_bytes()
like we have mt_srand() to mt_rand()?

I don't know if random_int() is more "random" than mt_rand(), but if it is,
so maybe is valid a random_seed() function.

--
David Rodrigues

Just to know, can we have a random_seed() for random_int()/random_bytes()
like we have mt_srand() to mt_rand()?

I don't know if random_int() is more "random" than mt_rand(), but if it is,
so maybe is valid a random_seed() function.

--
David Rodrigues

Hello,

random_bytes/random_int use proper random generation source - /dev/urandom
in most cases (and appropriate source on windows) - that's the whole point
why they were introduced. There is no need for seeds nor it can even be
initialized with a seed.
They are, as far as I understand, cryptographically safe random generators.

I suggest reading up on the subject, the RFC and the whole thing. Their
introduction was well covered by various core devs in blog posts.

Good afternoon,

fully correct. Seeds are not needed anymore.

best,

On Mon, Apr 1, 2019, 12:44 PM Arvids Godjuks arvids.godjuks@gmail.com
wrote:

Just to know, can we have a random_seed() for random_int()/random_bytes()
like we have mt_srand() to mt_rand()?

I don't know if random_int() is more "random" than mt_rand(), but if it
is,
so maybe is valid a random_seed() function.

--
David Rodrigues

Hello,

random_bytes/random_int use proper random generation source - /dev/urandom
in most cases (and appropriate source on windows) - that's the whole point
why they were introduced. There is no need for seeds nor it can even be
initialized with a seed.
They are, as far as I understand, cryptographically safe random generators.

I suggest reading up on the subject, the RFC and the whole thing. Their
introduction was well covered by various core devs in blog posts.

Seeds could even be dangerous here, as these numbers are supposed to be
cryptographically secure. If you need a seedable PRNG for testing, just use
rand().

Ben

Good afternoon,

fully correct. Seeds are not needed anymore.

best,

On Mon, Apr 1, 2019, 12:44 PM Arvids Godjuks arvids.godjuks@gmail.com
wrote:

On Mon, Apr 1, 2019, 05:52 David Rodrigues david.proweb@gmail.com
wrote:

Just to know, can we have a random_seed() for
random_int()/random_bytes()
like we have mt_srand() to mt_rand()?

I don't know if random_int() is more "random" than mt_rand(), but if it
is,
so maybe is valid a random_seed() function.

--
David Rodrigues

Hello,

random_bytes/random_int use proper random generation source -
/dev/urandom
in most cases (and appropriate source on windows) - that's the whole
point
why they were introduced. There is no need for seeds nor it can even be
initialized with a seed.
They are, as far as I understand, cryptographically safe random
generators.

I suggest reading up on the subject, the RFC and the whole thing. Their
introduction was well covered by various core devs in blog posts.

Hi,

Seeds could even be dangerous here, as these numbers are supposed to be
cryptographically secure. If you need a seedable PRNG for testing, just use
rand().

Not only it could be dangerous, it would beat the entire purpose of
random_bytes()/random_int(). Just to clarify for readers not familiar
with the topic:

Seed-based RNGs are deterministic.
deterministic === predictable
predictable === not secure

Whether you want to seed for testing purposes, or someone has beaten
it into you to use random_*() instead of (mt_)rand() and now your code
doesn't work the same way, you're likely blindly following best
practices without consideration. Not everything is 100% testable and
not every problem can have the same solution.

If you need to generate secure tokens of some kind - use random_bytes().
If you need to generate unpredictable random numbers - use random_int().
Don't worry about testing either of those.
If you need seed-based, reproducible outcomes - use mt_rand(), that's
perfectly fine for e.g. re-creating the same "random" map layout in a
video game - a valid use case; but it's not for security.

Cheers,
Andrey.