Edward, compressibility as a PRNG test isn't that reliable. It can weed out really bad PRNGs but RNGs need to protect against predictability.
For example: compressibility would pass for the previously circulated digest RNG with same seed code but its a horrible failure from a RNGs perspective. For your CBCrypt requirement, instead to imposing a new weakening requirement on RNGs (repeatability), why won't you use digests as the primitive construct? RNG repeatability should be a valid requirement only in test mode (e.g. An 'internal' method to re/set seed), not production. Peter, does BC 2.0 implement all of NIST 800-22 RNG checks? I've often wondered and wanted to ask - good opportunity to do so. Any pointers to where in the src? (on the road right now) Regards Sid On Jul 30, 2014, at 4:11 AM, "Edward Ned Harvey (bouncycastle)" <bouncycas...@nedharvey.com> wrote: >> From: Peter Dettman [mailto:peter.dett...@bouncycastle.org] >> >> Hi Edward, >> Thankyou for your informative comments (and to others for contributing >> their thoughts). I do think there is room for improvement in the BC RNG >> code, particularly around entropy-collection. > > Good info all around, thanks - I do have a few questions for you. > > First of all, given that BC is C# and java, my first question is, how closely > in-sync do they need to remain? I am a C# developer, and I haven't done java > in 10 years. Given the unfortunate direction oracle is taking java, I plan > to leave it in my past. > > I have a checkout of the C# code, from https://github.com/bcgit/bc-csharp > If I want to contribute, should I fork it, modify, and submit pull request? > Or should I branch and push to my own branch? (I think I would require > permission on the repo side.) > > To improve security, the very first thing I would like to add is: The > default master instance of SecureRandom should pull from > CryptoApiRandomGenerator, in addition to ThreadedSeedGenerator. And > SetSeed(GetSeed(8)) is obviously insufficient and trivially easy to improve, > and it would be very smart to periodically feed some more seed material into > the PRNG, but that would be a significant deviation from (and improvement > over) the java implementation. So is it ok to deviate from the java > implementation significantly? Not talking about changing the API. Just > improving the implementation. > > I haven't looked at the test code. I assume it would be trivial to add the > trivial compression test to detect compressible output coming out of > ThreadedSeedGenerator. But as demonstrated in this discussion thread, the > results vary according to which platform runs the test. So adding the test > code might be basically pointless, depending on how the tests are run on > which platforms. So my question is: How are the tests run, and on which > platforms? > > I would be very happy to also contribute ThreadSchedulerRandomGenerator (in > tinhat random, it's EntropySources.ThreadSchedulerRNG) and let the default > SecureRandom seed from it too. >
