I would say that there are certain member-objects of SecureRandom that should be transient like the seed, but some things like the provider implementation might have a legit use case to serialize. I'd rather there be an error in Deserializing a SecureRandom instance with a provider error than a different JVM/JRE downgrading to a weak provider without an error.
- Jim On 5/8/16 10:22 AM, Michael StJohns wrote: > Does anyone else think there's something wrong with SecureRandom being > serializable? In general, the internal state of a random number > generator shouldn't be extract-able or even saveable. > > I realize this behavior has probably been in the class since the > beginning - but I hadn't actually read this code until I saw the > review request. > > Mike > > > On 5/8/2016 9:06 AM, 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. >>> >>> Thanks >>> Max >>> >
