[Haskell-cafe] Splittable random numbers
rrnewton at gmail.com
Sat Jan 22 06:36:43 CET 2011
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?
On Fri, Jan 21, 2011 at 6:11 PM, Thomas DuBuisson <
thomas.dubuisson at gmail.com> wrote:
> If you make an AES based RNG then consider making an instance for
> CryptoRandomGen (see DRBG  for example instances). Such an
> instance means you can use "splitGen" , 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.
> 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.
>  http://hackage.haskell.org/package/DRBG
>  http://hackage.haskell.org/package/cryptocipher
> On Fri, Jan 21, 2011 at 2:19 PM, Ryan Newton <rrnewton at gmail.com> wrote:
> > Hi cafe,
> > I want to add the ability to use AES-NI instructions on Intel
> > to GHC. Mainly I'd like to do splittable random number generators based
> > AES as was suggested at the outset of this email. (I met Burton Smith
> > week and this topic came up.)
> > I was just reading the below thread about the plugin architecture which
> > me thinking about what the right way to add AES-NI is. (Disregarding for
> > moment portability and the issue of where to test cpuid...)
> > 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
> > with sufficiently low overhead for this purpose).
> > I also ran across the phrase "compiler primitive" somewhere wrt GHC:
> > 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 <wren at freegeek.org>
> >> 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
> >> 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
> >> matching expectation (how many samples did you take again?). For small
> >> ranges like this, a consistent -0.5 (or +0.5) tends to indicate
> >> errors in the generator.
> >> --
> >> Live well,
> >> ~wren
> >> _______________________________________________
> >> Haskell-Cafe mailing list
> >> Haskell-Cafe at haskell.org
> >> http://www.haskell.org/mailman/listinfo/haskell-cafe
> > _______________________________________________
> > Glasgow-haskell-users mailing list
> > Glasgow-haskell-users at haskell.org
> > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-Cafe