Add GPG encryption

The FAQ lists XEP-0246+TLS as the preferred way to do e2e encryption (hopefully with RFC5081). That XEP, however, is deferred and not recommended for implementation. XEP-0027, however, is historical and already supported by many clients (Psi, Gajim, etc). Implementation of XEP-0246, therefore, is implementing something few (if any) others do, and which likely no one ever will (since deferred XEPs are usually replaced by something else later, and not "reactivated"), whereas implementing XEP-0027 would give telepathy-gabble users in-protocol end-to-end OpenPGP strong encryption that is immediately compatible with existing clients and practices.

*** Bug 16707 has been marked as a duplicate of this bug. ***

Realistically, I think this is WONTFIX. XEP-0027 has some pretty serious flaws, and I would rather see effort go into XTLS and/or OTR.

(In reply to comment #0)
> The FAQ lists XEP-0246+TLS as the preferred way to do e2e encryption (hopefully
> with RFC5081). That XEP, however, is deferred and not recommended for
> implementation.

XTLS, the former XEP-0246, has morphed into an Internet-Draft, <https://tools.ietf.org/html/draft-meyer-xmpp-e2e-encryption-02>. I still think this is a better approach to strong cryptography in XMPP than XEP-0027.

The reason nobody has implemented it yet is that good security is difficult. I think if it's worth doing, it's worth doing right.

OTR ("off-the-record messaging" as implemented in a Pidgin plugin) is another option: it's not as flexible as XTLS, but is considerably better than XEP-0027.

Some thoughts about the right way to do strong cryptography in XMPP, with specific reference to XTLS and OTR: <http://lists.freedesktop.org/archives/telepathy/2012-June/006122.html>

> implementing XEP-0027 would give telepathy-gabble users
> in-protocol end-to-end OpenPGP strong encryption

Let's see how that compares with the potentially-desirable security properties in my mail "Goals for end-to-end security" to the list.

Confidentiality: yes, confidentiality is provided for messages. (I seem to remember hearing that encrypting messages without also signing them is a bad idea for some obscure cryptographic reason, but I can't find a reliable reference for that, so I could be wrong.)

Integrity: no, the integrity of messages is not protected. In particular, each message is entirely separate, so a "man in the middle" can silently drop some of your messages and you'll never know. In addition, the integrity of individual messages is only protected if you violate the XEP by signing as well as encrypting.

Deniability: yes, unless you violate the XEP and sign the messages as well as encrypting them.

Non-repudiability: no, unless you violate the XEP and sign the messages as well as encrypting them. (XTLS and OTR don't provide this either. I think this is appropriate.)

Strong authentication: yes if you verify key ownership out-of-band, otherwise no.

Weak authentication: no, nothing in the XMPP connection indicates which key the peer should expect to use.

Weak anonymity: yes if you use gpg --throw-keyids, otherwise no.

Strong anonymity: yes if you use gpg --throw-keyids, otherwise no. (XTLS and OTR don't provide this either. I think this is reasonable - secure anonymity is hard.)

Replay-protection: no, even if you violate the XEP and sign the messages as well as encrypting them. (In any case, you probably don't want a signed IM saying something like "yes, I agree", without context, to be something that exists... )

Perfect forward secrecy: no, losing control of the decryption key makes all past conversations decryptable.

--------

Some other interesting features of XEP-0027:

* it signs your presence (not very usefully, since it's vulnerable to replay attacks, and I'm not at all convinced that signing presence broadcasts is even useful)

* it's incredibly verbose for IMs (there's a significant per-message overhead, w...

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/telepathy/telepathy-gabble/issues/100.