3 ms·
> 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
by woodruffw 1y ago
> 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/ https://www.uriports.com/blog/mta-sts-survey-update-2025/
- em-bee 1y agoPGP 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 1y ago> 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 1y agothe 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 1y ago> 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 1y agoexactly 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.
- upofadown 1y agoOpenPGP 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 1y ago"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 https://support.delta.chat/t/autocrypt-key-rotation/2936
- upofadown 1y agoThe 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 1y agoThey 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.”