Looks like they got a security analysis (definition is different from security audits).
I’m going to drop some notes here as a lot of stuff is out of date.
I would recommend looking at Delta Chat as a messenger, not an email client. Let me walk through some of the previous comments that caught my eye:
This is an issue when you use legacy/classic email servers. If you use dedicated Chatmail servers this is not a problem. Chatmail servers do not allow any emails to be sent or received unless they’re encrypted. If you try to use Delta Chat with a normal email server you need to at least send each other one message in cleartext so the key exchange happens in the background. With Chatmail servers you cannot message anyone without using an invite link or QR code that gives you their public key.
This was actually a bug due to inverted logic on iOS. It was ignoring the notifications in some edge cases like recently switching away from the app and it wasn’t backgrounded by iOS yet.
Probably a bug long since fixed. I’ve never encountered this in the last 6 months of heavy testing.
That’s true for legacy PGP usage, but Delta Chat’s implementation doesn’t have this problem. Even the Subject field is encrypted.
Delta Chat protects most message metadata by putting the following information into the end-to-end encrypted part of messages:
* Subject line
* Group avatar and name
* MDN (read receipt) requests (Chat-Disposition-Notification-To)
* Disappearing message timer (Ephemeral-Timer)
* Chat-Group-Member-Removed, Chat-Group-Member-Added
* Secure-Join header containing secure join commands
* Notification about enabling location streaming
* WebRTC room URL
E-Mail servers do not get access to this protected metadata but they do see the message date as well as the message size, and, more importantly, the sender and receiver addresses. E-mail servers need receiver addresses to route and deliver messages to recipient’s devices.
source: https://delta.chat/en/help#message-metadataSince the creation of Chatmail servers they have been pushing people away from using regular email addresses with Delta Chat. Based on my discussions with the devs it will continue to be supported as it can still be useful in some situations, but the app and onboarding pushes you to use Chatmail servers.
I already covered the metadata. Rolling keys/PFS is not important for most people. Do you keep your chat history? Congratulations, PFS gives you no advantages. If your device is seized they still get all your messages. How many people ensure all their chats have disappearing messages? I want all my chats with friends and family to be secure, but I also want the history and to be able to search them. So what is PFS going to do for me? Nothing.
PFS is still important if you’re a target of a sophisticated State-funded attacker.
Compatibility with old PGP: technically true. Although it’s not vulnerable to EFAIL and DeltaChat will generate keys that are Ed25519/Curve25519 and use AES128 for the session keys. It’s technically possible for someone to manually import an ancient DES PGP key and use it via a normal email address. This is a pretty extreme scenario though.
Try Delta Chat again. It has in-chat apps now via WebXDC.org. It can do realtime p2p comms that bypasses the email servers. It’s fast. It has a quality client on all major platforms. It is open, permissionless, and federated. The Chatmail servers scrub metadata and logs. The Chatmail servers require significantly lower resources to host users than Matrix – even less than XMPP.
There are a lot of interesting things on the horizon such as making it possible to have it automatically register new random accounts on different Chatmail servers and rotate through them transparently. Your contacts and chat groups wouldn’t notice anything changed (a feature of AEAP), but it makes it very hard for adversaries to track you.
Try it again, but only with Chatmail servers. I think you’ll be pleased.
(had issues with new account limited on links)
example Chatmail servers:
- nine.testrun.org (their semi-official one they do all their R&D on)
- bcc.chat
- chat.feld.me
- tarpit.fun
- mailchat.pl
Keep in mind that the reason these work and aren’t a vector for spammers getting free email addresses is that you can’t send any email from a Chatmail server that isn’t encrypted, so open / automatic signups works perfectly fine. Spammers can try to register accounts but they’ll never be able to do anything with them.
For reference, the threat PFS protects against is passive MITMs collecting your encrypted network traffic to try and decrypt it later.
If you use Signal while a MITM stores all your network traffic, and you delete a message locally, and later your device is seized by that MITM operator, then that deleted message is still virtually unrecoverable.
If you use Delta Chat in this same scenario, the deleted message could be recovered by the MITM operator using your seized encryption keys to decrypt the past encrypted messages they had stored.
It’s theorized that the NSA regularly stores this data. Whether that’s true and whether other agencies/countries do this as well is not really for me to say, but I can see why it would be a concern to people.
PFS just adds a greater degree of assurance that your past messages can be secured if you choose to do so, nothing to do with message history or anything client-side (indeed Signal will soon allow synchronized message history). At the same time, I know plenty of people who enable Disappearing Messages by default, which is automatically applied to both sides of a conversation.
All this being said, I am pretty convinced that decentralization is more important to some people than the benefits of PFS above, so I’m not against looking at Chatmail servers either.
Sounds like they’re planning to add PFS and PQC this year.
I think we should consider this platform. There are currently limited options for messaging apps that don’t require a phone number or email address to sign up.
Not requiring a phone number is useful for scenarios that require multiple devices or aliases, burner devices, or use usage on a laptop as a primary device.
I got a few contacts to try SimpleX but it was too complicated (maybe it’s been updated since).
Wire was good since you could create several accounts easily, and login via web browser (useful for coms over TOR). But is problematic for other reasons.
There are several that are a whole lot better than Delta Chat, like SimpleX, Session, Threema. Imho neither of them make much sense. Signal requires only a phone number to sign up.
It sounds to me like once they implement Autocrypt v2, Delta Chat will be pretty competitive with Signal (and Threema I think, although I don’t know very much about that one) for 1:1 and smaller group chats. The main thing that would be missing is their take on Sealed Sender. There’s some other problems they need to work on eventually too like group management for big groups, but they’re more usability issues.
It’s also had fewer serious bugs IME than SimpleX and Session.
EDIT: I’ve read through a bit of the spec, and apparently post-compromise security is considered a non-goal for Autocrypt v2, so that’s a negative compared to Signal (unless they’re planning to add it themselves on top of Autocrypt at some point).
IMO, if/when Autocrypt v2 is implemented, Signal, SimpleX, and Delta Chat will all essentially be first-class secure messengers, in the sense that:
- each one has a clear & distinct target demographic and use-case
- there will be only deliberate tradeoffs between them, not omissions of important security features.
(Session and Threema both fail point #1 because Session is a worse SimpleX and Threema is a worse Signal.)
Delta Chat I think is interesting because it (again with a future PFS/PQC update) seems to approach the confidentiality properties of Signal and SimpleX without relying on something like Signal’s centralized infrastructure or SimpleX’s considerably more complicated routing architecture.
The biggest concern I have with SimpleX is that despite the decentralized model I do not see how it could continue to exist without SimpleX the company behind it. Essentially all of the complexity of SimpleX is placed upon the client, to achieve important privacy properties (absolutely minimizing the metadata the servers get) at the expense of being a
Usually where federated projects shine is decentralization of the project as a whole, because different aspects of the project are delegated more appropriately. If I want to develop a Delta Chat client I don’t need to understand and implement server-side things like intra-server routing etc., and vice-versa. And if I am a user of the messaging service I do not need to be responsible for every aspect of my experience: I think this is where a lot of people stop using SimpleX because having the client itself do everything comes with a lot of UX problems that tend to drive people to Signal.
Anyways, it is basically the classic Centralized (Signal) <> Federated (Delta) <> Decentralized (SimpleX) spectrum we always end up seeing in pretty much any field, with the same benefits and tradeoffs these architectures always have. Like with Twitter/Mastodon/Nostr, or Dropbox/Nextcloud/Syncthing, etc.
Otoh the entire complexity is effectively just the equivalence of clients exchanging E2EE information between each other about what call sign will fetch the next message.
E.g. 123@jabber.com tells server that this message is for someone going by 987@jabber.com, and the previous encrypted message told the recipient to create the 987 account to fetch the next message.
The server can tie those throwaway accounts together via IP addresses so I fail to see how SimpleX notably improves upon Matrix.
Home servers also hide the user’s IP from the contacts and it requires collaboration from home servers to establish full metadata about what IPs converse. If both Matrix servers run under Akamai, it has same issues as SimpleX running those server nodes under Akamai.
The good part is changing IP address can make it harder to tie user actions in server’s end, but nation state actors can still easily tie multiple IPs to individual user and with that, hosting provider level E2E correlation reveals full metadata log between real life users.
SimpleX does reduce server side incidental collection with the E2EE queue numbers but that goes into the sealed sender category of privacy by policy, even though this is a client-side enforced feature.
Tor messenger would be the opposite: anonymous long term user IDs through decentralized network but that doesn’t know who they are unless a single deanonymization happens and then the server allows aggregating single user’s metadata.
Rotating accounts stops that surveillance and that’s the part SimpleX automates which is great but that’s like the relation between E2EE and forward secrecy: queues complement anonymity but don’t replace it. Replacing keys in TLS (non-E2EE) sure reduces what server compromise enables but it doesn’t remove the ultimate trust on server so E2EE is needed. The same way queues require anonymity to remove trust for server infrastructure.
But also notably, for both examples the extending property is of stronger notion with the more robust underpinning:
Forward secrecy of TLS is good but forward secret E2EE solves the main problem much better. Likewise the queue mechanism over anonymous accounts has really interesting effects: it solves the offline messages problem, and long term tracking problem a (de)centralized server providing offline messages would have.
The cost is the availability if pinned server goes down but it’s not a terrible trade-off especially given that anyone can host a new server, and that server won’t have access to identifying metadata if it’s offered only as an Onion Service.
That part solves the misuse problem to limited extent which isn’t quite as good as Cwtch etc in this regarde, specially due to clients support of clearnet connections.
The very least, there’s a place for Tor only fork of SimpleX for more strict threat model.
there is another angle to this - resistence to mass censorship.
signal, session, simplex (default smp servers everyone use) - all are trivially blocked. even all main public chatmail servers are blocked.
but using delta chat over goverment-approved national email services was a stable way to get in touch with people.
sure it’s probably not complicated to crack down and ban such accounts, but so far it’s flying so low under the radar that noone cares
Delta Chat also allows you to use multiple (unlimited?) Chatmail relays simultaneously, so that there is not a significant impact if one is blocked or simply goes offline, although this is a feature that I think is shared with SimpleX. I don’t quite remember how having multiple message relays works with SimpleX, I’d have to read their docs again.
they surely promised that feature a year ago, and i was really looking forward to it, coupled with a registry of community driven relays to circumvent heavy mass censorship.
I’m not sure if this has been mention already here but if I understand correctly they also want to decouple email addresses from identities. So your identity would be probably a pair of public/private keys like in Nostr and email addresses would be temporary and used only for transport. I think this is very cool but at the same time it makes me wonder if the entire email system (imap/smtp) could be just replaced with something tailored for this use case.
From: A big user surge and funding for decentralized scale - Delta Chat
Cryptographic hardening: Using e-mail addresses as transport but not as a source of identity; hiding cryptographic identities from transports; and further minimizing visibility of meta-data in messages.
Looks like they’ve made progress here in making multiple relays the default. I’ve been trying out the app since @jonah did the messages tier list.
Latest release - not sure how to test it though:
adbenitez released this yesterday
Improve resilience & decentralization: new users onboard by default in more than one relay, randomly selected, instead of using the hardcoded nine.testrun.org relay
- Improve resilience: pick random relay for sending and try others if sending with one fails, no need for manually selecting a relay “used for sending”
They have already done this for some time, your identity is your cryptographic key.
Indeed! I missed that.
A profile is a name, a picture and some additional information for encrypting messages. A profile lives on your device(s) only and uses the server only to relay messages.
EDIT: There’s also talk from FOSDEM 2026 on this topic:
One important limitation of Delta Chat right now seems to be inability to secure one’s profile with password or pin. If someone gets a copy of my profile (by exporting it when I’m away from keyboard) he can read all incoming messages without me knowing. There will be a message “Profile transferred to your second device” in the Device Messages chat but it can be removed.
There is no information in the app about other connected devices and no way to log them out. I’m not sure if they plan to address this issue.
Current Delta Chat limitations on their forum:
This unfortunately confirms my concern that it’s currently not possible to know whether there are other devices with a copy of my profile and ability to intercept all messages.