Remix.run Logo
heavyset_go a day ago

Note that while it might be decentralized and "secure", it is not anonymizing as IMAP + SMTP are far from anonymous. Email is a legacy system that was never designed with privacy or anonymity in mind.

This is useful if you want to keep the content of your messages secure, but if you need to keep your identity, social graph and the fact that you conversed with certain people obfuscated, I don't think Delta Chat via email is a good solution.

It's also only decentralized as much as public email infrastructure is decentralized.

woodruffw a day ago | parent | next [-]

I would go a step further: this is not secure. Forward secrecy and metadata privacy are table stakes in any modern secure messaging design, and Delta Chat has neither.

repeekad a day ago | parent | next [-]

Today I learned: table stakes is borrowed from poker referring to the minimum size bet needed to participate in a hand, I’ve heard it so many times

jeremyjh a day ago | parent | next [-]

That is not correct. Table stakes are not a "bet size", they are the minimum you have to bring to have a seat at the table. For example you might have to bring $300 to sit a table where the minimum bet size (big blind) is $5. You only have to bet the blinds 2 out of 10 hands (or more, if short-handed), which would be much smaller.

post_below 21 hours ago | parent [-]

As a side note, despite its popularity, Texas hold'em is just one type of poker game. In most poker games (5 draw, 7 stud, etc..) you ante every hand.

1659447091 18 hours ago | parent | prev [-]

The first N times I came across someone use "table stakes", I dyslexically read it as "table steaks". Still came to the same meaning because, yeah -- I get it -- I too would only be coming over for dinner if there are steaks at the table.

lima a day ago | parent | prev | next [-]

Source: https://delta.chat/en/help#pfs

It's basically GPG with better UX.

newsclues a day ago | parent [-]

PGP?

__MatrixMan__ a day ago | parent | next [-]

GPG is gnu privacy guard, it's an open source implementation of the same ideas that are PGP (pretty good privacy).

singpolyma3 a day ago | parent | prev | next [-]

Specifically we're supposed to call it OpenPGP these days

47282847 21 hours ago | parent [-]

There is PGP, OpenPGP, and GnuPG, and they’re all parts of a shared ecosystem but not the same. They never were, so it’s not like anything changed over time about this.

a day ago | parent | prev [-]
[deleted]
em-bee a day ago | parent | prev | next [-]

deltachat devs are working on forward secrecy. and as for metadata, as long as the messages are sent from my personal email server to the destinations email server using a TLS connection, the metadata is accessible only on those two servers. sure, if i use gmail then google has my social graph. but so do whatsapp and telegram and others. yes, more private options exist, but for example in one group of friends right now the choice now is between whatsapp and deltachat. whatsapp because most people in the group already use it. deltachat because most people already have email. signal or matrix are not under consideration.

woodruffw a day ago | parent [-]

> deltachat devs are working on forward secrecy

That’s great, but I’m not holding my breath. PGP isn’t architecturally well-equipped to provide forward secrecy. In the mean time, I think it’s borderline negligent to put this in the category of secure messaging; the world’s expectations for security baselines have moved on beyond the mid-2000s.

(My reference point here is Keybase, which built a very user-friendly and misuse-resistant encrypted chat on top of PGP in the mid-2010s. They couldn’t get to forward secrecy either with PGP as their substrate.)

> as for metadata, as long as the messages are sent from my personal email server to the destinations email server using a TLS connection, the metadata is accessible only on those two servers.

To the best of my knowledge, MTA-STS adoption rates are still abysmal[1]. It’s a move in the right direction, but this kind of shambolic jigsaw approach to communication security isn’t appropriate in 2025. Sensitive messages should go over protocols designed to carry them.

[1]: https://www.uriports.com/blog/mta-sts-survey-update-2025/

upofadown 15 hours ago | parent | next [-]

