On 12/04/2014 04:40 AM, Paul Sandoz wrote:
There is already a mechanism to create a cryptographically strong seed by setting a system property and using SecureRandom. That has a high initialization cost, but i think under those circumstances that cost is acceptable (it may well be possible to reduce that cost but i consider that to be a separate issue). For the default case what we need is something with low initialization cost that is *good enough* for the majority of cases e.g. documents the lower bound of cryptographic strength.
Further, in these cases, we are not concerned about cryptographic strength in terms of algorithmic unpredictability by attackers. The default constructor methods promise only to use a seed that is highly likely to differ across invocations, including those of different programs running on different machines. Using initial system seeds that include some environmental entropy is the best way to get the first seed. It just so happens that crypto-based RNGs need to do this as well, so we use the cheapest forms of them that we can (or just use a time based seed on failure). Good-quality PRNG techniques produce more default-constructor seeds after the first one. Because Random, SplittableRandom, and ThreadLocalRandom all use the same basic approach, they can/should use the same mechanism. Placing the mechanics in TLR seems to work out best. In which case only TLR needs a static atomically updated seed initialized from system seed, further reducing static init overhead. I think I've convinced myself that this is the most promising approach, so hope to try it out based on Peter's versions some time in the next few days. Relately, Guy Steele and I have been sporadically investigating minor algorithmic and implementation improvements for SR and TLR (including systematic tests of more than 2500 variants). I suspect that we will settle on one of these sometime in the next few months. (Also, at some point we might reconsider our cowardice about not improving the internal java.util.Random algorithm. j.u.Random is much more commonly used, and does not fare well on quality tests. On the other hand, the more that users instead choose to use SR or TLR, the better.) -Doug
