Ideas on generating seeds for random number generators?

Question

Does anyone here have any ideas or know of any good links to articles that discuss how to generate good seeds for random number generators?
I am aware that I could always probably call SecureRandom.generateSeed as one technique.
The major problem that I have with the above is that I have no idea how any given implementation of SecureRandom works, and whether or not it is any good. (For instance, Sun seems to hide their implementation outside of the normal JDK source tree; must be in one of their semi-proprietary sun packages...)
I thought about the problem a little, and I -think- that the implementation below ought to be OK. The javadocs describe the requirements that I am looking for as well as the implementation. The only issue that still bugs me is that maybe the hash function that I use is not 1-1, and so may not guarantee uniqueness, so I would especially like feedback on that.
Here's the code fragments:
     * A seed value generating function for Random should satisfy these goals:
     * <ol>
     *  <li>be unique per each call of this method</li>
     *  <li>be different each time the JVM is run</li>
     *  <li>be uniformly spread around the range of all possible long values</li>
     * </ol>
     * This method <i>attempts</i> to satisfy all of these goals:
     * <ol>
     *  <li>
     *          an internal serial id field is incremented upon each call, so each call is guaranteed a different value;
     *          this field determines the high order bits of the result
     *  </li>
     *  <li>
     *          each call uses the result of {@link System#nanoTime System.nanoTime}
     *          to determine the low order bits of the result,
     *          which should be different each time the JVM is run (assuming that the system time is different)
     *  </li>
     *  <li>a hash algorithm is applied to the above numbers before putting them into the high and low order parts of the result</li>
     * </ol>
     * <b>Warning:</b> the uniqueness goals cannot be guaranteed because the hash algorithm, while it is of high quality,
     * is not guaranteed to be a 1-1 function (i.e. 2 different input ints might get mapped to the same output int).
     public static long makeSeed() {
          long bitsHigh = ((long) HashUtil.enhance( ++serialNumber )) << 32;
          long bitsLow = HashUtil.hash( System.nanoTime() );
          return bitsHigh | bitsLow;
     }and, in a class called HashUtil:     
     * Does various bit level manipulations of h which should thoroughly scramble its bits,
     * which enhances its hash effectiveness, before returning it.
     * This method is needed if h is initially a poor quality hash.
     * A prime example: {@link Integer#hashCode Integer.hashCode} simply returns the int value,
     * which is an extremely bad hash.     
     public static final int enhance(int h) {
// +++ the code below was taken from java.util.HashMap.hash
// is this a published known algorithm?  is there a better one?  research...
          h += ~(h << 9);
          h ^=  (h >>> 14);
          h +=  (h << 4);
          h ^=  (h >>> 10);
          return h;
     /** Returns a high quality hash for the long arg l. */
     public static final int hash(long l) {
          return enhance(
               (int) (l ^ (l >>> 32))     // the algorithm on this line is the same as that used in Long.hashCode
     }

Answer 1

Correct me if I'm incorrect, but doesn't SecureRandom just access hardware sources entropy? Sources like /dev/random?What do you mean by hardware sources of entropy?
What you really want is some physical source of noise, like voltage fluctuations across a diode, or Johnson noise, or certain radioactive decay processes; see, for example
     http://www.robertnz.net/true_rng.html
     http://ietfreport.isoc.org/idref/draft-eastlake-randomness2/
     this 2nd paper is terrific; see for example this section: http://ietfreport.isoc.org/idref/draft-eastlake-randomness2/#page-9
But is /dev/random equivalent to the above? Of course, this totally depends on how it is implemented; the 2nd paper cited above gives some more discussion:
     http://ietfreport.isoc.org/idref/draft-eastlake-randomness2/#page-34
I am not sure if using inputs like keyboard, mouse, and disk events is quite as secure as, say, using Johnson noise; if my skimming of that paper is correct, he concludes that you need as many different partially random sources as possible, and even then "A hardware based random source is still preferable" (p. 13). But he appears to say that you can still do pretty good with these these sources if you take care and do things like deskew them. For instance, the common linix implementation of /dev/random at least takes those events and does some sophisticated math and hashing to try to further scramble the bits, which is what I am trying to simulate with my hashing in my makeSeed method.
I don't think Java can actually do any better than the time without using JNI. But I always like to be enlightened; is there a way for the JVM to generate some quality entropy?Well, the JVM probably cannot beat some "true" hardware device like diode noise, but maybe it can be as good as /dev/random: if /dev/random is relying on partially random events like keyboard, mouse, and disk events, maybe there are similar events inside the JVM that it could tap into.
Obviously, if you have a gui, you can with java tap into the same mouse and keyboard events as /dev/random does.
Garbage collection events would probably NOT be the best candidate, since they should be somewhat deterministic. (However, note that that paper cited above gives you techniques for taking even very low entropy sources and getting good randomness out of them; you just have to be very careful and know what you are doing.)
Maybe one source of partial randomness is the thread scheduler. Imagine that have one or more threads sleep, and when they wake up put that precise time of wakeup as an input into an entropy pool similar to the /dev/random pool. Each thread would then be put back to sleep after waking up, where its sleep time would also be a random number drawn from the pool. Here, you are hoping that the precise time of thread wakeup is equivalent in its randomness to keyboard, mouse, and disk events.
I wish that I had time to pursue this...