4 ms·

I was so annoyed at all the misleading stuff in "The PGP Problem" that I did a deconstruction: * https://articles.59.ca/doku.php?id=pgpfan:tpp https://articles

I was so annoyed at all the misleading stuff in "The PGP Problem" that I did a deconstruction: * https://articles.59.ca/doku.php?id=pgpfan:tpp https://articles.59.ca/doku.php?id=pgpfan:tpp 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.

dngray 5y ago
> 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.
- upofadown 5y ago
  >It also embodies all of the metadata associated with it, which is still not encrypted. How is this worse than any system that depends on a server that routes messages? Like almost all of them... >For transient communication you're better off installing a purpose built client with a purpose built protocol... Yeah, the world definitely needs more "purpose built" protocols...
  - dngray 5y ago
    > How is this worse than any system that depends on a server that routes messages? Like almost all of them... Not in the same way that email does. Email metadata is much more extensive than that of say Matrix. If we look at metadata, often the subject isn't encrypted and ugly UX hacks then are made like https://tools.ietf.org/html/draft-autocrypt-lamps-protected-headers-02 https://tools.ietf.org/html/draft-autocrypt-lamps-protected-... 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-overlay-network 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/ 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. We discuss in quite some depth https://www.privacyguides.org/real-time-communication/ https://www.privacyguides.org/real-time-communication/ > 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".
Arathorn 5y ago
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.
- upofadown 5y ago
  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?

dngray 5y ago

> 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.

upofadown 5y ago
>It also embodies all of the metadata associated with it, which is still not encrypted. How is this worse than any system that depends on a server that routes messages? Like almost all of them... >For transient communication you're better off installing a purpose built client with a purpose built protocol... Yeah, the world definitely needs more "purpose built" protocols...
- dngray 5y ago
  > How is this worse than any system that depends on a server that routes messages? Like almost all of them... Not in the same way that email does. Email metadata is much more extensive than that of say Matrix. If we look at metadata, often the subject isn't encrypted and ugly UX hacks then are made like https://tools.ietf.org/html/draft-autocrypt-lamps-protected-headers-02 https://tools.ietf.org/html/draft-autocrypt-lamps-protected-... 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-overlay-network 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/ 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. We discuss in quite some depth https://www.privacyguides.org/real-time-communication/ https://www.privacyguides.org/real-time-communication/ > 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".

Arathorn 5y ago

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.

upofadown 5y ago
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?