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

Reply via email to