> Does anyone have a better solution that doesn't involve calling > entropy-gathering routines from all over the program or running a > continuous entropy-gathering thread? Are there any big problems in > this solution, other than that it only has (by my pessimistic > estimates) about 28 bits of entropy if my "thousandlists" trick isn't > really very effective? 28 bits is probably sufficient for my > purposes. Is there some much simpler solution I could have more > confidence in? Yes. OpenBSD has /dev/arandom, kernel arc4random(), and libc arc4random(3) which load a chunk from the real random pool when needed, persistantly permit reuse of that pool without having to rely on new entropy, and automatically reseeds that pool when we perceive that the quality of it may be dropping. This type of pool is ideal for use as chaff, random ids, etc. It's the right solution for the problem you (and many others) face: Where is a very cheap source of fairly strong random data that does not deplete the critical resource of very strong random in the kernel pool.
This archive was generated by hypermail 2b30 : Mon Jul 29 2002 - 14:15:32 PDT