Starting from version 4.3.0 SQLiteManager fully support SQLCipher database encryption. SQLCipher has been adopted as a secure database solution by many commercial and open source products, making it one of the most popular encrypted database platforms for Mobile, Embedded, and Desktop applications.
SQLiteManager is the only sqlite application that supports all the official encryption extensions developed for sqlite by the sqlite authors (SEE - SQLite Encryption Extension). We invested a lot of time building the encryption options built into SQLiteManager and you can now add, remove or change encryption for an sqlite database just selecting a menu item.
All database content, including the metadata, is encrypted so that to an outside observer the database appears to contain white noise. The SEE is actually a set of extension employing various encryption algorithms. The following encryption algorithms are currently supported:
Key Material
The amount of key material actually used by the encryption extension depends on which variant of SEE you are using. With RC4 the first 256 byte of key are used. With the AES-128 the first 16 bytes of the key are used. AES-256 the first 32 bytes of key are used. If you specify a key that is shorter than the maximum key length, then the key material is repeated as many times as necessary to complete the key. If you specify a key that is larger than the maximum key length, then the excess key material is silently ignored.
The Importance of a Nonce
The encryption is much more secure if it has a random nonce value on each page of the database. Without a nonce, the encryption can be broken using a chosen-plaintext attack. Purists will argue that (rightly) the encryption is weak without a nonce. The number of bytes of nonce on each page of the database is determined by byte 20 of the database file. This value is set to zero by default in databases created by the public-domain version of SQLite. And once a database has been created, this value cannot be changed. The nonce size can only be set when the database is first being created.
Because of the extra space taken to store the nonce on each page of the database, your database file might be slightly larger when encryption is enabled. This size increase (if any) will be very small. But if this is still a problem for you and if your use of encryption is to more to prevent idle snooping that to block a determined hack attempt, then you can create one or more tables in the database first, then invoke sqlite3_rekey() to change the encryption key from NULL to whatever you want. No nonce will be used in that case. The encryption will be weaker, but no extra space will be used in the database file to store the nonce.
Bytes 16 through 23 of the database are unencrypted. Thus, you can always check to see how much nonce is being used, even on an encrypted database file, just by looking at byte 20. It is recommended that any product that uses encryption check this byte to make sure it is being set to 4 or 12 or 32 and not 0.
Limitations
- TEMP tables are not encrypted.
- In-memory databases are not encrypted.
- Bytes 16 through 23 of the database file contain header information which is not encrypted.