[Haskell-cafe] Splittable random numbers

[Thomas DuBuisson]

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 <rrnewton at 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 <wren at 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 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
>
>