public inbox for gsl-discuss@sourceware.org
 help / color / mirror / Atom feed
From: "Robert G. Brown" <rgb@phy.duke.edu>
To: Jonathan Leto <jaleto@gmail.com>
Cc: GSL Discussion list <gsl-discuss@sources.redhat.com>
Subject: Re: New rngs...
Date: Wed, 14 Oct 2009 16:59:00 -0000	[thread overview]
Message-ID: <alpine.LFD.2.00.0910141247080.3513@lilith> (raw)
In-Reply-To: <9aaadf9c0910140912q7532fd82n9317b6e735dbc2ca@mail.gmail.com>

[-- 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


  reply	other threads:[~2009-10-14 16:59 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-08 13:46 Robert G. Brown
2009-10-14 16:12 ` Jonathan Leto
2009-10-14 16:59   ` Robert G. Brown [this message]
2009-10-23 21:28   ` Brian Gough

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.LFD.2.00.0910141247080.3513@lilith \
    --to=rgb@phy.duke.edu \
    --cc=gsl-discuss@sources.redhat.com \
    --cc=jaleto@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).