I&#39;m not too familiar with all the Haskell API&#39;s for RNGs.  This is the first time I&#39;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 &quot;AES&quot; or &quot;crypto&quot; packages can&#39;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">&lt;<a href="mailto:thomas.dubuisson@gmail.com">thomas.dubuisson@gmail.com</a>&gt;</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 &quot;splitGen&quot; [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&#39;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&#39;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&#39;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 &lt;<a href="mailto:rrnewton@gmail.com">rrnewton@gmail.com</a>&gt; wrote:<br>
&gt; Hi cafe,<br>
&gt;<br>
&gt; I want to add the ability to use AES-NI instructions on Intel architectures<br>
&gt; to GHC.  Mainly I&#39;d like to do splittable random number generators based on<br>
&gt; AES as was suggested at the outset of this email.  (I met Burton Smith last<br>
&gt; week and this topic came up.)<br>
&gt;<br>
&gt; I was just reading the below thread about the plugin architecture which got<br>
&gt; me thinking about what the right way to add AES-NI is.  (Disregarding for a<br>
&gt; moment portability and the issue of where to test cpuid...)<br>
&gt;<br>
&gt; <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>
&gt;<br>
&gt; The FFI is always an option.  But after reading the first N pages I could<br>
&gt; come across from google I&#39;m still not totally clear on whether &quot;unsafe&quot;<br>
&gt; foreign calls can happen simultaneously from separate Haskell threads (and<br>
&gt; with sufficiently low overhead for this purpose).<br>
&gt;<br>
&gt; I also ran across the phrase &quot;compiler primitive&quot; somewhere wrt GHC:<br>
&gt;     <a href="http://hackage.haskell.org/trac/ghc/wiki/AddingNewPrimitiveOperations" target="_blank">http://hackage.haskell.org/trac/ghc/wiki/AddingNewPrimitiveOperations</a><br>
&gt;<br>
&gt; Is that the right way to go?  Or would the compiler plugin mechanism<br>
&gt; possibly allowing doing this without modifying mainline GHC?<br>
&gt;<br>
&gt; Thanks,<br>
&gt;   -Ryan<br>
&gt;<br>
&gt; On Fri, Nov 12, 2010 at 6:26 PM, wren ng thornton &lt;<a href="mailto:wren@freegeek.org">wren@freegeek.org</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; On 11/12/10 5:33 AM, Richard Senington wrote:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; It does not give the results you would want. This may have something to<br>
&gt;&gt;&gt; do with picking &quot;good&quot; parameters for the mkLehmerTree function.<br>
&gt;&gt;&gt; For example, using a random setup, I just got these results<br>
&gt;&gt;&gt; result expected range<br>
&gt;&gt;&gt; 16.814 expected = 16.0 (1,31)<br>
&gt;&gt;&gt; 16.191 expected = 16.5 (1,32)<br>
&gt;&gt;&gt; 16.576 expected = 17.0 (1,33)<br>
&gt;&gt;&gt; 17.081 expected = 17.5 (1,34)<br>
&gt;&gt;&gt; 17.543 expected = 18.0 (1,35)<br>
&gt;&gt;<br>
&gt;&gt; Have you run any significance tests? I wouldn&#39;t be surprised to see +/-0.5<br>
&gt;&gt; as within the bounds of expected randomness. I&#39;m more worried about it<br>
&gt;&gt; seeming to be consistently on the -0.5 end of things, than I am about it not<br>
&gt;&gt; matching expectation (how many samples did you take again?). For small<br>
&gt;&gt; ranges like this, a consistent -0.5 (or +0.5) tends to indicate off-by-one<br>
&gt;&gt; errors in the generator.<br>
&gt;&gt;<br>
&gt;&gt; --<br>
&gt;&gt; Live well,<br>
&gt;&gt; ~wren<br>
&gt;&gt; _______________________________________________<br>
&gt;&gt; Haskell-Cafe mailing list<br>
&gt;&gt; <a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
&gt;&gt; <a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
&gt;<br>
&gt;<br>
</div></div>&gt; _______________________________________________<br>
&gt; Glasgow-haskell-users mailing list<br>
&gt; <a href="mailto:Glasgow-haskell-users@haskell.org">Glasgow-haskell-users@haskell.org</a><br>
&gt; <a href="http://www.haskell.org/mailman/listinfo/glasgow-haskell-users" target="_blank">http://www.haskell.org/mailman/listinfo/glasgow-haskell-users</a><br>
&gt;<br>
&gt;<br>
</blockquote></div><br>