[crac] RFR: Reseed secure random on checkpoint restore

Dan Heidinga duke at openjdk.java.net
Mon Dec 20 15:48:16 UTC 2021


On Fri, 17 Dec 2021 13:38:18 GMT, Alexey Bakhtin <abakhtin 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 176:

> 174:             state = digest.digest(seed);
> 175:             remCount = 0;
> 176:             clearStateOnCheckpoint = false;

I'm not clear on why we need this boolean.  Why does the code say not to clear this Random on a checkpoint if someone has called `engineSetSeed`?

src/java.base/share/classes/sun/security/provider/SecureRandom.java line 244:

> 242:         if (isSeedGenerator)
> 243:             return -12;
> 244:         return -11;

How are priorities determined?  I see other implementors of this method mostly setting their priority to 0.

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

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


More information about the crac-dev mailing list