OpenPGP is a message format standard, not an architecture standard. Since they are doing a instant messaging thing, there is no particular reason they couldn't do forward secrecy. They could even do a hash ratchet and call the result a double ratchet if they really wanted to. It would probably be more reasonable to do something a bit less obsessive and just make it so that the user can more securely delete their messages in the face of device compromise in an instant messaging environment.

woodruffw 14 hours ago | parent [-]

"Architecturally" refers to the architecture of OpenPGP's message and certificate formats, not some kind of architectural standard. You can see Delta Chat's own community struggle with this[1]: unbounded certificate growth doesn't mesh well with acceptable rotation periods for ephemeral keys. There's also the problem of OpenPGP implementations encrypting to all subkeys instead of the "latest" one, which of course blows a hole in the FS property.

[1]: https://support.delta.chat/t/autocrypt-key-rotation/2936

upofadown 5 hours ago | parent [-]

The Delta Chat issue with subkeys seems to be an Autocrypt thing. Most OpenPGP implementations will encrypt with the latest encryption key.

Which brings up a point I suppose. Delta Chat is not really doing OpenPGP. They are mostly doing Autocrypt. Autocrypt was an attempt to do encrypted email without the bother of identity verification. It has always seemed like a bad idea to me. The Delta Chat project ended up adding identity verification on top of Autocrypt.

woodruffw 3 hours ago | parent [-]

They don’t seem to think it’s an Autocrypt thing; they seem to think it’s an issue with certificates being de facto append-only. Also, “most” is not acceptable —- if even a small percentage of Signal clients had this kind of FS-breaking bug it’d be considered a significant vulnerability. We should demand better than “most.”

em-bee 21 hours ago | parent | prev [-]

PGP isn’t architecturally well-equipped to provide forward secrecy

i have no insight into the development, but i suppose that swapping out PGP for something entirely different should technically be possible.

they did develop a peer to peer protocol with forward security for real-time messages that sidesteps SMTP entirely. seems a bit wierd given the premise, but the devs are at least not limiting themselves to SMTP and PGP.

woodruffw 21 hours ago | parent [-]

> but i suppose that swapping out PGP for something entirely different should technically be possible.

That would probably be good, but email is still a terrible substrate for secure messaging. Clear metadata is security poison; you want as little of it revealed to participant servers as possible.

> they did develop a peer to peer protocol with forward security for real-time messages that sidesteps SMTP entirely.

That’s great, but in that case: what’s the value proposition relative to Signal or even Matrix?

em-bee 20 hours ago | parent [-]

the peer to peer protocol at this point is only for realtime communication at which both parties have to be present. like IRC, those messages are not saved. it does not replace regular messaging which is stored. i was merely trying to point out that the developers are capable of thinking outside of the box that they started from and that deltachat may develop in a different direction. as someone else stated, deltachat's value is that it is able to reuse existing infrastructure and does not require (but allow) a new set of servers to be able to work.

woodruffw 18 hours ago | parent [-]

> i was merely trying to point out that the developers are capable of thinking outside of the box that they started from and that deltachat may develop in a different direction.

I mean this kindly: I wish they would think a little bit more inside the box, and converge onto a proven design.

(It’s worth noting that your “existing infrastructure” argument is exactly why Signal uses phone numbers. Using existing infrastructure is a great idea, so long as it doesn’t compromise the security expectations any reasonable user has. That isn’t currently true for Delta Chat.)

em-bee 4 hours ago | parent [-]

exactly why Signal uses phone numbers

the reason may be the same, but the effect is entirely different. until recently signal did not allow hiding the phone number, failing my privacy expectations. a public phone number is something entirely different than a public email address. signal is also centralized with its own servers. deltachat works completely without dedicated servers. and emails easily allow multiple accounts.

and what are reasonable security expectations? what you and i consider reasonable does not at all match what the general population expects. for most people sending encrypted emails would already be a win. (autocrypt also works with regular email clients, not just deltachat)

the goal here is to raise the general use of encryption in messages. if that is not sufficient then deltachat is not the right tool. but i have friends on telegram and whatsapp. getting them to use deltachat would be an improvement.

