8020292: j.u.SplittableRandom

[Mike Duigou]

On Aug 20 2013, at 04:57 , Paul Sandoz wrote:

> [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?

It was more that "seeder" is initialized with a potentially predictable value. currentTimeMillis probably has only a couple of bits of entropy (and on a webserver it is probably observable), maybe a dozen bits for nanoTime. Those random bits are likely in the same range of bits (around bits 5-15). If getLocalHostAddress() returns a loopback address then we've seeded the shared state with only a few bits of randomness. (Also, since the local host address is directly visible it could be reversed out by an attacker). The suggestion of using mix64 was mostly to take best advantage of the entropy available. 

Plus, more bits would be better. Imagine an attack where the attacker looked for newly launched instances of a clustered webserver. It would not be too hard to reduce the search space for the initial value of it's SplittableRandom seeder to less than 2^16 possibilities. Whether this is useful would depend upon the application being run on that webserver but it seems insufficient to me though.

Mike