I'm not too familiar with all the Haskell API's for RNGs. This is the first time I've looked at CryptoRandomGen, but I can see the benefit of having a bytestring interface rather than the System.Random Int based one.
Is there a reason that the AES implementation in the "AES" or "crypto" packages can't be ripped out and repackage in the way you would like? Cheers, -Ryan On Fri, Jan 21, 2011 at 6:11 PM, Thomas DuBuisson < thomas.dubuis...@gmail.com> wrote: > Ryan, > If you make an AES based RNG then consider making an instance for > CryptoRandomGen (see DRBG [1] for example instances). Such an > instance means you can use "splitGen" [2], which can split generators > in the manner described in this thread. If you make the RNG match > NIST SP 800-90 then feel free to send it to me for inclusion in the > DRBG package, I've been meaning to make the block cipher based DRBG > for a while now. > > Finally, any implementation of AES (using NI or not) could probably go > in its own package or a cipher-specific package like CryptoCipher[3]. > Its a shame we don't have an AES implementation on Hackage that 1) > exposes the fundamental block interface instead of some higher-level > wrapping and 2) isn't tied to a large library. > > Cheers, > Thomas > > [1] http://hackage.haskell.org/package/DRBG > and > > http://hackage.haskell.org/packages/archive/DRBG/0.1.2/doc/html/src/Crypto-Random-DRBG.html#HmacDRBG > [2] > http://hackage.haskell.org/packages/archive/crypto-api/0.3.1/doc/html/Crypto-Random.html#v:splitGen > [3] http://hackage.haskell.org/package/cryptocipher > > > On Fri, Jan 21, 2011 at 2:19 PM, Ryan Newton <rrnew...@gmail.com> wrote: > > Hi cafe, > > > > I want to add the ability to use AES-NI instructions on Intel > architectures > > to GHC. Mainly I'd like to do splittable random number generators based > on > > AES as was suggested at the outset of this email. (I met Burton Smith > last > > week and this topic came up.) > > > > I was just reading the below thread about the plugin architecture which > got > > me thinking about what the right way to add AES-NI is. (Disregarding for > a > > moment portability and the issue of where to test cpuid...) > > > > > http://www.haskell.org/pipermail/glasgow-haskell-users/2011-January/019874.html > > > > The FFI is always an option. But after reading the first N pages I could > > come across from google I'm still not totally clear on whether "unsafe" > > foreign calls can happen simultaneously from separate Haskell threads > (and > > with sufficiently low overhead for this purpose). > > > > I also ran across the phrase "compiler primitive" somewhere wrt GHC: > > > http://hackage.haskell.org/trac/ghc/wiki/AddingNewPrimitiveOperations > > > > Is that the right way to go? Or would the compiler plugin mechanism > > possibly allowing doing this without modifying mainline GHC? > > > > Thanks, > > -Ryan > > > > On Fri, Nov 12, 2010 at 6:26 PM, wren ng thornton <w...@freegeek.org> > wrote: > >> > >> On 11/12/10 5:33 AM, Richard Senington wrote: > >>> > >>> It does not give the results you would want. This may have something to > >>> do with picking "good" parameters for the mkLehmerTree function. > >>> For example, using a random setup, I just got these results > >>> result expected range > >>> 16.814 expected = 16.0 (1,31) > >>> 16.191 expected = 16.5 (1,32) > >>> 16.576 expected = 17.0 (1,33) > >>> 17.081 expected = 17.5 (1,34) > >>> 17.543 expected = 18.0 (1,35) > >> > >> Have you run any significance tests? I wouldn't be surprised to see > +/-0.5 > >> as within the bounds of expected randomness. I'm more worried about it > >> seeming to be consistently on the -0.5 end of things, than I am about it > not > >> matching expectation (how many samples did you take again?). For small > >> ranges like this, a consistent -0.5 (or +0.5) tends to indicate > off-by-one > >> errors in the generator. > >> > >> -- > >> Live well, > >> ~wren > >> _______________________________________________ > >> Haskell-Cafe mailing list > >> Haskell-Cafe@haskell.org > >> http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > > > _______________________________________________ > > Glasgow-haskell-users mailing list > > glasgow-haskell-us...@haskell.org > > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > > > >
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe