Appears it is indeed threadsafe. 100 threads, 1000 bytes per thread gives the results below. The histogram of nibbles from the random stream seems fairly well distributed. Note that this doesn't check as thoroughly as http://csrc.nist.gov/groups/ST/toolkit/rng/stats_tests.html but work for our needs for now.
Quick and dirty test code at https://github.com/sidshetye/BouncyRngThreadSafety ---------------------------------------- HISTOGRAM Nibble BinCnt Delta from expected 0 12468 0.02 % ========= 1 12555 0.03 % ================ 2 12577 0.04 % ======================= 3 12428 0.04 % ===================== 4 12488 0.01 % ==== 5 12463 0.02 % =========== 6 12463 0.02 % =========== 7 12364 0.07 % ======================================== 8 12487 0.01 % ==== 9 12570 0.04 % ===================== A 12485 0.01 % ==== B 12390 0.06 % ================================ C 12584 0.04 % ========================= D 12554 0.03 % ================ E 12570 0.04 % ===================== F 12554 0.03 % ================ Expected bin count is 12500 Bin standard deviation is 66.9449400627112 Test PASSED Press any key to continue or hit escape to quit ... From: Sid Shetye [mailto:sid...@outlook.com] Sent: Monday, June 23, 2014 10:09 PM To: 'Bouncy Castle Developer List' Subject: [dev-crypto-csharp] Is the SecureRandom class thread safe? Within the BouncyCastle.Security namespace, there lives the SecureRandom class. Is it thread-safe in its crypto-random assurances? i.e. If I had 100 threads drawing random bytes out of a single instance of that class (created for example via SecureRandom.GetInstance("SHA256PRNG")) would it actually pull random bytes in an overall crypto-random manner? Or will it trip over and (example) keep supplying the same "random" byte to multiple threads due to lack of thread safety? If yes but this behavior was recently changed, would appreciate that tip too! Thanks
