Other SQLite3 encryption extesions (e.g., wxSQLite3 & SQLCipher) do not verify the encryption key in sqlite_key_v2(). Instead, the validity of the key is determined later based on the success/failure of the following database access (source SQLCipher API: Testing the key).
Verifying the key automatically in sqlite_key_v2() is generally better, but in certain situations skipping the key verification is useful. For example, a multi-threaded app may want to verify the key once in the main thread, and then skip unnecessary key verifications in child threads using the same (known to be correct) key. Moreover, the verification process involves reading the 1st page of the database (from disk bypassing page caches), which may be unacceptable in rare cases.
Straightforward implementation consists of a compile-time macro and a run-time URI parameter controlling the skipping of the key verification in codec_set_to().
Other SQLite3 encryption extesions (e.g., wxSQLite3 & SQLCipher) do not verify the encryption key in
sqlite_key_v2(). Instead, the validity of the key is determined later based on the success/failure of the following database access (source SQLCipher API: Testing the key).Verifying the key automatically in
sqlite_key_v2()is generally better, but in certain situations skipping the key verification is useful. For example, a multi-threaded app may want to verify the key once in the main thread, and then skip unnecessary key verifications in child threads using the same (known to be correct) key. Moreover, the verification process involves reading the 1st page of the database (from disk bypassing page caches), which may be unacceptable in rare cases.Straightforward implementation consists of a compile-time macro and a run-time URI parameter controlling the skipping of the key verification in
codec_set_to().