

The schema name is main for the main database, temp for the temporary database, or the schema name specified in an ATTACH statement for an attached database. Sqlite3_rekey() is used to change the encryption key for the main database, while sqlite3_rekey_v2() changes the key for the database with the schema name specified by zDbName. Sqlite3_key() is used to set the key for the main database, while sqlite3_key_v2() sets the key for the database with the schema name specified by zDbName. The functions sqlite3_key() and sqlite3_key_v2() set the database key to be used when accessing an encrypted database or creating a new encrypted database, and should usually be called immediately after sqlite3_open(). SQLITE_API int sqlite3_key ( sqlite3 * db, /* Database to set the key on */ const void * pKey, int nKey /* The key */ ) SQLITE_API int sqlite3_key_v2 ( sqlite3 * db, /* Database to set the key on */ const char * zDbName, /* Database schema name */ const void * pKey, int nKey /* The key */ ) SQLITE_API int sqlite3_rekey ( sqlite3 * db, /* Database to be rekeyed */ const void * pKey, int nKey /* The new key */ ) SQLITE_API int sqlite3_rekey_v2 ( sqlite3 * db, /* Database to be rekeyed */ const char * zDbName, /* Database schema name */ const void * pKey, int nKey /* The new key */ ) C APIīasically, the C API of the official SQLite Encryption Extension (SEE) is supported. The SQLite3 Multiple Ciphers encryption extension can be used via the C API as well as via SQL. Bytes 16 through 23 of the database file contain header information that is usually not encrypted.In-memory ( ":memory:") databases are not encrypted.SQLite3 Multiple Ciphers has more or less the same limitations as the official SQLite Encryption Extension (SEE): Not only the database files themselves, but also journal files are encrypted.

SQLite3 Multiple Ciphers encrypts the entire database file, so that an encrypted SQLite database file appears to be white noise to an outside observer. For each database file a different encryption cipher scheme can be used. Applications can use the ATTACH statement of SQLite to simultaneously connect to two or more encrypted and/or unencrypted database files. In addition to reading and writing encrypted database files SQLite with the SQLite3 Multiple Ciphers extension is able to read and write ordinary database files created using a public domain version of SQLite. SQLCipher: AES 256 Bit CBC - SHA1/SHA256/SHA512 HMAC.

Currently 5 different encryption cipher schemes are supported: SQLite3 Multiple Ciphers is an extension to the public domain version of SQLite that allows applications to read and write encrypted database files.
#Db browser for sqlite encryption android
Not DI (Dependency Injection) friendly but Android can't really do that, yet.The project SQLite3 Multiple Ciphers implements an encryption extension for SQLite with support for multiple ciphers.

I then set up a static getter for retrieving the already opened SQLiteDatabase object. The approach I ended up adopting was sub-classing Application and performing a single db open during onCreate and a single db close onTerminate. From my investigation at the time it became clear that it was unnecessary to constantly open and close db connections. Expanding on elhadi's answer I have come across similar issues when opening and closing database connections across multiple async tasks.
