If you haven't read this article please do. I couldn't help but admit to myself that choosing open platforms / specs like #email and #DeltaChat was the best decision ever 馃摟

Keeping platforms open seirdy.one/2021/02/23/keeping- przez @wallabagapp

@avalos @michal While Delta Chat is quite an 鈥渙pen鈥 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 鈥渨eakest 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鈥檛 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鈥揑 make use of its abilities here every day鈥揵ut 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 autocrypt.org

@delta @michal @avalos Okay there鈥檚 a lot to unpack here.

  1. Lots of things are IETF protocols, but that doesn鈥檛 automatically make them secure. The IETF is actually working on a better solution than PGP for messaging, called Messaging Layer Security (MLS); here鈥檚 the 12th draft.
  2. 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.
  3. The existence of a Rust implementation of a protocol does not mean the protocol itself is a more secure option.
  4. I don鈥檛 know what you mean when you say 鈥淔orward 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.
  5. 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 鈥渨orked鈥 for Snowden in that his email bodies weren鈥檛 decryptable; however, the fact that PGP isn鈥檛 broken isn鈥檛 the same thing as saying PGP is nearly as good as other alternatives. Finally, there鈥檚 threat modelling: Snowden鈥檚 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鈥檛 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 countermitm.readthedocs.io/en/

@delta @Seirdy I agree that forward secrecy (for example via double ratchet) would've been awesome 鈾
@delta @Seirdy This is not about MITM. Instead, the fear without forward secrecy is that once my key is cracked, the entire archive of sent emails will be. That's what forward secrecy prevents.
(Not to lecture the @delta team nor @Seirdy . Just as a PSA for all ya lurkers out there about the life-changing magic of forward secrecy.)
@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
Sign in to participate in the conversation
Mastodon 馃悩

A general-purpose Mastodon server with a 1000 character limit.