The best way to generate random values in multiple threads is to safely split your random generator every time you fork. In the case of mwc-random, it looks like you will want to do something like gen' <- initialize =<< (uniformVector gen 32 :: IO (Vector Word32)) forkIO $ ... gen' ... gen There is no good reason to share RNG state across threads. Just use a separate RNG state for every thread. This is inherently thread-safe and more performant. If you're forking very frequently, you will want to benchmark the effect of using a more efficient vector type (i.e. Vector.Unboxed instead of Vector) or fewer elements during initialization. On Tue, Oct 10, 2017 at 9:06 PM, Kazu Yamamoto wrote:

Hi David,

Thank you for your reply.

...

I've heard good things about *mwc-random* (https://github.com/bos/mwc- random )

Are there any example code to use mwc-random safely from multiple threads?

// Kazu _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

The hash drbg from the drbg package should meet your needs. Deterministic, pure Haskell except the actual hash function. On Oct 10, 2017 8:13 PM, "Viktor Dukhovni" wrote:

...

On Oct 10, 2017, at 8:48 PM, Kazu Yamamoto (山本和彦) wrote:

Before the release, I would like to replace the random package since it is slow. I'm looking for a random library which is - fast - thread-safe (good for concurrent use)

Any recommendations?

Just to make it more interesting, I should mention that the RNG should be not just statistically random, but should in fact be crypto random (resist predictability through cryptanalysis when properly seeded).

So indeed there are two more issues here:

- Securely seeding the RNG (likely using the OS API for random seeds, and/or the RDSEED/RDRAND instructions on Intel CPUs), IIRC we can that from cryptonite, I hope at a reasonable cost.

- Choosing a suitable DRBG based on the seed. Likely again something from cryptonite.

Some time back I posted to the cryptography list about the soundness of relying on RDRAND in cryptonite's RNG (uses it instead of /dev/urandom and the like when available). The rough consensus IIRC was not rely solely on RDRAND. I never went back to write a PR to address that...

http://www.metzdowd.com/pipermail/cryptography/2016- November/thread.html#30859

-- Viktor.

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

Jonathan, The full claim is:

As of 1July2014 this remains the fastest cryptographic RNG on hackage that has been ran against known answer tests.

Many other packaged generators are off-the-cuff inventions of the programmer - IIRC the two designs I saw most were 1. Pick a random IV or counter, generate some data with a block cipher, repeat and 2. Just run a stream cipher like AES-CTR (so, no forward secrecy). The developers are often people who's knowledge I have faith in but the decision is too serious to make such designs lightly. The only package I knew of at the time that tried to implement a standard that included KATs (unit tests) was my DRBG package w/ tests for the Hash generator and HMAC. In this case, the Hash generator is notably faster than HMAC. As for the performance of this and other generators, I did some benchmarking now 4 years ago: http://tommd.github.io/posts/RNG-Bench.html N.B. I intentionally did not discuss security in that post. Many people want a standard, some just don't care about forward secrecy, others won't touch RDRAND with a ten foot pole. All fine, but too many dimensions for me to want to talk about in a blog post. Cheers, Thomas On Tue, Oct 10, 2017 at 8:46 PM, wrote:

All,

Interesting library! Here's a link: http://hackage.haskell.org/package/DRBG-0.5.5/docs/Crypto-Random-DRBG.html

Thomas,

In the linked docs, there's a claim that Hash DRBG is the fastest cryptographically secure RNG on Hackage. Do you have a link to the benchmark results, or perhaps some updated ones? Unlike Viktor, I'm interested in less secure applications, but if the performance is good, it might be worth switching from the defacto random package.

Thanks, Jonathan

On October 10, 2017 10:23:14 PM CDT, Thomas DuBuisson wrote:

...

The hash drbg from the drbg package should meet your needs. Deterministic, pure Haskell except the actual hash function.

On Oct 10, 2017 8:13 PM, "Viktor Dukhovni" wrote:

...

...

On Oct 10, 2017, at 8:48 PM, Kazu Yamamoto (山本和彦) wrote:

Before the release, I would like to replace the random package since it is slow. I'm looking for a random library which is - fast - thread-safe (good for concurrent use)

Any recommendations?

Just to make it more interesting, I should mention that the RNG should be not just statistically random, but should in fact be crypto random (resist predictability through cryptanalysis when properly seeded).

So indeed there are two more issues here:

- Securely seeding the RNG (likely using the OS API for random seeds, and/or the RDSEED/RDRAND instructions on Intel CPUs), IIRC we can that from cryptonite, I hope at a reasonable cost.

- Choosing a suitable DRBG based on the seed. Likely again something from cryptonite.

Some time back I posted to the cryptography list about the soundness of relying on RDRAND in cryptonite's RNG (uses it instead of /dev/urandom and the like when available). The rough consensus IIRC was not rely solely on RDRAND. I never went back to write a PR to address that...

http://www.metzdowd.com/pipermail/cryptography/2016-November/thread.html#308...

-- Viktor.

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

-- Sent from my Android device with K-9 Mail. Please excuse my brevity.

I was looking at this recently; may I ask why drbg and crypto-api even bother to expose the possibility of CSPRNGs "running out" of entropy?

Because most standards discuss this possibility and my decisions at the time were motivated by trying to make those implementations as much of a mindless "translate English to Haskell" job as possible.

This is not thought to be a concern on any cryptographically sound primitive

The primitive's soundness doesn't have anything to do with the period. We can construct a sound cipher with small block size and claim the counter mode of this cipher is a DRBG that is both secure and with a small period.

, and it substantially complicates both the implementation and the user-facing API.

The implementations are not substantially harder. For the users I had begun moving to exceptions with separate `.Pure` and `.Exceptions` modules. The API is all a bit long in the tooth and could stand for me to spend some time on it though.

The currently selected reseed interval of 2^48 is already large enough that it might as well not be there; it's too large to provide forward secrecy

Again, this is unrelated. The instantiated Hash and HMAC DRBGs both have forward secrecy and large intervals.

and almost large enough that you'll never hit it.

Yes! That is the convincing argument right there. The fact that no user actually cares (beyond getting an exception instead of unsafe operation) or will ever hit such a bound is rather important.

Might I suggest in a future revision of the drbg/crypto-api libraries dropping all mentions of "Either" from the CryptoRandomGen typeclass API, except maybe "newGen"? I think this would make your job a lot easier *and* make the library a lot easier to consume (e.g. via RandT).

Well my job is easiest doing nothing. But yes, making it nice for users would be good. I've been meaning to give these packages some more attention and I'll take this as motivation. -Thomas