RFR: 8260274: Cipher.init(int, key) does not use highest priority provider for random bytes

[Valerie Peng]

On Tue, 16 Mar 2021 20:57:48 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>>> As this behavior has been a while, I may not update the implementation. Instead, I would like to add an "implNote" tag to state that once the default provider is loaded, an implementation may be changed it any longer. Applications could use provider parameter if there is a preference.
>> 
>> Well, javadoc of the affected init methods clearly specifies that "get them using the SecureRandom implementation of the highest-priority installed provider as the source of randomness. ", thus I am not sure if we can just get around this with an _ at implNote_.
>
>> I did not get the point that the code path should be unaffected". As there are a few update like:
>> init(keysize, JCAUtil.getSecureRandom());
>> init(keysize, JCAUtil.getDefSecureRandom());
> 
> What I mean is that the new suggestion will not impact callers of JCAUtil.getSecureRandom() which I thought what your performance regression means. To enforce that the most preferred SecureRandom impl is used, this for sure will incur some cost especially when the existing impl just returns a cached obj w/o any checking.

> Could `java.security.Security` contain a "provider version" `int` (volatile, atomic, or similar) which is incremented every time the provider list is changed? Then this class (clearly using some non-public API) would check that value and if it is the same, just return the cached instance. If it has changed since the last time, then it would update `instance` and its remembered value of the index. I think that we might be able to do it without taking any locks in this class because even if the providers change out from under us, we returned a reasonable value (subject to multi-threading) and will fix things up when we're called the next time.

This and Tony's suggestion sounds similar and I can sure explore this.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3018