If your security needs are high enough that you'd rather risk blocking
for an arbitrarily-long period of time while sufficient system entropy
builds, than risk generating values from potentially insufficient entropy
(ex, if you'd rather reseed from Linux's /dev/random than /dev/urandom),
then set this to Yes.PredictionResistance. The next time a value is
generated, the internal state will first be replenished with additional
entropy, potentially from a blocking source.
After the next value is generated, this will automatically reset back
to No.PredictionResistance to avoid needlessly consuming the system's
available entropy. Note that forcefully setting this to Yes.PredictionResistance
before each and every value generated is NOT cryptographically necessary,
can quickly starve the system of entropy, and should not be done.
Default is No.PredictionResistance.
This setting is for changing read()'s default bahavior. Individual calls
to read() can manually override this per call.
If your security needs are high enough that you'd rather risk blocking for an arbitrarily-long period of time while sufficient system entropy builds, than risk generating values from potentially insufficient entropy (ex, if you'd rather reseed from Linux's /dev/random than /dev/urandom), then set this to Yes.PredictionResistance. The next time a value is generated, the internal state will first be replenished with additional entropy, potentially from a blocking source.
After the next value is generated, this will automatically reset back to No.PredictionResistance to avoid needlessly consuming the system's available entropy. Note that forcefully setting this to Yes.PredictionResistance before each and every value generated is NOT cryptographically necessary, can quickly starve the system of entropy, and should not be done.
Default is No.PredictionResistance.
This setting is for changing read()'s default bahavior. Individual calls to read() can manually override this per call.