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