RFR: 8260274: Cipher.init(int, key) does not use highest priority provider for random bytes [v2]
Valerie Peng
valeriep at openjdk.java.net
Wed Mar 17 19:59:50 UTC 2021
On Wed, 17 Mar 2021 19:34:54 GMT, SalusaSecondus <github.com+829871+SalusaSecondus at openjdk.org> wrote:
>> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
>>
>> Changed to use volatile for the default SecureRandom object reference
>
> src/java.base/share/classes/sun/security/jca/JCAUtil.java line 84:
>
>> 82: * SecureRandom impl if the provider table is the same.
>> 83: */
>> 84: public static SecureRandom getDefSecureRandom() {
>
> When should people use `getSecureRandom` rather than `getDefSecureRandom()`? Are we leaving the old to avoid changing behavior out from under people who may not expect it?
To minimize the impact, I leave the JCAUtil.getSecureRandom() impl as is. I suppose this is more for JDK internal code which is not required to use the most preferred SecureRandom impl. There are quite a few callers to this method and I feel it's better to leave them out of this change.
> src/java.base/share/classes/sun/security/jca/JCAUtil.java line 92:
>
>> 90: }
>> 91: }
>> 92: return def;
>
> Do we need to worry about `clearDefSecureRandom()` being called between lines 88 and 92?
>
> Thread 1: `getDefSecureRandom()#85` (`def` is `null`)
> Thread 1: `getDefSecureRandom()#86`
> Thread 1: `getDefSecureRandom()#87` (`def` is still `null`)
> Thread 1: `getDefSecureRandom()#88` (`def` is **not** `null`)
> Thread 2: `clearDefSecureRandom()` (`def` is `null` again)
> Thread 1: `getDefSecureRandom()#92` (return `def` which is incorrectly `null`)
>
>
> Suggestion:
>
> SecureRandom result = def;
> if (result == null) {
> synchronized (JCAUtil.class) {
> result = def;
> if (result == null) {
> def = result = new SecureRandom();
> }
> }
> }
> return result;
Sure, good point. I will update. Thanks for catching this.
-------------
PR: https://git.openjdk.java.net/jdk/pull/3018
More information about the security-dev
mailing list