Bug #123845 for Data-Random-Flexible: eval method for Math::Random::Secure not working

Fri Dec 08 16:15:10 2017 DANAJ [...] cpan.org - Ticket created

Subject:

eval method for Math::Random::Secure not working

Without Math::Random::Secure installed, the module dies since the use statement is bare (it is executed when the module is loaded regardless of the if() around it). A different method for loading this is going to be needed. Doing the require and import while still getting rand() to be exported is not as clear. Since the docs currently say "FAST", I will also point out that Math::Random::Secure's rand is one of the slowest implementations available. $random->int(n) is about 20x slower using that module vs. core rand. Crypt::PRNG, Math::Random::MT::Auto, ntheory, and Math::Random::MTwist could be used without other changes and are much faster (Crypt::PRNG and ntheory both use proper seeding and CSPRNGs -- both ChaCha20 rather than ISAAC though neither algorithm has known issues). All your rand() calls seem to be done as CORE::int(rand( n )), which means you could use an irand() function. Math::Prime::Util::GMP and ntheory both have a urandomm(n) call which does exactly what you want, but for the other modules below you'd have to roll your own. For the small performance benefit you could just use CORE::int(rand(n)) without much penalty (for the modules with that call). Non-crypto: Math::Random::MTwist Math::Random::Xorshift Math::Random::MT::Auto Math::Random::MT Crypto: Math::Random::ISAAC Math::Random::ISAAC::XS Math::Prime::Util::GMP ntheory Bytes::Random::Secure Bytes::Random::Secure::Tiny Crypt::PRNG A downside of Perl / CPAN here -- too many choices.

Sat Dec 09 10:51:01 2017 paul.g.webster [...] googlemail.com - Correspondence added

Subject:	Re: [rt.cpan.org #123845] eval method for Math::Random::Secure not working
Date:	Sat, 9 Dec 2017 15:50:50 +0000
To:	bug-Data-Random-Flexible [...] rt.cpan.org
From:	Paul Webster <paul.g.webster [...] googlemail.com>

Ah I fixed the optional include before spotting this email :) Thank you for the list of altnerative randoms though I will include checks for them on the next version! On 8 December 2017 at 21:15, Dana Jacobsen via RT < bug-Data-Random-Flexible@rt.cpan.org> wrote: Show quoted text

> Fri Dec 08 16:15:10 2017: Request 123845 was acted upon. > Transaction: Ticket created by DANAJ > Queue: Data-Random-Flexible > Subject: eval method for Math::Random::Secure not working > Broken in: 1.01 > Severity: Important > Owner: Nobody > Requestors: DANAJ@cpan.org > Status: new > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=123845 > > > > Without Math::Random::Secure installed, the module dies since the use > statement is bare (it is executed when the module is loaded regardless of > the if() around it). A different method for loading this is going to be > needed. Doing the require and import while still getting rand() to be > exported is not as clear. > > Since the docs currently say "FAST", I will also point out that > Math::Random::Secure's rand is one of the slowest implementations > available. $random->int(n) is about 20x slower using that module vs. core > rand. Crypt::PRNG, Math::Random::MT::Auto, ntheory, and > Math::Random::MTwist could be used without other changes and are much > faster (Crypt::PRNG and ntheory both use proper seeding and CSPRNGs -- both > ChaCha20 rather than ISAAC though neither algorithm has known issues). > > All your rand() calls seem to be done as CORE::int(rand( n )), which means > you could use an irand() function. Math::Prime::Util::GMP and ntheory both > have a urandomm(n) call which does exactly what you want, but for the other > modules below you'd have to roll your own. For the small performance > benefit you could just use CORE::int(rand(n)) without much penalty (for the > modules with that call). > > Non-crypto: > Math::Random::MTwist > Math::Random::Xorshift > Math::Random::MT::Auto > Math::Random::MT > > Crypto: > Math::Random::ISAAC > Math::Random::ISAAC::XS > Math::Prime::Util::GMP > ntheory > Bytes::Random::Secure > Bytes::Random::Secure::Tiny > Crypt::PRNG > > A downside of Perl / CPAN here -- too many choices. >

