HI Ivor. > it doesn't matter how long and complicated a chain of > generators you string together - you cannot make entropy where there was >none before.
Agreed. However I have control over what rand() is seeded with (without hacking the SQLite codebase - that would be sacrilege) and have verified it is definitely not zero and not "similar" on each invocation for all platforms. The proof, however, will be after I run the chain through the full suite of NIST and "DieHarder" tests (didn't want to if I could get away with it). Initial "quick" statistical tests (on windows7) seem to indicate it should do well and ENT (http://www.fourmilab.ch/random/) agrees (Entropy 7.9991, ChiSQ 257.532, Exceed 44.38%). Udon Shaun ------------------------------------------------------------------------------------------------- Message: 13 Date: Wed, 29 May 2013 09:11:56 -0400 From: Igor Tandetnik <i...@tandetnik.org> To: sqlite-users@sqlite.org Subject: Re: [sqlite] sqlite3_randomness Quality Message-ID: <ko4uqu$fa8$1...@ger.gmane.org> Content-Type: text/plain; charset=UTF-8; format=flowed On 5/29/2013 8:54 AM, Udon Shaun wrote: > I have decided to hash the sqlite random with the normal rand() then use that as the seed for the FORTUNA algo to mitigate this scenario. That should then ensure that the seed is always different.even if > the OS specific random function isn't that random (or indeed 0). rand() needs to be seeded, too. If one can predict the seed for SQLite RNG and for rand(), then one can also predict the seed for FORTUNA. More generally, it doesn't matter how long and complicated a chain of generators you string together - you cannot make entropy where there was none before. -- Igor Tandetnik _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users