New rngs...

New rngs...

[Robert G. Brown]

Dear Brian et. al.

As we're discussing the roadmap for a new GSL, I'd like to offer up at
least two, maybe three more random number generators for inclusion in
the GSL list that have been contributed and integrated into dieharder.
One that I think should absolutely be there is rng_aes -- basically an
implementation of AES as a random number generator.  AES is
cryptographic grade random and is arguably very close to a "gold
standard" that can be used to test random number generator testers, as
there is always an unstated addition to the null hypothesis "Assuming
that this is a perfect random number generator AND that this is a valid
test...", and failure of the latter is very difficult to discriminate
from failure of the former without at least a few generators for which
failure of the former is arguably less likely than failure of the
latter.  rng_threefish does the same thing on top of many rounds of
skein.  I was using aespipe to feed dieharder in a pipe until these were
contributed, but having them integrated is worthwhile, especially given
that rng_aes is respectably fast, around 1/5 the speed of mt19937.

    rgb

Robert G. Brown	                       http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567  Fax: 919-660-2525     email:rgb@phy.duke.edu

Re: New rngs...

[Jonathan Leto]

Howdy,

I would very much like to see these RNGs added to GSL, so that I can
add them to Math::GSL and access them from Perl. I am willing to work
on integrating these into GSL, as long as the GSL maintainers want
this to be done. Should I continue in this direction?


Cheers,


[0] http://search.cpan.org/dist/Math-GSL/

On Thu, Oct 8, 2009 at 6:46 AM, Robert G. Brown <rgb@phy.duke.edu> wrote:
> Dear Brian et. al.
>
> As we're discussing the roadmap for a new GSL, I'd like to offer up at
> least two, maybe three more random number generators for inclusion in
> the GSL list that have been contributed and integrated into dieharder.
> One that I think should absolutely be there is rng_aes -- basically an
> implementation of AES as a random number generator.  AES is
> cryptographic grade random and is arguably very close to a "gold
> standard" that can be used to test random number generator testers, as
> there is always an unstated addition to the null hypothesis "Assuming
> that this is a perfect random number generator AND that this is a valid
> test...", and failure of the latter is very difficult to discriminate
> from failure of the former without at least a few generators for which
> failure of the former is arguably less likely than failure of the
> latter.  rng_threefish does the same thing on top of many rounds of
> skein.  I was using aespipe to feed dieharder in a pipe until these were
> contributed, but having them integrated is worthwhile, especially given
> that rng_aes is respectably fast, around 1/5 the speed of mt19937.
>
>   rgb
>
> Robert G. Brown                        http://www.phy.duke.edu/~rgb/
> Duke University Dept. of Physics, Box 90305
> Durham, N.C. 27708-0305
> Phone: 1-919-660-2567  Fax: 919-660-2525     email:rgb@phy.duke.edu
>
>
>



-- 

Jonathan Leto
jonathan@leto.net
http://leto.net

Re: New rngs...

[Robert G. Brown]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 4079 bytes --]

On Wed, 14 Oct 2009, Jonathan Leto wrote:

> Howdy,
>
> I would very much like to see these RNGs added to GSL, so that I can
> add them to Math::GSL and access them from Perl. I am willing to work
> on integrating these into GSL, as long as the GSL maintainers want
> this to be done. Should I continue in this direction?

You're welcome to do so by me -- dieharder is all GPL code, and they're
already in GSL wrappers.  rng_aes could just be dropped in.
rng_threefish has an annoying endian dependence that is "ugly" code from
Gladman's website but that I think I can simplify with an endian test in
configure.ac (I don't know if this is already tested for in gsl's build
-- I'd guess that it is).  You can grab rng_aes right now from:

   http://www.phy.duke.edu/~rgb/dieharder-3.29.3beta.tgz

and should be able to splice it right in (drop it into the rng source
directory, add the include/dieharder/rijndael-alg-fst.h stuff to e.g.
gsl/gsl_rng.h, make sure it is added to the list of supported rngs which
IIRC isn't yet automagic).  As soon as it shows up in the GSL I'll drop
it from dieharder per se and rely on the GSL copy.

I'd hold off on threefish for a little longer, until I resolves some
build issues in dieharder and perhaps combine its includes into a
single/smaller set.

Note well that in neither case are the rngs "encryption subroutines"; a
separate issue is whether or not to add an integrated e.g. "gsl_crypt()"
function that could be used to encrypt data via GSL calls using one of a
set of well-known crypt routines (aes, des, Nfish, etc).  If GSL goes in
this direction, then the aes rng should probably be split into an actual
aes encryption routine similar to what was in the old libaes or aespipe
(wrapped in GSL function form) plus a thinner rng shell that calls the
same basic routine.  This would give GSL "instant" internal access to
all its supported crypt routines as rngs for testing purposes, which
would actually be very convenient to people seeking to certify crypt
quality algorithms via e.g. STS (as dieharder implements more and more
of STS).

I'd be happy to help out with some parts of the implementation and
maintenance and of course with the testing of the results.

    rgb

>
>
> Cheers,
>
>
> [0] http://search.cpan.org/dist/Math-GSL/
>
> On Thu, Oct 8, 2009 at 6:46 AM, Robert G. Brown <rgb@phy.duke.edu> wrote:
>> Dear Brian et. al.
>>
>> As we're discussing the roadmap for a new GSL, I'd like to offer up at
>> least two, maybe three more random number generators for inclusion in
>> the GSL list that have been contributed and integrated into dieharder.
>> One that I think should absolutely be there is rng_aes -- basically an
>> implementation of AES as a random number generator.  AES is
>> cryptographic grade random and is arguably very close to a "gold
>> standard" that can be used to test random number generator testers, as
>> there is always an unstated addition to the null hypothesis "Assuming
>> that this is a perfect random number generator AND that this is a valid
>> test...", and failure of the latter is very difficult to discriminate
>> from failure of the former without at least a few generators for which
>> failure of the former is arguably less likely than failure of the
>> latter.  rng_threefish does the same thing on top of many rounds of
>> skein.  I was using aespipe to feed dieharder in a pipe until these were
>> contributed, but having them integrated is worthwhile, especially given
>> that rng_aes is respectably fast, around 1/5 the speed of mt19937.
>>
>>   rgb
>>
>> Robert G. Brown                        http://www.phy.duke.edu/~rgb/
>> Duke University Dept. of Physics, Box 90305
>> Durham, N.C. 27708-0305
>> Phone: 1-919-660-2567  Fax: 919-660-2525     email:rgb@phy.duke.edu
>>
>>
>>
>
>
>
> -- 
>
> Jonathan Leto
> jonathan@leto.net
> http://leto.net
>

Robert G. Brown	                       http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567  Fax: 919-660-2525     email:rgb@phy.duke.edu

Re: New rngs...

[Brian Gough]

At Wed, 14 Oct 2009 09:12:09 -0700,
Jonathan Leto wrote:
> I would very much like to see these RNGs added to GSL, so that I can
> add them to Math::GSL and access them from Perl. I am willing to work
> on integrating these into GSL, as long as the GSL maintainers want
> this to be done. Should I continue in this direction?

Yes, it would be useful to have a cryptographically based rng, so
please go ahead both of you.  I don't think we want to provide
anything more than the actual random numbers though, so just a minimal
implementation would be best.  I would say we only need one, to be
representative of this class of generator - AES would be ideal.

-- 
Brian Gough