Sat Dec 09 10:51:02 2017 The RT System itself - Status changed from 'new' to 'open'

Sat Dec 09 16:20:52 2017 paul.g.webster [...] googlemail.com - Correspondence added

Subject:	Re: [rt.cpan.org #123845] eval method for Math::Random::Secure not working
Date:	Sat, 9 Dec 2017 21:20:18 +0000
To:	bug-Data-Random-Flexible [...] rt.cpan.org
From:	Paul Webster <paul.g.webster [...] googlemail.com>

There we go added other engine support :) check version 1.03 On 9 December 2017 at 15:51, Paul Webster via RT < bug-Data-Random-Flexible@rt.cpan.org> wrote: Show quoted text

> Queue: Data-Random-Flexible > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=123845 > > > Ah I fixed the optional include before spotting this email :) > > Thank you for the list of altnerative randoms though I will include checks > for them on the next version! > > > On 8 December 2017 at 21:15, Dana Jacobsen via RT < > bug-Data-Random-Flexible@rt.cpan.org> wrote: >

> > Fri Dec 08 16:15:10 2017: Request 123845 was acted upon. > > Transaction: Ticket created by DANAJ > > Queue: Data-Random-Flexible > > Subject: eval method for Math::Random::Secure not working > > Broken in: 1.01 > > Severity: Important > > Owner: Nobody > > Requestors: DANAJ@cpan.org > > Status: new > > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=123845 > > > > > > > Without Math::Random::Secure installed, the module dies since the use > > statement is bare (it is executed when the module is loaded regardless of > > the if() around it). A different method for loading this is going to be > > needed. Doing the require and import while still getting rand() to be > > exported is not as clear. > > > > Since the docs currently say "FAST", I will also point out that > > Math::Random::Secure's rand is one of the slowest implementations > > available. $random->int(n) is about 20x slower using that module vs.

> core

> > rand. Crypt::PRNG, Math::Random::MT::Auto, ntheory, and > > Math::Random::MTwist could be used without other changes and are much > > faster (Crypt::PRNG and ntheory both use proper seeding and CSPRNGs --

> both

> > ChaCha20 rather than ISAAC though neither algorithm has known issues). > > > > All your rand() calls seem to be done as CORE::int(rand( n )), which

> means

> > you could use an irand() function. Math::Prime::Util::GMP and ntheory

> both

> > have a urandomm(n) call which does exactly what you want, but for the

> other

> > modules below you'd have to roll your own. For the small performance > > benefit you could just use CORE::int(rand(n)) without much penalty (for

> the

> > modules with that call). > > > > Non-crypto: > > Math::Random::MTwist > > Math::Random::Xorshift > > Math::Random::MT::Auto > > Math::Random::MT > > > > Crypto: > > Math::Random::ISAAC > > Math::Random::ISAAC::XS > > Math::Prime::Util::GMP > > ntheory > > Bytes::Random::Secure > > Bytes::Random::Secure::Tiny > > Crypt::PRNG > > > > A downside of Perl / CPAN here -- too many choices. > >

>

Sat Dec 09 16:28:56 2017 daemon [...] cpan.org - Correspondence added

Make that version 1.04 I forgot to update the Makefile to reflect the new module dependencies

Sat Dec 09 16:49:27 2017 daemon [...] cpan.org - Correspondence added

Resolved in version 1.02

Sat Dec 09 16:49:27 2017 daemon [...] cpan.org - Status changed from 'open' to 'resolved'

Sat Dec 09 16:49:27 2017 daemon [...] cpan.org - Taken

Sat Dec 09 16:49:27 2017 daemon [...] cpan.org - Fixed in 1.02 added