bug-bash
[Top][All Lists]
Advanced

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

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


From: Rawiri Blundell
Subject: Re: [bug-bash] $RANDOM not Cryptographically secure pseudorandom number generator
Date: Mon, 21 Jan 2019 14:07:51 +1300

On Mon, Jan 21, 2019 at 1:36 PM Eduardo A. Bustamante López
<dualbus@gmail.com> wrote:
>
> On Sun, Jan 20, 2019 at 05:22:12PM -0500, Chet Ramey wrote:
> > On 1/20/19 4:54 PM, Chet Ramey wrote:
> >
> > >> 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,
> (...)
> > So I ran a quick test.
> >
> > $ ./bash ./x3
> > iterations: 1000000
> > BASH_VERSION: 5.0.2(4)-maint
> > time: 9.684
> > $ ../bash-5.0/bash ./x3
> > iterations: 1000000
> > BASH_VERSION: 5.0.0(1)-release
> > time: 9.749
> > $ ../bash-5.0-patched/bash ./x3
> > iterations: 1000000
> > BASH_VERSION: 5.0.2(3)-release
> > time: 9.840
> > $ ../bash-4.4-patched/bash ./x3
> > iterations: 1000000
> > BASH_VERSION: 4.4.23(7)-release
> > time: 11.365
> > $ ../bash-4.4-patched/bash ./x3
> > iterations: 1000000
> > BASH_VERSION: 4.4.23(7)-release
> > time: 11.235
> > jenna.local(1)
> >
> > Where the script is Eduardo's iterator that just expands $RANDOM
> > N times.
> >
> > The random number generator has been the same since bash-4.0.
>
> I'm sorry, my tests were wrong. I built bash using the default `./configure'
> behavior for the `devel' branch, which I always forget, uses the internal
> allocator with debugging enabled, and thus, all of my times were off due to 
> the
> additional malloc overhead.
>
> I rebuilt it with `../bash/configure --without-bash-malloc', which causes it 
> to
> use the system's allocator, and surely enough, the timings make more sense 
> now:
>
> (`build-bash-devel-malloc' is `configure --with-bash-malloc',
>  `build-bash-devel' is `configure --without-bash-malloc')
>
> | dualbus@system76-pc:~/src/gnu/build-bash-devel-malloc$ ./bash 
> ~/test-speed.sh
> | iterations: 1000000
> | BASH_VERSION: 5.0.0(1)-maint
> | time: 8.765
> |
> | dualbus@system76-pc:~/src/gnu/build-bash-devel-malloc$ 
> ../build-bash-devel/bash ~/test-speed.sh
> | iterations: 1000000
> | BASH_VERSION: 5.0.0(1)-maint
> | time: 3.431
> |
> | dualbus@system76-pc:~/src/gnu/build-bash-devel-malloc$ bash ~/test-speed.sh
> | iterations: 1000000
> | BASH_VERSION: 5.0.0(1)-release
> | time: 3.435
> |
> | dualbus@system76-pc:~/src/gnu/build-bash-4.4$ ./bash ~/test-speed.sh
> | iterations: 1000000
> | BASH_VERSION: 4.4.0(1)-release
> | time: 3.443

Hi,
Perfect timing - I was just about to reply to Chet's earlier message
with the following finding:

*snip*

On Mon, Jan 21, 2019 at 11:22 AM Chet Ramey <chet.ramey@case.edu> wrote:
>
> On 1/20/19 4:54 PM, Chet Ramey wrote:
>
> So I ran a quick test.
>
> [results removed for brevity]

That's interesting.  For comparison here's what I'm seeing:

▓▒░$ ~/bin/bash5/bash /tmp/randtest   # Downloaded and compiled as-is
iterations: 1000000
BASH_VERSION: 5.0.0(1)-release
time: 7.210
▓▒░$ ~/bin/bash5lcg/bash /tmp/randtest # With all the RANDOM related
code reverted to the 4.4 code
iterations: 1000000
BASH_VERSION: 5.0.0(2)-release
time: 7.271
▓▒░$ ~/bin/bash5chacha/bash /tmp/randtest # With Ole's chacha patch
iterations: 1000000
BASH_VERSION: 5.0.0(1)-release
time: 7.443
▓▒░$ /bin/bash /tmp/randtest # Distro provided package, wait a minute...
iterations: 1000000
BASH_VERSION: 4.4.19(1)-release
time: 5.610

I hadn't thought of the pre-compiled package vs source compiled
difference until just now.  So I figured that while I'd downloaded
4.4's source to double check variables.c, I may as well compile and
test it:

▓▒░$ ~/bin/bash44/bash /tmp/randtest
iterations: 1000000
BASH_VERSION: 4.4.0(1)-release
time: 7.432

So in the best tradition of n=1 science, it looks like the difference
may be down to compilation choices?  Can anyone else replicate this?

*/snip*

So it looks like problem solved?

Rawiri



reply via email to

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