Hi Dr Hipp.
Thanks for the qualitative reply. I have seen comments about RC4 being biased
towards the first few bytes (some suggestions are to drop the first n bytes
etc). I just don't have the confidence from the replies that it is usable
as-is. You have convinced me of the repetition rate but, that aside, it is also
that the seed method on different platforms could be a cause of concern (a prng
will give the same sequence with the same seed). As said previously. On VxWorks
<6.3 this seed was always zero using the method defined (note this was with
older SQLite versions < 3.7.14). The plus here is that the RC4 algo is
initialised only once so subsequent calls produce new values even if they are
predictable. So based on the replies here (which I greatly appreciate), 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).
Regards
Udon Shaun
________________________________
From: Richard Hipp <d...@sqlite.org>
To: Udon Shaun <udon_sh...@yahoo.com>; General Discussion of SQLite Database
<sqlite-users@sqlite.org>
Sent: Sunday, May 26, 2013 12:02 PM
Subject: Re: [sqlite] sqlite3_randomness Quality
The PRNG in SQLite is RC4. That means that the output never repeats. (The
output of RC4 does repeat, in theory, but the repeats do not happen in your
lifetime. The cycle time is on the order of 10^100). The output is uniform
and unbiased - white noise. There are attacks against RC4 but all such attacks
involve analysis of multiple sessions using the same initial key. But the key
is never reused in SQLite, so those attacks are not applicable.
On Sun, May 26, 2013 at 2:54 AM, Udon Shaun <udon_sh...@yahoo.com> wrote:
Hi Simon.
>
>>That's 2^64 values.
>That's not the same as the repetition/period. Also.sqlite3_randomness can
>supply up to n bytes so isn't limited to 8 bytes.
>
>>"You're not going to catch any one of us saying here publicly "This is
>good enough for all cryptographic purposes." since we have no intention
>of being implicated in some disaster."
>
>"Cryptographically secure PRNG" has specific test criteria so it's not
>unreasonable to ask whether it meets the spec or not (there are a couple
>though NIST, BSI et. al.). I suppose what you are really saying is the work
>has not been done therefore the answer is "No, it is not a CSPRNG" and the
>repetition rate is unknown for all platforms. ("we don't know" is an
>acceptable answer by the way although I would have thought it had been looked
>at because of the SQLite Encryption Extension)
>
>Oh well. It was worth a try. Like I said, it would have been a great bonus.
>
>thanks for your input.
>Udon Shaun
>
>
>
>
>________________________________
> From: Simon Slavin <slav...@bigfraud.org>
>To: Udon Shaun <udon_sh...@yahoo.com>
>Sent: Friday, May 24, 2013 9:27 PM
>
>Subject: Re: [sqlite] sqlite3_randomness Quality
>
>
>
>
>On 24 May 2013, at 9:03pm, Udon Shaun <udon_sh...@yahoo.com> wrote:
>
>> Ok. Good start. So we are talking about 2^24?
>
><http://www.sqlite.org/lang_corefunc.html>
>
>"The random() function returns a pseudo-random integer between
>-9223372036854775808 and +9223372036854775807."
>
>That's 2^64 values.
>
>
>> Has any work been done to ascertain the quality on each platform, or is it
>> just a case of it "seems" good enough for locking and SQL on ALL platforms
>> as Simon seems to be saying. (urandom is, after all, as near to random as
>> can be expected from a machine so technically you wouldn't need an RC4 on
>> top for that platform)
>
>Although seeding is done differently on each platform (derived from values
>supplied by different OSen), as Doctor Hipp wrote the function that is seeded
>is the widely-used well-analysed function described here:
>
><http://en.wikipedia.org/wiki/RC4>
>
>Take a look. If you feel it's secure enough for your purposes, go ahead and
>use it. You're not going to catch any one of us saying here publicly "This is
>good enough for all cryptographic purposes." since we have no intention of
>being implicated in some disaster.
>
>
>Simon.
>_______________________________________________
>sqlite-users mailing list
>sqlite-users@sqlite.org
>http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>
--
D. Richard Hipp
d...@sqlite.org
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
