Re: $RANDOM not Cryptographically secure pseudorandom number generator

[Ole Tange]

On Mon, Jan 7, 2019 at 9:37 AM Eduardo A. Bustamante López
<dualbus@gmail.com> wrote:
> On Mon, Jan 07, 2019 at 08:15:12AM +0100, Ole Tange wrote:
> > On Mon, Jan 7, 2019 at 12:08 AM Chet Ramey <chet.ramey@case.edu> wrote:
> > > On 1/5/19 3:12 PM, Eduardo A. Bustamante López wrote:
> > > > On Fri, Dec 28, 2018 at 10:24:50AM +0100, Ole Tange wrote:
> > > > (...)
> > > >> Patch attached.
> > :
> > > > - What is the performance impact (roughly 2X slower)
> >
> > The impact is not from Salsa20/ChaCha20, though, if you compare
> > patched vs. unpatched code.
> >
> > On my system BASH_RANDOM_16 is a tiny bit faster than the original,
> > while BASH_RANDOM_32 is a tiny bit slower.
>
> I find that really hard to believe. The new RNG is clearly doing more work, so
> it should be slower.

It does more work, yes, but it also produces more numbers and the work
it does is simpler: When it does 20 rounds it produces 16 or 32
numbers. The calculations in each round are parallelizable and are
mostly bit shifting. https://en.wikipedia.org/wiki/Salsa20 says it
uses 3.95 cpu cycles per byte. Given that the old version did 1
division, 1 modulo, and 2 multiplications, I would say it is not
unreasonable that they are comparable in speed.

> And that's OK. I just wanted to know by how much.
>
> What numbers are you seeing and how did you measure them?

I ran your test script on 3 versions:

* the original source. Git [3669b0bacc6]
* the patched source with BASH_RANDOM_32
* the patched source with BASH_RANDOM_16

and the results were within 1% of each other.

(I can, however, reproduce your finding that $RANDOM is twice as slow
on 5.0 as on 4.4, but it is not due to the generator).


/Ole