[crac] RFR: Reseed secure random on checkpoint restore

Alexey Bakhtin abakhtin at openjdk.java.net
Thu Dec 23 16:12:34 UTC 2021


On Thu, 23 Dec 2021 13:45:54 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> Proposed changes in the SecureRandom implementation allow invalidating and reseeding SHA1PRNG secure random during checkpoint/restore. SHA1PRNG can be invalidated and reseeded in case of being created with a default embedded seed generator. Also, SHA1PRNG is used as an additional seed generator to the SUN NativePRNG implementation, so it is desirable to have reseeded SHA1PRNG after restore.
>> Two jtreg tests added: 
>> - verify if no deadlocks introduced by checkpoint/restore
>> - verify if SHA1PRNG is reseeded if created with default embedded seed generator
>
> src/java.base/share/classes/sun/security/provider/SecureRandom.java line 267:
> 
>> 265:             SeedGenerator.generateSeed(b);
>> 266:             seeder.engineSetSeed(b);
>> 267:             seeder.clearStateOnCheckpoint = true;
> 
> This highlights that the `seeder` differs from any other SecureRandom. I would prefer `seeder` to be an object of a subclass of `SecureRandom`. This will also save us a field `isSeedGenerator` that is false for all except one object in the system.

Unfortunately sun.security.provider.SecureRandom class is final. I think it was done intentionally for security reasons.
isSeedGenerator can be easily replaced by comparison with SeederHolder.seeder but it'll eat time during restore.

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

PR: https://git.openjdk.java.net/crac/pull/7


More information about the crac-dev mailing list