woodruffw 3 hours ago | parent [-]

Centralization is not a security property in the context of E2EE. You can want decentralization (I often do), but it’s essentially an ideological demand rather than a security preference when the server provably has no access to your messages or metadata.

> and what are reasonable security expectations?

End-to-end encryption that the user can’t accidentally downgrade from and that doesn’t spray valuable metadata across the Internet. That’s table stakes; I’m not interested in lowering my standards below that.

> for most people sending encrypted emails would already be a win.

I don’t think this is even remotely true. I think the average person doesn’t know what an encrypted email is. We’re now in at least the third decade of encrypted email techniques, and adoption outside of corporate S/MIME (another can of worms) is marginal.

There’s almost too much to even say here; it’s a disservice to even accept the implicit assumption that users would use encrypted email correctly if they could be made to: the single most common breakage point for all of this stuff is still people replying or forwarding previously encrypted messages in the clear!

> the goal here is to raise the general use of encryption in messages.

No. The goal is security. “General use of encryption” goes back to putting ideology before security. The goal is to actually put users in a position where adversaries struggle to collect the kinds of data and metadata that would allow them to harm people. The US famously kills people based on metadata[1], and we’re the “strict” ones in terms of evidentiary standards.

[1]: https://www.nybooks.com/online/2014/05/10/we-kill-people-bas...

em-bee 2 hours ago | parent [-]

Centralization is not a security property

true, i wasn't thinking about security here but reuse of infrastructure. signal doesn't reuse infrastructure because it needs its own servers.

End-to-end encryption that the user can’t accidentally downgrade from

that's a fair point.

that doesn’t spray valuable metadata across the Internet

i find that a gross exaggeration. yes. metadata can be read by every server the mail passes through. but in practice most mails are only touching the sending and the receiving mail server. if both of those servers are in control of the sender and recipient and the connection between them is encrypted then the metadata remains private.

also, where i use deltachat, the alternative is to use email.

I think the average person doesn’t know what an encrypted email is

which is why we need more encryption by default.

adoption outside of corporate S/MIME is marginal.

because it is to hard to use. deltachat makes it easy to use. next possible step: delta mail. a more traditional mail client that makes encryption as easy as deltachat does.

The goal is to actually put users in a position where adversaries struggle to collect the kinds of data and metadata that would allow them to harm people

there is a long road to get to that. more encryption is just one step, but a necessary one. i agree with you, but the goal can't be reached if we don't work on multiple fronts. one of those is helping people to learn about encryption and privacy, which only happens by slowly getting them to use better tools and by improving those tools.

rejecting deltachat is rejecting something that improves the current state for something better that is not obtainable by some. sometimes that makes sense, especially if the solution promises more than it holds. and deltachat would fall into this if it were to promise complete privacy. but i don't think it does that.

i have friends who outright refuse to sign up to a new service. but deltachat is ok because they can use their existing email for it. technically that sounds the same as saying that with signal you can reuse your existing phonenumber, but people already have much higher privacy expectations to sharing their phone number, and also deltachat doesn't share your email address except with recipients so it really isn't the same thing.

woodruffw 2 hours ago | parent [-]

> if both of those servers are in control of the sender and recipient and the connection between them is encrypted then the metadata remains private.

Why are we entertaining this hypothetical? It isn’t true in practice; the average user doesn’t control their mail server. The average user is using Gmail or Outlook, where their metadata is a single subpoena away.

And again, it just isn’t true: you need not just control over the server but also strict transport security for this property. This is not widely true of mail servers on the Internet.

> rejecting deltachat is rejecting something that improves the current state for something better that is not obtainable by some.

I don’t agree. I think the average user has multiple high-quality E2EE messaging technologies available to them, and that Delta Chat effectively muddies the water by providing a worse security posture with the trappings of a familiar-but-unsecurable ecosystem (email).

