std.random suggestions

[Denis Feklushkin]

On Tuesday, 16 September 2025 at 15:06:39 UTC, H. S. Teoh wrote:
> On Tue, Sep 16, 2025 at 12:04:20PM +0000, Denis Feklushkin via 
> Digitalmars-d wrote:
>> I don't like the way the module std.random is designed
> [...]
>> I think if we save users from deepening into details this will 
>> only go to the benefit of security. So, my suggestion:
>> 
>> 1. Do not provide any access about entropy sources (I am about 
>> std.internal.entropy.EntropySource.tryAll and 
>> forceEntropySource).
> [...]
>
> Users are not supposed to use anything from std.internal.  It's 
> named "internal" for a reason.

Yes. But I saw that this function is public out and the fact that 
it even exists is strange.

>> 2. Completely exclude "seeding" concept: this is a source of 
>> potential
>> issues
>> (https://github.com/dlang/phobos/pull/10865/commits/3c2f87ef745ca6de6e392007421af81e661aecbe).
>> Seeding can be encapsulated inside of of urandom generator 
>> (see 2
>> above) if needed.
>
> Seeding is useful for Monte Carlo simulations where you need 
> pseudorandom numbers in large quantity, but completely 
> reproducible from a seed value (e.g. for verification of 
> certain results).

Sugggested `std.random.predetermined` exactly for this purpose

At the moment I see that `unpredictableSeed` used for seeding 
returns 32 bits by default and called everywhere. 128 or 256 bits 
is more preferable. I am convinced that this occurs because we 
did not provide a simple function that returns just an array of 
random bytes. More precisely, we hid its name behind this "Seed" 
name

> std.random is not designed for cryptographically-safe random 
> generation.

It is in vain!

> We neither have the resources nor the expertise to do this.

We need just a copy bytes from TRNG to our arrays or ranges. This 
is not looks unsafe.

>> 1. std.random.truerandom: implemented as OS/hardware call if 
>> system provides hardware (or environmental) random number 
>> generator. Suitable for encryption key generation, etc. Maybe 
>> three functions will be provided, something like:
>
> There's no need for this.  You could just open /dev/random or 
> /dev/urandom as a file yourself, and read whatever you need 
> from it. It's OS-dependent anyway, so there's no need to add 
> another layer of abstraction to pretend that you're portable.

But in fact, this has already been implemented in 
`unpredictableSeed`

> The problem with offering a crypto-level RNG in the standard 
> library is that you need an active maintainer who's keeping on 
> top of the latest security weaknesses and updates,

All of this is already implemented in the operating systems we 
use - we just need to use the appropriate APIs.

> Or if what you're really asking for is an API to /dev/random or 
> /dev/urandom, then why not just open them as files yourself?

Because I do not want to research this for MacOS during 
developing on Linux. Usula all I want is 8-16 random bytes 
obtained in the way recommended by the target system.

> That's why these devices are in /dev/ in the first place.

Also /dev/* can be unavailable at load stages, getrandom is 
recommended way on Linux

>
> [...]
>> 3. std.random.pseudorandom.pseudoRandom: not for cryptography 
>> at all. Name was specifically chosen so that the user would 
>> clearly see the "pseudo" prefix.
> [...]
>
> What's currently in std.random falls in this category. Wouldn't 
> be a bad idea to rename it this way.  Good idea.

Thanks