> On May 8, 2016, at 10:26 PM, Xuelei Fan <xuelei....@oracle.com> wrote: > > On 5/8/2016 9:06 PM, Wang Weijun wrote: >> Ping again. >> >>> On May 3, 2016, at 10:26 AM, Wang Weijun <weijun.w...@oracle.com> wrote: >>> >>> Hi All >>> >>> Please take a review at >>> >>> http://cr.openjdk.java.net/~weijun/8154523/webrev.00 >>> >>> Basically, a reset in SHA1PRNG should forget the internal state and cached >>> output. >>> > The spec of SecureRandomSpi.engineSetSeed() says: > > The given seed supplements, rather than replaces, the existing seed.
I think this is to encourage people to call setSeed() even if the caller cannot find a perfect seed, as any new call won't make randomness worse. > > If I'm understand correctly, reseed is not the same as reset. It should > be OK to use the cached output for performance if the previous seed is OK. Well, it's almost reset. One calls setSeed() hoping new entropy is added and the output changes. Calling setSeed() is not a common thing and I think it's OK to ignore the performance impact here. Non predictability is quite crucial for a SecureRandom. Thanks Max > > Xuelei