(I also don’t know why people think Signal shares your phone number with people other than recipients. To my knowledge, that has never been the default and presumably never will be, even with their private contact discovery protocol.)

heavyset_go a day ago | parent | prev | next [-]

I agree from that perspective.

klabb3 19 hours ago | parent | prev [-]

> Forward secrecy and metadata privacy are table stakes in any modern secure messaging design

I think this is counter-productive, limiting the adoption of meaningful security improvements. The engineering and UX implications of PFS and full metadata encryption (in particular social graphs) are severe. Not even signal has that, and they are above and beyond for a mass consumer product.

From the physical world, it’s like saying that having addresses on the letter is the same as the government opening and scanning the contents of every letter. Of course I don’t like the indiscriminate metadata collection, but there are worse things.

If you’re a spook or dissident, by all means, take extra precautions. You’re gonna need to anyway, in many more disruptive ways than your messaging app. Personally I just want to share shitposts with friends and speak freely without second guessing if I’m gonna be profiled by a data broker, or someone is gonna scan and store the pictures I send forever. Keep in mind that the status quo (Gmail, DM on social media) is incredibly bad.

tptacek 18 hours ago | parent | next [-]

No. Unless your messenger is at pains to make sure people don't use it in life-or-death situations (for instance: because they're being targeted by ICE, or the law enforcement and security apparatus of their country), the exact opposite thing is true.

These kinds of message board discussions invariably pose a dilemma: "send messages in plaintext using normal email, or use whatever secure messaging tool is available regardless of its strength". That's false. People always have a third option: not sending the message electronically. Most of us here have messages they wouldn't send even with their most trusted messaging tools; people who are at serious risk from message interception have much more dangerous messages than that.

Recommending that at-risk people use weak secure messaging as a "better than nothing" step towards real secure messaging isn't just bad advice. It's malpractice.

klabb3 3 hours ago | parent [-]

This conversation is important, and weighing these aspects against each other is critical in order to form better opinions. We clearly both agree there are subtle and counter-intuitive effects at play. I don't think there's anything wrong with debating them, and I'm happy to be convinced otherwise.

> Unless your messenger is at pains to make sure people don't use it in life-or-death situations [...] the exact opposite thing is true

Right, this is the false-sense-of-security effect. It exists and it's real. But there are more aspects that weigh in.

> People always have a third option: not sending the message electronically.

I challenge this assumption. In reality the effect is not about what they can do if they listen to the advice of Bruce Schneier, but what they will do. Navel-gazing on security and throwing your hands up if people don't act "the way they should" is what's really irresponsible, imo. I.e. if your contacts are not physically close, they won't (or even can't) schedule a flight to send a message. They'll generally use what's socially convenient, even if they're discussing something like abortion in an oppressive state. If you're lucky non-techies will say "Hey, maybe we should try that app Signal, I heard it's more secure". That's as good of a win as it gets.

The counter-example would be going around saying Signal is worthless because they collect phone numbers, they don't enforce public key validation, and they don't use onion routing to protect your social graph. I don't think we disagree about how ridiculous that would be, even if we disagree on which aspects are most important.

Basically, if set the weight of all security properties to ∞, you will get something that's so wildly inconvenient that nobody would use it. Even PGP that's relatively easy to use was at its peak about as popular as starting a yak farm.

bastawhiz 18 hours ago | parent | prev | next [-]

Metadata security isn't table stakes? I guess just pray your app's UX isn't good enough that the US Secretary of Defense decides to use it.

woodruffw 18 hours ago | parent | prev | next [-]

I don’t understand how asking for things that are bog-standard is somehow counter-productive. I think the really counter-productive thing here is flogging the dead horse of encrypted email; ordinary people deserve better than that.

> Not even signal has that, and they are above and beyond for a mass consumer product

What parts of this do you think are missing from Signal? Signal has had PFS for as long as it’s been called Signal, and has famously minuscule metadata on users.

klabb3 6 hours ago | parent | next [-]

