@avalos @michal While Delta Chat is quite an “open” platform, I would not recommend it because its PGP-based encryption is not as good as Matrix/XMPP+OMEMO, let alone Signal. PGP lacks some critical features for IM platforms such as perfect forward secrecy and channel binding. PGP also has a host of other issues, including a preference for extension rather than versioning resulting in insecure configurations among “weakest link” members of chats. Authentication is also flawed: without DNSSEC, authentication is weak and tied entirely to flawed PGP.

So Delta is open but openness/freedom isn’t all that matters: security does too. I imagine that cryptographers are an underrepresented slice of its user population.

Email is excellent for public forum-like discussion–I make use of its abilities here every day–but not the best tool for secure/private messaging.

@Seirdy @avalos I was vaguely aware of this aspect of Delta Chat so thanks for clarifying. But... what if I set up an email server just for a group of friends so that the messages won't even leave the server. Will it be more secure?
I realize that a private Matrix server would be a better solution but we're talking about non-technical people. Also, they might want to use the said email in different contexts. So having an extra email account would be more practical, wouldn't it?

@michal @avalos Sound encryption should eliminate trust in the server; your friends should be able to DM each other without you knowing.

If everyone is sharing a server, there's no need for federation; you can use something like the full centralized Signal protocol to keep even the metadata private.

@Seirdy @michal @avalos note that PGP is an IETF protocol (and we have small security-audited engine in Rust for it) while Forward Security is a app feature. Messengers supporting FS do not interoperate with each other leading to silos and centralization. FWIW the likes of Snowden used PGP for their secure communications so it's maybe better to not reject it wholly :) Delta Chat uses a minimal specified subset of PGP to reduce attack surfaces and confusion, namely https://autocrypt.org

@delta @michal @avalos Okay there’s a lot to unpack here.

Lots of things are IETF protocols, but that doesn’t automatically make them secure. The IETF is actually working on a better solution than PGP for messaging, called Messaging Layer Security (MLS); here’s the 12th draft.
Messengers supporting FS do absolutely interoperate. XMPP+OMEMO supports (admittedly weak) forward secrecy, and Matrix uses the OLM protocol which also supports it. Good TLS 1.2 cipher suites and all of TLS 1.3 support FS as well.
The existence of a Rust implementation of a protocol does not mean the protocol itself is a more secure option.
I don’t know what you mean when you say “Forward Security is an app feature”. Forward Secrecy is a property of key-agreement protocols, used in plenty of open protocols including HTTPS with modern TLS.
The Double Ratchet Algorithm did not exist in 2012-2013, while Snowden was doing his thing. Snowden endorsed Signal in its early days and continues to do so because its cryptography is top-notch. Yes, PGP “worked” for Snowden in that his email bodies weren’t decryptable; however, the fact that PGP isn’t broken isn’t the same thing as saying PGP is nearly as good as other alternatives. Finally, there’s threat modelling: Snowden’s goal was to leak info and get to safety even if it meant putting in serious effort, not hide his trail indefinitely with minimal effort.

Autocrypt helps solve the fact that PGP is unversioned and extensible instead of versioned and iterable, true. Some form of cross-client negotiation of autocrypt versions could make this a useful improvement, but it wouldn’t address the other issues.

@Seirdy @michal @avalos "Messengers supporting FS do absolutely interoperate" -- you can't mean that Signal, Whatsapp and Matrix are interoperable (and whether they implement MLS with interop between messengers needs to be seen) or do you? You are right that it's more precise to talk about FS in messengers and not FS in general. However, we do not share the view that FS in messengers is a must-have feature.

@delta @michal @avalos On the Matrix side: GNOME Fractal, FluffyChat, Gomuks, Element Web, and Nheko absolutely do interoperate because I use multiple accounts on four of those five clients regularly, from two different Matrix server implementations (Synapse and Conduit) developed by different teams; I've talked to Dendrite (a third Matrix server implementation) users too. I'm planning on giving KDE's new client (NeoChat) a spin once the e2ee branch gets merged.

On the XMPP side, the same thing is true: many client and server implementations interoperate.

Email clients/servers interoperate if they use the same protocols (the autocrypt subset of PGP, SMTP, IMAP, perhaps DANE if you call that a protocol). The same is true for Matrix and XMPP, because these are open platforms.

You can add FS to a closed platform too, as Signal/WhatsApp/etc have done. The math involved doesn't really care about the openness of the platform or lack thereof.

@delta @avalos @michal I also do absolutely think FS is essential for messengers, as the confidentiality of an e2ee thread should not require all parties to trust long-term keys, sometimes indefinitely. It creates an extra mandatory source of trust per person. FS gives all users the ability to have one less secret to keep forever to secure all their chat history.

Long-lived keys are okay for signing a release and great for encrypting a backup, but make for a poorly designed e2ee messaging protocol.

@Seirdy @michal @avalos Thanks for detailing your expert view and considerations. Maybe one day Delta chat will grow FS but for now, it's not a primary concern for several reasons. We are rather focusing on preventing active attacks in a useable way, using the "countermitm" protocols which we are still evolving https://countermitm.readthedocs.io/en/latest/new.html

@Seirdy @michal @delta @avalos PGP is not really the probleme, FS kind of but since PGP is automated away it can be solved. The real problem is that From: and To: must remain in cleartext and the body might be in cleartext by mistake because compatibility. Compatibility is a valuable goal, and one might argue it's not possible to switch without it. But it's a bit early to compare overall security while compatibility is a goal. The day Autocrypt can do what it wants with no concern for mail standards, we can talk