Zum Inhalt der Seite gehen


Much of what is commonly said about #email and #openpgp is wrong. It can very well be fast and secure and that's a claim backed by working code and deployments and audits (#chatmail servers and the #deltachat family of apps). There is no both-sides-have-opinions game to be played here. Internet-scale messaging alternatives are arguably either centralized or brittle. There is however much room for further improvements including deep changes in how we commonly understand email today. Stay tuned :)
@Delta Chat to be fair, PGP doesn't encrypt metadata (including the subject line) and lacks perfect forward secrecy.

Still it's better than nothing.
subject lines are encrypted with delta since 2018 ;) for more info see https://delta.chat/en/help#message-metadata and the whole section around encryption.
Dieser Beitrag wurde bearbeitet. (4 Tage her)
Crosspoint had PGP-encrypted email subjects in what must have been 1992 or 93. 🤔
@Martin Schmitt #NochNieCDU @Delta Chat I'm actually surprised about that. That said, the perfect forward secrecy bit remains. Also, it doesn't do anything to mask [em]who[/em] you're communicating with (which is admittedly difficult to do).
signal also doesn't have "sealed recipients": When a client sends a message signal server knows precisely who are the recipients including their verified phone numbers.
security and privacy are in many -if not most- cases not the same. everyone needs to evaluate their own threat model and choose the tools that fit best - this often comes with a certain level of inconvenience
To be fair, we should have mentioned #xmpp as an internet scalable solution that exists and works but maybe it could be said it doesn't reach pervasive end-to-end encryption? Anyways, sorry for not incorporating its existence better in what was posted.
#xmpp
I don’t have the numbers (Maybe we can try digging some up) but my best guess is that the overwhelming majority of messages flowing through the public XMPP network are OMEMO encrypted these days. (Excluding those to and from public channels, obviously)
Yes there are clients that don’t have OMEMO but I don’t think they are responsible for a lot of the traffic.
thanks for the insight! We'll see to better phrase things in the future .... As you know we are cooperating with xmpp messenger devs and do think there are interesting things to do together ... For example, bridging with end-to-end encryption may be doable if the right people manage to sit together and sort it out.
All good. I didn’t even have any issues with your original post.
Things that have existed and evolved for 25 years are brittle.
The question is do you look at the 2-3 clients we actually recommend or everything under the sun that calls itself #XMPP.

I’m not holding Delta Chat responsible for mutt+gnupg even though it would probably be somewhat compatible.
#xmpp
That’s actually the one thing I’m most looking forward to when I can finally make Ltt.rs my primary email client: Good, native #autocrypt / #openpgp support.

The OpenPGP spec or even the libraries aren’t the problem. It’s just bad clients that treat E2EE as an afterthought.

#JMAP
Dieser Beitrag wurde bearbeitet. (4 Tage her)
if you engage there let us know if you need help. The @rpgp lib we use is top notch and security audited but autocrypt and higher level handling us in the deltachat rust core. Could be factored out into an own crate probably.
@rpgp
Agreed with the top quality of rPGP. We’re using it for our signing enclave for Arch Linux (https://gitlab.archlinux.org/archlinux/signstar) and couldn’t be happier.

Although for Ltt.rs https://pgpainless.org would probably be easier to integrate (not to mention Paul is already deeply integrated in similar circles 😉).
@rpgp fair point and great that there are multiple choices :)
@rpgp
when post quantum encryption?
No ETA, but work on post-quantum encryption for OpenPGP is in progress at https://datatracker.ietf.org/doc/draft-ietf-openpgp-pqc/, eventually it gets standardized and implemented in rPGP, so it will be possible to generate PQ keys.
it'll be interesting to see, how the OpenPGP schism plays out in the long run. Right now it looks like there might be two competing, almost identical PQC drafts, one from GnuPG (LibrePGP) and one from BSI/MTG/Proton (https://www.ietf.org/archive/id/draft-ietf-openpgp-pqc-06.html).
we are mostly engaged with OpenPGP players because this is where multi-party collaboration happens today, including advances on various specs, discussing questions etc. We experience discussions there as in good faith. People listen to each other and move jointly. The whole point of standardization is to have multi-party agreements and compliant implementations, after all.
fwiw, I'd expect the IETF OpenPGP PQC format to land in rPGP in the first half of this year