Initializing Secure Random (Reprise)

Bernd Eckenfels ecki at zusammenkunft.net
Mon Nov 24 22:36:01 UTC 2014


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 generate a random
process startup uuid would be so usefull, not only be the seeder for
the TLR. Maybe there should be some bootstrap code to do this once (and
without too much subsystem dependencies). This could even uses stuff
like libuuid on Linux or UuidCreate from rpcrt.dll on Windows.

Mixing this "JVM instance UUID" with PID and Timestamp -> good enough
TLR.

BTW: It was probably not a good idea to make SecureRandom.getSeed() so
easily accessible... if you think TLR needs a good random source, you
should at least allow the SecureRandom instance to use urandom and SHA1
mixing. Both is present with getInstance().getBytes() (but its probably
also not faster in the bug-specific test as the SecureRandom will be
seeded once at this point).

BTW2: I am not sure, it this seeded per thread? then using getSeed()
is probably even worse.



More information about the core-libs-dev mailing list