These are just my guesses: You disabled the ability to import user-generated encryption keys. You did this at the request of the intelligence agencies. Now you can secretly embed a weak random number generator into your code, which will generate encryption key parameters from a very small set. This is done so that the intelligence agencies can quickly guess the encryption key.
Don’t tell me you passed an audit. That doesn’t prove you have no connection to the intelligence agencies. Also, don’t tell me I can read the source code. Because almost no one reads the source code of programs; they just take your word for it.
Don’t tell us you don’t want to support all possible encryption key types. We don’t need that at all. Declare that only curve 25519 support is guaranteed, and that using NIST curves is at the user’s risk.
Just bring back support for importing encryption keys or show us how to replace the encryption key in the profile backup.
For context, the reason for not importing the keys is in FAQ and was already answered at How can I import my keys? and is a follow-up to your other previous topic Could you please comment on this deltachat message?
If you don’t trust the code that generates keys in Delta Chat then it does not matter if you can import your own key anyway because other users of Delta Chat that you communicate with are unlikely to import their own key.
Code that generates keys is fully open source, we use the same random number generator as most of other Rust projects, there is a single line that instantiates it:
OpenPGP is a hybrid cryptosystem, when the message is encrypted it is encrypted with a newly generated symmetric session key and then this session key is encrypted to the recipients OpenPGP keys. So you need to trust the same generator that is used to generate session keys here:
If you don’t trust this generator to generate persistent asymmetric keys, you should not trust it to generate symmetric keys as well, at this point you better not use Delta Chat to encrypt your messages.
All releases of chatmail core are reproducibly built, this includes the binaries used in Delta Chat Desktop downloaded from npm, you can rebuild them with a single nix build command and verify that you get the same binary. For F-Droid builds you can check status here, they build the core from source as well as a part of build process: Delta Chat Reproducibility Status
Don’t speak for others. They will import keys at their own discretion. But you’ve deprived them of that ability.
can I ask a question?
give an example of compiled generated keys in delta chat?
I’m not sure I understand the question and what “compiled” key means, but here is an example of a freshly generated secret key from 2.43.0:
-----BEGIN PGP PRIVATE KEY BLOCK-----
xVgEaaW7mhYJKwYBBAHaRw8BAQdAzVpG5ucJeIdzLFqginHDfbDjnVSDoO5xmzMw
HDtooisAAQDzym27O+KVHMNyXQrvgbtWt2rYhCOgfUBiMAzdD08Sxw+AzRw8anNh
NXpubGVuQG5pbmUudGVzdHJ1bi5vcmc+wo8EExYIADcFAmmlu5oWIQTUsJ7WaOQO
HhWIi5Mg+CUp4uZn7AIbAwIeAQQLCQgHBRUICQoLAxYCAQEnAhkBAAoJECD4JSni
5mfsUsIA/ixb96AiArV2y+WAdy2XuhhuUOO5cs6zTQspDwk3LQoGAP9uqoxtQGFq
SpbMiun5ly2D32kEoGzeFntSgTi/bcu3AsddBGmlu5oSCisGAQQBl1UBBQEBB0Co
MbUCjZ4V7iBlf3kNE+rc9o710nUDEH3F2lgfowmTdQMBCAcAAP9FugJS/Tp+NLLK
ZZNTG0VhEbjYE2Twdbo8J1mqkj0rGA5ywngEGBYIACAFAmmlu5oCGwwWIQTUsJ7W
aOQOHhWIi5Mg+CUp4uZn7AAKCRAg+CUp4uZn7D/tAP9mOHrmTMWn58uC4YYmyZfe
T1vxGJjEtkBi0Z7XGt2qWwD+KSa0dR5eDpwpHkrJ2+1KgNuXrtmiwqvKCtpLA2+k
qwQ=
=t++K
-----END PGP PRIVATE KEY BLOCK-----
This is the structure of the key, it is compliant with Autocrypt spec:
$ sq inspect key
key: Transferable Secret Key.
Fingerprint: D4B09ED668E40E1E15888B9320F82529E2E667EC
Public-key algo: EdDSA
Public-key size: 256 bits
Secret key: Unencrypted
Creation time: 2026-03-02 16:32:26 UTC
Key flags: certification, signing
Subkey: 13C2221098A1AC52D67EE7C006A64E5E4EC3E3A3
Public-key algo: ECDH
Public-key size: 256 bits
Secret key: Unencrypted
Creation time: 2026-03-02 16:32:26 UTC
Key flags: transport encryption, data-at-rest encryption
UserID: <jsa5znlen@nine.testrun.org>
no no, not from the word compilation, this is apparently a typo…
meaning to compromise, expose
Don’t tell us the code is open source, because almost no one reads it. Instead, almost all users take your word for it. Just allow us to import encryption keys. And announce that only the 25519 curve is guaranteed to be supported. That’s all.
Doesn’t it seem to you that if Delta Chat were actually cooperating with intelligence agencies, the presence or absence of key import/export functionality would be irrelevant?
Based on your logic (especially regarding the open-source nature of the application), one could just as easily argue that the app might generate and use its own keys at the moment a message is sent, instead of the user-imported ones.
However, this is easily verifiable: you can simply create two profiles and examine which keys are actually being used for encryption. The process is transparent and open to analysis.
Therefore, making accusations against an open-source project without having the technical competence to analyze the code seems questionable at best. The response “speak for yourself” is not an argument, but rather an avoidance of the core issue.
Finally, which key exactly do you believe should be imported?
For the keys to be compromised, the random number generator, used by many projects, would need to be compromised, without those projects noticing, despite all the people who are pretty obsessive about testing random number generators. Alternately, DC could have published false source code, and snuck a different keygen algo into the code in use. The latter would tend to be noticed by the folk doing reproducible builds of DC.
The public keys also get transmitted in Autocrypt headers, and your own private keys are available to anyone who can inspect the database. If they were not actually random, this could be discovered by analysis of the generated keys.
There are lots of ways to attack DeltaChat that are easier than compromising the keys, especially if you have the resources of a government behind you. Leaking the keys, for instance, perhaps using one of the many third-party apps that steal info off mobile phones, or by compromising a dependency, or the distribution chain. Or you could give up on the fulltext and just go for the metadata.
Socially, any covert surveillance operation that requires the long-term, knowing, unwilling co-operation of a bunch of FOSS devs seems doomed to failure: someone would defect. Easier to periodically pay someone else to find a zero-day exploit. Security audits are not that expensive.
Here’s a news story about state surveillance tools, from Tuesday: A Possible US Government iPhone-Hacking Toolkit Is Now in the Hands of Foreign Spies and Criminals | WIRED.
This sort of tool makes weakening keys pointless; stealing them is easier. In fact, stealing keys is more useful, since you are more likely to get exclusive info.
The devs here can’t do much about that sort of attack. Diversifying mobile operating systems, and removing them from the control of companies that profit from surveillance, would be an effective political countermeasure; so making Chatmail more cross-platform helps.