feat: add support for locked/encrypted accounts to jsonrpc api

[Simon-Laux]

api!: jsonrpc new variant of Account enum: Account::Locked.

TODO:

• Account::Locked type
• when feat: add AccountsChanged and AccountsItemChanged events #6118 is merged add event and test upon unlocking/opening
• Add missing encryption apis to jsonrpc/api.rs

[link2xt]

This has been even removed on Android and iOS, so unlikely we want to add support on Desktop now.

[link2xt]

Another problem of this feature is that it pulls OpenSSL that takes long time to build. It would be great to get rid of OpenSSL, we currently only depend on it for nauta.cu support (they have self-signed TLS certificate with outdated SHA-1 and small RSA-1024 that Rustls refuses to work with at all) and for most connections Rustls is used.

[Simon-Laux]

Another problem of this feature is that it pulls OpenSSL that takes long time to build.

seems unrealated. edit: seems true that sqlcipher uses openssl for crypto, I couldn't believe that at first.

This has been even removed on Android and iOS, so unlikely we want to add support on Desktop now.

the feature is not needed on those platforms as they have reliable methods of protecting the app data from other apps.

[iequidoo]

the feature is not needed on those platforms as they have reliable methods of protecting the app data from other apps.

Why don't we want to store the app data in Desktop only accessible by a separate user and running deltachat-rpc-server with the privileges of that user (using SUID)?

[link2xt]

seems true that sqlcipher uses openssl for crypto, I couldn't believe that at first.

SQLCipher is annoying in other ways, iOS has troubles recognizing the file as SQLite and only allows locking SQLite as a hack. Signal works around this by not encrypting the first few bytes on iOS. See deltachat/deltachat-ios#2010

We cannot just remove this feature however, because Delta Touch is using it and the reason is that Ubuntu Touch does not have filesystem or full disk encryption. But we don't want new users of this, especially bot operators deciding it is a good idea to encrypt the database.

I also opened #7403

[link2xt]

Why don't we want to store the app data in Desktop only accessible by a separate user and running deltachat-rpc-server with the privileges of that user (using SUID)?

This does not protect against malware that runs as your primary user, it can just as well run the same SUID binary and access any data this way.

In any case, on Linux the way to isolate apps from each other is Flatpak nowadays. It is not used, its sandboxing features are not used properly etc. etc., but whatever effort we can spend on doing our hacky solution is better spent improving flatpak build.

the feature is not needed on those platforms as they have reliable methods of protecting the app data from other apps.

The problem is that database encryption also does not protect app data from other apps. Signal is protecting app data with a symmetric key, but then stores the symmetric key with DPAPI and DPAPI is not protecting the secret from other apps, it only protects from other users. See https://stolenfootball.github.io/posts/research/2025/signal_windows_decryption/ for the current state of it. If you can protect the secret key against other apps, just protect the database against other apps the same way.

[Simon-Laux]

So the only thing that would be secure on windows and Linux is to encrypt with a password and asking user on startup for that password?

But even then it would be too complex to have locked/unlocked state per dc profile/account, it would be easier to have locking on the account manager instead.

But typing in a password is rather inconvenient for users... Maybe something for a fork that focuses on more on local data hardening / trusting the local device less.
(another thing that could be interesting for a "security level: paranoid" fork would be storing encryption/decryption keys on an external yubikey or OpenPGP Keycard and stuff like that)

[iequidoo]

This does not protect against malware that runs as your primary user, it can just as well run the same SUID binary and access any data this way.

The SUID binary can ask a password additionally (what e.g. sudo does).

As for data encryption, it shouldn't be necessary in general, the most important thing is that the whole disk is encrypted, instead, apps should be isolated from each other in some way.