The project SQLite3 Multiple Ciphers implements an encryption extension for SQLite with support for multiple ciphers. In the past the encryption extension was bundled with the project wxSQLite3, which provides a thin SQLite3 database wrapper for wxWidgets.
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 that will be 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.
The code was mainly developed under Windows, but was tested under Linux as well. At the moment no major issues are known.
- 2.5.0 - August 2026
- Adjusted visibility of internal functions and global data
Many functions and global data of the AEGIS and Ascon crypto algorithms were visible to the linker possibly causing name clashes. They have been made consequentlystatic. - Added 2 compile time symbols,
SQLITE3MC_USE_DISPATCH_TABLEandSQLITE3MC_API_TABLE_PREFIX- Symbol
SQLITE3MC_USE_DISPATCH_TABLEallows to effectively hide all SQLite API functions' symbols from the linker by establishing dispatch tables for calling the SQLite API functions. This avoids linker and runtime conflicts, if an application can't avoid to load multiple SQLite instances. In general, applications should avoid to load multiple instances of SQLite, because that can easily lead to database file corruption, if multiple SQLite instances access the same database file(s). However, if each SQLite instance only accesses a set of database files disjunct to each other, it is usually safe to have multiple SQLite instances in the same process. - Symbol
SQLITE3MC_API_TABLE_PREFIXallows to adjust the external names of the dispatch tables, so that even 2 instances of SQLite3MC could operate in parallel, as long as they don't access the same database file(s). If the symbol is not defined, the default prefixsqlite3mcwill be used.
- Symbol
- Adjusted visibility of internal functions and global data
For further version information please consult the CHANGELOG.
Help in testing and discussing further development will be highly appreciated. Please use the issue tracker to give feedback, report problems, or to discuss ideas.
Before opening a pull request, please read our Contributing Guidelines.
PRs that do not include a verifiable problem statement or human-validated changes may be closed without review.
Documentation of the currently supported cipher schemes and the C and SQL interfaces is provided on the SQLite3 Multiple Ciphers website.
Documentation on how to build the extension can be found on the page SQLite3 Multiple Ciphers Installation.
Free code signing on Windows provided by SignPath.io, certificate by SignPath Foundation
