bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: $RANDOM not Cryptographically secure pseudorandom number generator


From: Ole Tange
Subject: Re: $RANDOM not Cryptographically secure pseudorandom number generator
Date: Mon, 3 Dec 2018 17:31:18 +0100

On Mon, Dec 3, 2018 at 3:56 PM Chet Ramey <chet.ramey@case.edu> wrote:

> There has to be a compelling reason to change this, especially at a point
> so close to a major release.

The reason for my submission was that I needed a bunch of random
numbers in a shell script, but I needed them to be high quality.
Luckily I did not just assume that Bash delivers high quality random
numbers, but I read the source code, and then found that the quality
was low. I do not think must users would do that.

The man page does not warn about the low quality either, and it does
not point to a way to get high quality numbers. Somehow we expect the
user to simply know this.

So from personal experience I have wasted a few hours on that account.

Had I simply assumed the numbers were high quality, it might have
caused problems for me at a later stage.

And it is protect users who do not read the man page and source code
that I suggest the change.

> You might be expecting too much from bash's random number generator. Is
> the problem that its period is at most 2**16? For its intended uses, the
> cycle length is acceptable. Do you disagree?

If I read the man page, I do not see what the intended use is. Where
is that documented?

If the user's view on the intended use differs from the developers',
then there is a risk of misaligned expectations. Documenting the
developers' view is IMHO a poor way of mitigating this, if there is a
simple solution that will satisfy the demanding user.

I see software daily that is being use in ways it was not intended.
Usually it does not break, and for GNU tools this (in my experience)
is especially true, because the GNU project officially endorses
writing robust programs.

So my suggestion is really just to be proactive, so that when users do
not use it in the intended way, it will still not break.

If you choose not to implement a CSPRNG, then please at least make it
clear in the man page that $RANDOM is a poor RNG, and what the
intended use is.


/Ole



reply via email to

[Prev in Thread] Current Thread [Next in Thread]