> What parts of this do you think are missing from Signal?

The social graph isn’t e2ee in any app that works because the server needs to route the message. And the social graph is metadata.

jjav 9 hours ago | parent | prev [-]

> famously minuscule metadata

Famously minuscule? They demand a phone number, which blows up any possible anonymity story.

maqp 16 hours ago | parent | prev [-]

>Personally I just want to share shitposts with friends and speak freely without second guessing if I’m gonna be profiled by a data broker

You are welcome to live your privileged life with your privileged friends using any software you feel is good enough. Just don't assume everyone can afford that luxury.

https://pressgazette.co.uk/news/rsf-moves-downgrades-global-... is a decent index to assess in what kind of country you're living in.

SwtCyber 3 hours ago | parent | prev | next [-]

Definitely not for threat models where anonymity is critical

agnishom 16 hours ago | parent | prev | next [-]

"It's also only decentralized as much as public email infrastructure is decentralized."

That's already a lot more decentralized than most web services we use on a daily basis

woodruffw 16 hours ago | parent [-]

In what sense? I think in practice there are significantly fewer widely used email service providers than there are web service providers. If you threw a rock at a crowd of people, you'd probably hit someone with a Gmail or Outlook-managed inbox.

jjav 9 hours ago | parent [-]

> In what sense?

Email is an open interoperable standard, owned by nobody.

You can run your own email infrastructure just fine (I do, many do).

So it is fundamentally different from all the proprietary walled gardens which have a single owner that controls everything.

woodruffw 3 hours ago | parent | next [-]

Signal is notably not proprietary. And email is de-facto owned by a small handful of service providers.

Telling Joe Shmoe that he should run his own email infrastructure instead of using literally anything actually built for E2EE is an ideological argument, not one grounded in Joe’s message security expectations.

Bluestein 7 hours ago | parent | prev [-]

All of which is true and praiseworthy.-

Sadly, as with many things, Gmail effectively controls it de facto, nowadays ...

singpolyma3 a day ago | parent | prev | next [-]

It is not possible to hide the fact that you conversed with a certain person from your service provider. That's part of why being able to choose a service provider is so important.

heavyset_go a day ago | parent [-]

Theoretically, Cwtch[1] would afford you this obfuscation assuming Tor is secure and your adversary isn't nation-state level.

Similarly, using SimpleX private message routing via .onion message relays and the fact that the system has no identifiers can also afford you that obfuscation.

[1] https://docs.cwtch.im/

johnisgood a day ago | parent [-]

Differences between Cwtch, and SimpleX? Which are you leaning towards to and why?

According to https://github.com/simplex-chat/simplexmq/blob/stable/protoc...:

> identify that and when a user is using SimpleX.

Does this apply to Cwtch?

Also, is it not possible to obfsucate this traffic? Tor with obfs4?

Related:

#1 - https://security.stackexchange.com/questions/241730/traffic-...

#2 - https://github.com/simplex-chat/simplex-chat/issues/4300

#3 - https://github.com/tst-race/race-docs/blob/main/race-channel...

heavyset_go a day ago | parent [-]

> Which are you leaning towards to and why?

Heavily sandboxed SimpleX that's firewalled to block any non-Tor traffic. Chose this one because it allows for offline message sending/receiving, despite privacy implications, and because it has clients people will actually use.

Cwtch doesn't let you send messages when the recipient is offline by virtue of how it works, which is more secure, but inconvenient.

When evaluating Cwtch, I think I read somewhere it might send identifying metadata to your recipient, or something similar, but I might just be making that up. I'll have to look up what I was reading.

> > identify that and when a user is using SimpleX.

> Does this apply to Cwtch?

With Cwtch you're running two hidden services, one on either end of the chat, and that happens over Tor with no middleman service, so no. A passive network observer can tell when you're connecting to Tor, but you can attempt to obfuscate that with transports.

johnisgood 21 hours ago | parent [-]

> obfuscate that with transports.

Such as obfs4, I presume.

