[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, 7 Jan 2019 10:10:23 +0100 |
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