std.random suggestions

[H. S. Teoh]

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.


> 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).  Being unable
to use seeding means users have to roll their own generators, which
usually means it's done poorly because generating random numbers is not
as simple as it looks.


[...]
> It follows from this that it is necessary to provide only four points
> for obtaining random numbers, all without the need for any combining
> of them by users. (My suggestion is place each of it in dedicated
> std.random.* module)

std.random is not designed for cryptographically-safe random generation.
We neither have the resources nor the expertise to do this.  It should
NOT be used for anything related to authentication, security,
cryptography, or anything similar.  If you need random numbers for any
of these areas, please use a battle-tested library like openssl or one
of the similar variants.  It's unsafe to use anything that wasn't
explicitly designed for security.


> 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.

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, and who has the expertise to actually
understand the issues involved, because when it comes to crypto, rolling
your own is extremely risky and almost certain to fall into unexpected
pitfalls that will greatly weaken the security of your applications.  We
have no such person and no such expertise currently.  Unless a crypto
researcher shows up who has the time and energy to spend in such a
project, I don't think we should go this route.

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?  That's why
these devices are in /dev/ in the first place.


[...]
> 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.


T

-- 
Real men don't take backups. They put their source on a public FTP-server and let the world mirror it. -- Linus Torvalds