
SQLite3 Multiple Ciphers
The project SQLite3MultipleCiphers implements an encryption extension for SQLite with support for multiple ciphers.
is the latest version. The API documentation is available online. The component itself is hosted on GitHub:
SQLite3 encryption extension with support for multiple ciphers
Description
SQLite3 Multiple Ciphers is an extension to the public domain version of SQLite that allows applications to read and write encrypted database files. Currently 7 different encryption cipher schemes are supported:
- wxSQLite3: AES 128 Bit CBC - No HMAC
- wxSQLite3: AES 256 Bit CBC - No HMAC
- sqleet: ChaCha20 - Poly1305 HMAC (Default cipher scheme)
- SQLCipher: AES 256 Bit CBC - SHA1/SHA256/SHA512 HMAC
- System.Data.SQLite: RC4
- Ascon: Ascon-128 v1.2
- AEGIS: AEGIS Family of Authenticated Encryption Algorithms
In the past the SQLite encryption extension was bundled with the project wxSQLite3, which provides a thin SQLite3 database wrapper for wxWidgets-based applications.
In the course of time several developers had asked for a stand-alone version of the wxSQLite3 encryption extension. Originally it was planned to undertake the separation process already in 2019, but due to personal matters it had to be postponed for several months. However, maybe that wasn’t that bad after all, because there were changes to the public SQLite code on Feb 7, 2020: “Simplify the code by removing the unsupported and undocumented SQLITE_HAS_CODEC compile-time option”. These changes took effect with the release of SQLite version 3.32.0 on May 22, 2020. As a consequence, all SQLite encryption extensions out there will not be able to easily support SQLite version 3.32.0 and later.
In late February 2020 work started on a new implementation of a SQLite encryption extension being able to support SQLite 3.32.0 and later. The new approach is based on SQLite’s VFS feature. This approach has its pros and cons. On the one hand, the code is less closely coupled with SQLite itself; on the other hand, access to SQLite’s internal data structures is more complex.
Technical details
SQLite3 Multiple Ciphers encrypts the entire database file, so that an encrypted SQLite database file appears to be white noise to an outside observer. Not only the database files themselves, but also journal files are encrypted.
SQLite3 Multiple Ciphers has more or less the same limitations as the official SQLite Encryption Extension (SEE):
- TEMP tables are not encrypted.
- In-memory (":memory:") databases are not encrypted.
- Bytes 16 through 23 of the database file contain header information that is usually not encrypted.
To not compromise security by leaking temporary data to disk, it is very important to keep all temporary data in memory. Therefore it is strongly recommended to use the compile time option SQLITE_TEMP_STORE=2 (which is the default in the current build files) (or even SQLITE_TEMP_STORE=3, forcing temporary data to memory unconditionally). PRAGMA temp_store=MEMORY; should be used for encrypted databases, if the compile time option SQLITE_TEMP_STORE was not set to a value of 2 or 3.
In addition to reading and writing encrypted database files SQLite3 Multiple Ciphers is able to read and write ordinary database files created using a public domain version of SQLite. Applications can use the ATTACH statement of SQLite to simultaneously connect to two or more encrypted and/or unencrypted database files. For each database file a different encryption cipher scheme can be used.
History
A detailed version history can be found in the change log.