Hello,
while trying to understand the exact behaviour of SecureRandom in Oracle
JavaSE I found some places with potential improvements. I am new to the
list, so let me know if and how I should submit the RFE (or patches)
differently.
http://hg.openjdk.java.net/jdk8/jdk8-gate/jdk/file/32a57e645e01/src/share/classes/sun/security/provider/SeedGenerator.java
sun.security.provider.SeedGenerator#getSystemEntropy()
159: (if resolution is 20ms then this will only contribute 4bits) would it
make sense to use nano seconds instead of millisenconds and submit more
than one byte to the hashing? (longToByteArray() already exists)
170: instead of looping through the enumeration of the system property
names I would loop over the entry set, since this avoids the hash lookups
http://hg.openjdk.java.net/jdk8/jdk8-gate/jdk/file/32a57e645e01/src/share/classes/sun/security/provider/SunEntries.java
32: this javadoc comment does not format nicely into html
http://hg.openjdk.java.net/jdk8/jdk8-gate/jdk/file/32a57e645e01/src/solaris/classes/sun/security/provider/NativePRNG.java
77: this logic requires both random and urandom to exist. The idea behind
that is not using this native seeder if one of both is missing, since both
are used. However on a system where one of both exists I would expect it
to be used since it is for sure better than using the threaded
alternative. In addition to that user might have specified one of both
with java.security.egd and it is confusing if it is not observed.
130: MAX_BUFFER_TIME what is the idea behind expiring the urandom buffer?
The content does not get worse or bad if it lays around. Especially not
within 100ms.
252: implSetSeed() the comment says it is always adding the seed to the
mixer and optionally writing it to dev/random, however the code is
different, the engineSetSeed() is called at the end outside of a finally
block, so in case there is a ioerror writing to /dev/random (likely!)
there will also be additional seeding of the mixer
278: implNextBytes() this logic with calling ensureBufferValid() for every
single byte has the disadvantage that it will call
System.currentTimeMillis() for every byte EVEN when there are more/enough
bytes in the internal buffer. This shoould be changed into two loops (the
inner loop consumes all remaining buffered bytes without using the
validity check). Another option would be to skip the validity check
completely, I dont see a need for it.
Greetings
Bernd
--
http://bernd.eckenfels.net
