Random points

[Bernd Eckenfels]

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