I read about RACE just now, seems interesting:

- https://github.com/tst-race/race-quickstart?tab=readme-ov-fi...

- https://github.com/tst-race/race-destini

Have you heard about it, or have you used it before?

> Cwtch doesn't let you send messages when the recipient is offline by virtue of how it works, which is more secure, but inconvenient.

I agree. How much more secure is that? In the case of Ricochet, this only applies to friend requests. You have to be online to be able to receive friend requests, which I am fine with.

maqp 16 hours ago | parent | next [-]

>How much more secure is that?

It's much more secure wrt metadata. There is no third party server that's able to amass metadata about the two users conversing. SimpleX doesn't hide your IP-address from the server, and given that there's exactly two parent companies hosting ALL of the official servers, it's not too hard for Akamai or https://runonflux.com/ or anyone who compromises their OOBM systems to perform end-to-end correlation between two users.

https://discuss.privacyguides.net/t/simplex-vs-cwtch-who-is-... has a lot of discussion about Simplex vs Cwtch.

heavyset_go 15 hours ago | parent [-]

Agree with your post, but do want to point out that using private message routing on SimpleX theoretically hides your IP address from the server[1].

Similarly, built-in routing over Tor can make performing correlation attacks difficult for some adversaries, and if you elect to use your own .onion servers instead of the official ones, it adds another layer of obfuscation.

[1] https://github.com/simplex-chat/simplexmq/blob/stable/protoc...

johnisgood 5 hours ago | parent [-]

What do you mean by "own .onion servers" here specifically? It is ambiguous for me. Your own hidden service? Your own bridge? As for hidden services, that would be up to SimpleX to do so (just like how Ricochet does it), otherwise I have no idea how one would do it with SimpleX or configure SimpleX to use "mine". You would need Orbot on Android to begin with to use SimpleX with Tor, and I do not know if there is such an option to "use own hidden service", as hidden services do not work this way at all.

How do you configure SimpleX on Android to use your own SMP servers BTW?

heavyset_go 16 hours ago | parent | prev [-]

> Such as obfs4, I presume.

Yep, but the author of obfs4 says not to use it, there are more modern transports with less flaws.

At the end of the day, the transport lists are public, but sharded, so it's truly just obfuscation no matter what transport protocol you use. Someone observing your connection with the resources to map out transport relays can tell if you're using Tor.

> Have you heard about it, or have you used it before?

I haven't, but it looks interesting. It seems they're doing a similar mixnet approach to SimpleX.

> I agree. How much more secure is that?

If you don't to rely on a third party to queue and relay your messages when your recipient comes online, it's one less party that you're sharing information with.

I also believe it opens you up to Tor correlation attacks, like what happened with Ricochet. Maybe an overlay mixnet can add some further obfuscation, as with SimpleX and RACE, but I assume those overlays are vulnerable to correlation attacks, as well.

johnisgood 16 hours ago | parent [-]

> Yep, but the author of obfs4 says not to use it, there are more modern transports with less flaws.

Such as?

heavyset_go 16 hours ago | parent [-]

Check out https://torproject.github.io/manual/circumvention/ and https://obfuscation.github.io/

johnisgood 5 hours ago | parent [-]

I know about those, but scramblesuit and meek and snowflake came before obfs4 I believe and they do not achieve the same thing obfs4 does, so I do not see a better obfs4 alternative here.

umanwizard a day ago | parent | prev [-]

> It's also only decentralized as much as public email infrastructure is decentralized.

So… entirely? What am I missing about your point?

heavyset_go a day ago | parent | next [-]

I run my own email servers, but 99% of mail goes over Google/Microsoft/AWS/etc email servers anyway.

In practice, it's quite centralized and you're always at risk of one of the big providers locking your servers out of their network or putting you on a blocklist they all use.

binary132 a day ago | parent | prev [-]

Public email infrastructure is almost entirely dominated by Google. This is worth looking into if you’re not familiar with the state of affairs