8020292: j.u.SplittableRandom

[Paul Sandoz]

[resending unsigned, sorry if a dup arrives later on]

On Aug 19, 2013, at 9:04 PM, Mike Duigou <mike.duigou at oracle.com> wrote:

> Looks pretty good. Two points concern me:
> 
> - Every source of non-crypto quality randoms should explicitly document that it should not be used for generating keys or other crypto purposes. There is mention that the seeding is insecure in the implementation docs but more explicit mention in the public docs is needed. (And some fool somewhere will *still* use it for crypto...)
> 

Good point.


> - Additional seed material might be desirable for "seeder". I worry about how many of the actual bits are random. If no local host address is available the seed might be fairly predictable. In the murmur3 implementation I included also System.identityHashCode(String.class), System.identityHashCode(System.class), System.identityHashCode(Thread.currentThread()), Thread.currentThread().getId() and Runtime.getRuntime().freeMemory(). Mixing multiply with XOR operations also helps to spread the random bits out. Perhaps just call mix64 on each component and XOR against previous?
> 

Are you concerned that the values passed to mix64 may be of low entropy? i.e. that small differences in input (such as counting numbers) do not result in large enough differences in the output. I suppose it might be possible to switch from MurmurHash3 to using Stafford's "Mix13" constants or a combination to avoid any potential correlations. However, given that there is further mixing going on for the values and gamma generation perhaps it is not so important?

Paul.