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.
Are you expecting security from the app which is aiming to be a mainstream, easy on-boarding messaging text/voice app?
Don’t be naive.
You want a reasonable security and privacy level?
Set up own xmpp server in .onion or .i2p domain, enable client authorization (Tor) or whitelisting (i2p) for your peers, disable S2S and enjoy.
Delta Chat is Okayish if you want to encourage Facebook, Telegram, Whatsapp level people to use an open source project. Delta Chat’s big advantage is that on-boarding is easy.
Oh, don’t worry, there are similar problems with Android! Here is a backgrounder on surveillance (a bit out-of-date but solid). It’s interesting that most of the effective countermeasures are political and financial. DC is deploying those.
I’m with you, I’m on Mobian. And I’d really like the luxury of not caring about the flaws of products I don’t use, but oligopoly products give oligopoly power, which is shaping the society I live in, including things like the the laws I live under, which I can’t really opt out of. 
let me see if I understand correctly, so you think if we let you import your key then you are safe??? buddy if you think we are collaborating with agencies, do you realize we could allow you to import the key and then leak it to some server and then not only your delta chat comms are compromised but anywhere where you use that key???
if you don’t trust the developers (which is OK, this is good, trust no one) you need to read the code and compile the app yourself, or have enough people doing that (ex. f-droid checking the build is reproducible is a plus, then it is a matter of auditing the code that changed between versions)
Perhaps this concept may also be of interest in this regard:
No, my friend. You’re trying to cover up your possible connection to the intelligence agencies by explaining that you’ll be able to give them my key anyway. This explanation doesn’t work for the following reason.
Right now, you have two options: generate a weak key, or give the key to the intelligence agencies. You’re probably using the first option, because the second option is easily detected by reading the code and traffic. In that case, users can check the code as many times as they want. Everything’s fine there.
I want you to fundamentally eliminate the ability to generate weak keys if I can import my key.
Give us back the ability to import keys, and the trust issue will be solved.
Nobody’s forcing you to use DC. Just switch to another messenger that lets you use your own key. I just can’t think of one right now.
So don’t use DeltaChat. No one forced the developer to remove key importing, which worked perfectly well.
The way it was implemented it was not working perfectly. It did not create a new profile, but replaced the whole key in your existing profile without any checks and also kept your existing key next to it. So you could still decrypt incoming messages and thought you are part of the groups, while other users recognized you as not part of the group or a different user. There was also never any way to see how many keys you have, remove existing keys or switch to the old key once you realized that you have broken existing setup by importing a key into a profile that already has contacts and joined chats. The feature should have been first of all implemented as “create a new profile with this key” and not as “import the key into profile”.
The first option is easily detectable by anyone who inspects the keys. Directly sending a key to an intelligence agency would be conspicuous but not necessary.
The US is physically the hub of the big fiber-optic connections that are the core connections of the internet. The US government runs a huge wiretap network, reportedly including Room-641A type blackrooms in internet hubs, which have the technical ability to see the traffic passing through the hub. It collects massive amounts of data, stores it long-term, and spends huge sums on efforts to break encryption. The US government is not the only gov to try this (see this 2010 Chinese attack, which briefly made China a hub), but it is the most successful.
This rather old article will give an idea of the scale, if you read all of it, including the long and incomplete list of data sources:
All this predates the current machine-learning bubble, which is funnelling preposterous sums of money into big datacentres and massively parallel computation.
So just leaking the key in some transmission somehow would be adequate. Not that I think the devs would ever deliberately leak data, either. I think they are quite sincere.
Apart from anything else, it would be near-impossible to consistently suborn a bunch of FOSS devs who live all over the world and clearly aren’t strongly motivated by personal gain. And then you’d need to keep consistently suborning any new contributors who volunteer. For decades. And repeat for every encrypted FOSS messenger. This is unfeasible.
A burglar won’t cut a hole in a cement wall if it’s easier and quieter to open a window.
Additionally, the US government seems more interested in metadata than message data. They want who emails whom, when, from where, and message sizes. DC does not even try to hide that data from an adversary with the ability to comprehensively monitor the network.
To hide that, you send your e-mails over I2P or something with garlic routing, assuming your government lets you run I2P nodes.