-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> * <P> The seed is produced by counting the number of times the VM
> * manages to loop in a given period. This number roughly
> * reflects the machine load at that point in time.
> * The samples are translated using a permutation (s-box)
> * and then XORed together. This process is non linear and
I would think SHA1 would be good enough for the above.
> * to the system by keeping the scheduler busy.
> * Twenty such samples should give us roughly 160 bits of randomness.
> * <P> These values are gathered in the background by a daemon thread
> * thus allowing the system to continue performing it's different
> * activites, which in turn add entropy to the random seed.
> * <p> The class also gathers miscellaneous system information, some
> * machine dependent, some not. This information is then hashed together
> * with the 20 seed bytes.
Not sure I like the idea of having the thing looping all the time in the
background. Might heat the processor too much even if its technically
idle time.
I do like the idea of using this on startup and perhaps
periodically. I need to implement entropy estimation code, perhaps using
the clock jitter as an emergency entropy source when the entropy gets too
low.
The EntropyPool class at it stands now has two phases:
Phase 1: Initialization
1- Initialize an SHA-1 context as a pool.
2- update the hash with the following information:
* The current system time
* The entire contents of the system properties table (which should
include some machine dependent fields)
* The machines IP address (definitely system dependent)
* Store a random value (from the pool) into the lastRequest field
Phase 2: random number generation
1- Hash the value of System time - time of last request
2- Use the first n bytes of the hash as the output
Also, entropy can be fed in from parts of the server using the
acceptEntropy() method. Currently, the time taken to receive a freenet
message is fed into the pool. Other places to feedback entropy should be
investigated.
I *was* feeding the unused (n-used) bytes of the hash back into the hash,
but this just doesn't -feel- right to me.
Scott
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE4/AljpXyM95IyRhURAuzQAJ9xCfFZ3qp6SRsYNEff5fiotKjiQgCcDQ+u
5sy4lsopUZog/W+CPIksOqw=
=48li
-----END PGP SIGNATURE-----
_______________________________________________
Freenet-dev mailing list
Freenet-dev at lists.sourceforge.net
http://lists.sourceforge.net/mailman/listinfo/freenet-dev