> OpenPGP is a message standard that specifically covers the offline, end to end encryption case. So the contention that it bad at other cases isn't very interesting.
There are actually some XMPP clients which offer it as an option, which you should never use when you've got OMEMO, or (OTRv4). The double ratchet protocols olm, etc are better for this usecase.
> Forward secrecy can be implemented in the OpenPGP case in way compatible with regular usage, but no one bothers. Offline encryption can be made arbitrarily secure so that it is always better to spend the time and effort on preventing the compromise in the first place. Besides, no one wants to have to immediately delete all their emails after having read them. Forward secrecy is simply not relevant for offline applications.
I was specifically talking about instant messengers, not email usecases. It's also why things like Deltachat are basically taking the worst parts of email encryption and mashing it into an instant messenger client.
I actually do PGP over XMPP these days. It is so simple that it ends up being quite reliable. So I consider it the superior protocol.
>I was specifically talking about instant messengers, not email usecases.
Forward secret PGP would be simple for an online application like instant messaging. You could just throw up a new public encryption key on the server before you delete the private key.
Deltachat also embodies some of the best parts of email encryption. Open federation based on the popular and well known SMTP standard. Encryption based on the popular and well known OpenPGP standard. Contrast with what happened with the Signal encryption protocol. OMEMO, Signal Messenger, Matrix are all entirely incompatible. Things are worse off now than they were before.
OMEMO, signal protocol and Olm (as used by Matrix) are pretty much bitwise identical. OMEMO for instance has been implemented using both libsignalprotocol and libolm.
The “incompatibility” comes from the fact that the payloads within the encryption are utterly different. It’s nothing to do with the encryption; you’d see the same thing with PGP.
How? The payload is completely defined under the base standard (RFC-4880), both the binary and ASCII protected versions. Otherwise what would be the point of a universally interoperable end to end encryption standard like OpenPGP?
> Deltachat also embodies some of the best parts of email encryption
It also embodies all of the metadata associated with it, which is still not encrypted.
> Open federation based on the popular and well known SMTP standard
and inefficient for messaging protocols, attachments are literally base64 encoded, every message includes a heap of metadata.
For transient communication you're better off installing a purpose built client with a purpose built protocol rather than trying to butcher email to do it.
This replaces the subject with "...", however if I send that email to someone who doesn't support that every email I send is going to have the same subject, making it difficult for them to easily find the "correct" email from a group. Protonmail for example doesn't support encrypted subjects.
With Matrix for example the only real metadata is room id, and flow of events (what Matrix ID is in what room). You can have rooms which are centralized to a specific server and then that's not an issue.
It will be interesting to see where P2P functionality leads in the future. https://matrix.org/blog/2021/05/06/introducing-the-pinecone-... I think with any long-term identity, it's going to be trackable to some extent, so that is up to specific threat model, whether you get worried about that.
With Signal and Sealed Sender https://signal.org/blog/sealed-sender/ even less metadata is available, although this centralized model is not without downsides such as being operated by a single entity.
> Yeah, the world definitely needs more "purpose built" protocols...
With protocols like olm, you also have concept of different devices, device keys, which can be revoked, and shifted without having to ditch all your keys at once. Cross signing means new devices can be "trusted".
It's an overly complicated protocol, https://latacora.micro.blog/2019/07/16/the-pgp-problem.html which has no place in an instant messenger protocol..
There are actually some XMPP clients which offer it as an option, which you should never use when you've got OMEMO, or (OTRv4). The double ratchet protocols olm, etc are better for this usecase.
There is also MLS https://en.wikipedia.org/wiki/Messaging_Layer_Security which is looking to become an IETF standard.
> Forward secrecy can be implemented in the OpenPGP case in way compatible with regular usage, but no one bothers. Offline encryption can be made arbitrarily secure so that it is always better to spend the time and effort on preventing the compromise in the first place. Besides, no one wants to have to immediately delete all their emails after having read them. Forward secrecy is simply not relevant for offline applications.
I was specifically talking about instant messengers, not email usecases. It's also why things like Deltachat are basically taking the worst parts of email encryption and mashing it into an instant messenger client.