For some background, we already have password protection using SQLCipher and have deprecated it because of way too many problems with it.
We implemented this as an experiment, but it has limitations:
- We store blobs (images, files and other media) in a blob directory rather than inside the database. It is not encrypted even when the database is encrypted.
- iOS has special handling for SQLite files, allowing to keep them locked when the process is suspended. Encrypted with SQLCipher databases are not recognized and result in 0xdead10cc error. We have stopped this experiment on iOS because of this: disable creation of new encrypted accounts, fade out existing ones · Issue #2010 · deltachat/deltachat-ios · GitHub
Signal works around this by not encrypting the header of the database, just literally skipping encryption of the first N bytes. - Opening the database is just slow because of key derivation function. This is a problem if you have multiple profiles.
This is all not even considering the UI questions: we just stored the key in the OS “keychain”, not asking the user to ever type the password.
Currently password encryption database feature is marked as “deprecated at unknown future date”. We keep it around for Ubuntu Touch client because Ubuntu Touch does not support disk encryption or filesystem encryption. This is better than nothing even when the blobdir is not encrypted, but for every other operating system (Android, Linux, Windows, macOS, FreeBSD, iOS) we recommend that users use their OS features to encrypt all the application files. As soon as Ubuntu Touch has proper FS encryption, we would really like to deprecate SQLCipher for real and go back to plain SQLite.
In short, I think this is not a feature that apps should implement, but an OS should implement. Otherwise it greatly multiplies the effort: every application will need to integrate with iOS, Android, GNOME/KDE/whatever, macOS, Windows etc. interfaces to access keychains (“secure enclaves”)
The answer is likely “no”. There is much lower hanging fruit, such as encrypting the backups. Users uploading their backups to Google Drive is easier to solve and likely has more impact. As for “forensic resilience”, we have not even thought about it being a problem that we should solve in the app before.
Storage it Delta Chat is basically using rusqlite, an Rust interface to SQLite, with vendored SQLCipher. Next to the database each profile (called “account” in the core for historical reasons) stores blob directory with unencrypted blobs named after the contents BLAKE3 hash for deduplication.
For me this technology also looks like something that is more interesting for protecting the servers which are much easier to access than phones. The phones you can likely protect by locking down the USB or rebooting them like GrapheneOS does, and at the same time it is more likely that user will be forced to unlock the phone regardless of the technical measures.
As for the issues linked by @ian, I would not interpret them as user asking for protection against so-called forensic tools. Most of them are asking for encrypted backups or local “password protection” for the app on a shared device (which is better solved by e.g. private space feature, multiple profiles with filesystem encryption like on Ubuntu etc.).
I could not find anything about “lease token” in relation to “searchable symmetric encryption”, what does this mean?