Re: [bug-bash] $RANDOM not Cryptographically secure pseudorandom number generator

[Rawiri Blundell]

> OK, this is a reasonable approach. Since /dev/urandom just generates
> random bytes, there's a lot of flexibility and we're not subject to
> any kind of backwards compatibility constraints, especially not the
> 16-bit limit. What do you think would be the best way to present that
> to a user? As a 32-bit random number? A character string you can use to
> create filenames? Some other form?

Hi Chet, et al,
I really like this suggestion.  All recent variants of /dev/urandom
are using something like ChaCha20, Yarrow or Fortuna, and older
implementations will still be reasonably secure - using something like
Yarrow, Yarrow-like or arc4.  Ole's concerns should be well covered by
this approach.

Having said that, there appear to be some gotchas, as covered here:

* 
https://stackoverflow.com/questions/2572366/how-to-use-dev-random-or-urandom-in-c
* 
http://insanecoding.blogspot.com/2014/05/a-good-idea-with-bad-usage-devurandom.html

So it might be a case of restricting the usability of this change to
newer kernels that have dedicated calls like getrandom() or
getentropy(), and having to handle detecting/selecting those?

So if this is an exercise that you're happy to entertain, and without
wanting to feature-creep too much, why not something like this?

* $RANDOM = exactly as it is (or with an improved RNG... probably a
separate discussion now)
* $RANDINT = 32 bit integer from RANDOM's RNG i.e. this is seed-able
* $OS_RANDINT = 32 bit random integer from /dev/urandom
* $OS_RANDSTR = random character string from /dev/urandom

I suggest OS_ because it's less typing than, say, SECURE_ or SYSTEM_,
vaguely conveys the source of randomness and it might have some
familiarity with other languages. Python's os.urandom comes to mind.
SYS_ might be a good alternative, too.

Certain characters such as '!' may need to be omitted from
OS_RANDSTR's output, possibly that's a worthwhile thing to keep in
mind?

As an aside, I can confirm the findings of a performance difference
between 4.4 and 5.0 when running the script provided earlier in the
discussion. At first glance it seems to be due to the switch from the
old LCG to the current MINSTD RNG, but I've compiled 5.0 with the old
LCG code and on my hardware that performs roughly the same as the
MINSTD RNG and Ole's ChaCha20 patch. So I thought it might be
something to do with how loops are handled, but testing other tasks
shows no great difference there between 4.4 and 5.0. That's as far as
I got.

Cheers

Rawiri