SQLCipher is one of the more popular SQLite encryption extensions available at this time. Despite this, we are sometimes asked by prospective users how SQLCipher compares to other available SQLite encryption tools from a performance and security perspective.
We don’t have first hand experience with other SQLite encryption tools because SQLCipher was deliberately implemented as a clean room design. However, we are aware that there are some important factors that differ between SQLCipher and other similar products. It is very important to account and control for these factors because SQLCipher may provide enhanced security with the default settings, but these same features may impact performance testing:
When comparing SQLCipher to other encryption extensions, control for these security features that SQLCipher enables by default:
PRAGMA key = "x'...'"; (RAW key) to skip PBKDF2 when comparing to implementations without key derivationPRAGMA cipher_use_hmac = OFF; when comparing to implementations without page tampering protectionPRAGMA secure_delete = OFF; when comparing to implementations that don’t enable this by defaultPRAGMA cipher_page_size = N; to match the page size of other implementations being testedSee detailed explanations below for each factor.
SQLCipher uses an expensive key derivation process (PBKDF2) to derive the actual encryption key from the provided key material and a random per-database salt. This security feature hardens SQLCipher databases against brute force, dictionary, and pre-computation attacks. However, this key deviation process is deliberately very slow. It occurs on the first access of the database after the key is set. When comparing SQLCipher against a similar implementation that does not perform key derivation, the competitor may appear to perform better than SQLCipher. In order to rule this out you can set a test key using the RAW key semantics, e.g. PRAGMA key = "x'2DD29CA851E7B56E4697B0E1F08507293D761A05CE4D1B628663F411A8086D99'"; so that SQLCipher skips key derivation. Make sure to disable key derivation before comparing against implementations that do not offer this security feature.
SQLCipher implements an additional security feature where each page data is protected by a HMAC “signature”. This helps protect the database against tampering because if any page data is modified externally or resequenced SQLCipher will detect the invalid change when the page is read back. This validation involves additional processing overhead whenever pages are read or written. For testing purposes you can disable HMAC for a SQLCipher database using PRAGMA cipher_use_hmac = OFF; after setting the key, but before using the database. Disable HMAC for an accurate comparison against other extensions that don’t provide page data validation / tamper evidence.
SQLCipher enables secure delete by default as a security feature. Usage of secure delete reduces the chance of forensic recovery of deleted data, however, it is time consuming because it requires every deleted page to be written to disk. Standard SQLite and other encryption implementations have secure delete disabled by default. For testing purposes you can disable secure delete using PRAGMA secure_delete = OFF; after setting the key, but before using the database. Disable secure delete for an accurate comparison against other implementations that don’t enable this feature by default.
SQLCipher uses a default page size of 4096 bytes for encrypted databases. Depending on the structure of a database this can have a significant affect on performance, particularly if a competing product is using a different page size. SQLCipher does allow you the flexibility of changing the page size used via PRAGMA cipher_page_size. Typically a smaller page size will perform well with operations that affect a small amount of data, because less information must be encrypted / decrypted to satisfy a statement. If statements are operating on large amounts of data then a larger page size may be more efficient (due to a lower number of overall operations required). Determining the best page size is therefore an application-specific performance tuning exercise, but you should make sure the same page size is used by all implementations when testing. Set SQLCipher’s page size to the same value as any other products to ensure an accurate comparison against alternate implementations.
SQLCipher users have reported that SQLCipher outperforms some other SQLite encryption extensions when controlling for these variables.
Many encrypted SQLite solutions, including all versions of SQLCipher, use FIPS-approved algorithms such as AES-256, SHA-256, and HMAC-SHA-256. However, using FIPS-approved algorithms is not the same as FIPS validation. FIPS validation requires a cryptographic module to undergo rigorous testing and formal validation by an accredited laboratory under the Cryptographic Module Validation Program (CMVP). SQLCipher Enterprise FIPS is the only SQLite-compatible database encryption solution we are aware of that offers an integrated FIPS-validated cryptographic module by default. This distinction is important for organizations operating in regulated environments that require FIPS 140-2 compliance. For more information, see the SQLCipher FIPS page.
SQLCipher encrypts and decrypts the database on a per page basis, but only as needed. If only a few pages are needed to execute a statement, only those pages are in scope. You can see more details on the design page.
When you set a key using PRAGMA key, it does not immediately encrypt or decrypt the entire database file. The key provides the password to be used within PBKDF2 to derive your encryption key (unless you provide a raw key format). Encryption and decryption is deferred until the execution of a SQL command.