On 11/24/2014 09:46 PM, roger riggs wrote:
Hi,
This topic has languished for a bit and could use a bit of expertise from
Windows developers.
The improvements in entropy for initializing Secure Random in JDK 8 have
some negative attributes that affect maintainability, robustness and
Hi Roger,
I see the 8060435 bug already talks about that possible solution too.
I agree with Paul that a public static method on SecureRandom would be
better for JDK9. Or maybe even some new class in java.util, which would
implement just the interface to native /dev/urandom on Unixes and
Hi,
This topic has languished for a bit and could use a bit of expertise from
Windows developers.
The improvements in entropy for initializing Secure Random in JDK 8 have
some negative attributes that affect maintainability, robustness and
performance[1].
The dependency on networking, can in
Hello,
Crypto API (as used by NativeRandom on windows with SubMSCAPI) would be
the right thing to use for a secure high entropy source (and this is
actually what is used if you ask SecureRandom for seed bytes). But I
guess this is not at all expected/needed for TLR.
Having all platform launchers
On Mon, Nov 24, 2014 at 2:36 PM, Bernd Eckenfels e...@zusammenkunft.net wrote:
Hello,
BTW2: I am not sure, it this seeded per thread? then using getSeed()
is probably even worse.
No. ThreadLocalRandom and SplittableRandom each need 8 seed bytes per
JVM startup.
