> On Feb 20, 2020, at 10:48 AM, Richard Hipp <d...@sqlite.org> wrote: > > That assumption is not correct for SQLite, which does you a > cryptographically strong PRNG. And the SQLite PRNG is seeded from > /dev/random on unix.
Not quite; I'm looking at the function unixRandomness() in SQLite 3.28. It's seeded from /dev/urandom, which on Linux "will produce lower quality output if the entropy pool drains, while /dev/random will prefer to block and wait for additional entropy to be collected." (I'm quoting the macOS man page, which goes on to say that on macOS it always returns high-quality randomness.) I'm a bit doubtful about how the function handles errors, too. * If /dev/urandom can't be opened, it instead cobbles together some decidedly low-entropy bytes from the results of the time() and getpid() system calls. IIRC this is very much like the way Netscape seeded its RNG in their first implementation of SSL, which turned out to be easily crackable by guessing the seed. * If there's a read error on /dev/urandom, it just returns a buffer full of zeros, which is about as non-random as you can get. Admittedly these are unlikely scenarios, but failure to properly seed an RNG can be catastrophic for security. And a lot of security exploits come from 'unlikely' scenarios that an attacker finds a way to force. There's a disclaimer about this, actually, inside the source code of sqlite3_randomness(): > /* Initialize the state of the random number generator once, > ** the first time this routine is called. The seed value does > ** not need to contain a lot of randomness since we are not > ** trying to do secure encryption or anything like that… That's kind of at odds with your calling it a cryptographically strong PRNG. :( —Jens _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
