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