Add GPG encryption

Bug #348082 reported by Aigars Mahinovs on 2009-03-24
138
This bug affects 25 people
Affects Status Importance Assigned to Milestone
Empathy
Unknown
Wishlist
telepathy-gabble
Confirmed
Medium
empathy (Ubuntu)
Wishlist
Unassigned
telepathy-gabble (Ubuntu)
Wishlist
Unassigned

Bug Description

Binary package hint: empathy

A mayor feature that keeps a bunch of people migrating to Empathy from Psi is the GPG encrypted and signed messages and status updates, conformant to XEP-0027: http://xmpp.org/extensions/xep-0027.html

jaduncan (jaduncan) wrote :

This is clearly wishlist.

Jonathan Davies (jpds) on 2009-04-03
Changed in empathy (Ubuntu):
importance: Undecided → Wishlist
status: New → Triaged
Jonathan Davies (jpds) wrote :

This has been reported upstream at: http://bugzilla.gnome.org/show_bug.cgi?id=564802

Changed in empathy:
status: Unknown → New
summary: - Need GPG encryption in Empathy
+ Add GPG encryption
neuromancer (neuromancer) wrote :

As reported in the upstream (https://bugzilla.gnome.org/show_bug.cgi?id=564802) I think that this bug would be closed, because is GPG encryption need to be implemented in the XMPP protocol

Changed in empathy (Ubuntu):
status: Triaged → Invalid
Changed in empathy:
status: New → Invalid
Changed in empathy:
importance: Unknown → Wishlist
status: Invalid → Unknown

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.

Vish (vish) wrote :

This bug is an upstream one and it would be quite helpful if somebody experiencing it could send the bug the to the people writing the software. You can learn more about how to do this for various upstreams at https://wiki.ubuntu.com/Bugs/Upstream .
Once submitted upstream , do report back here with the upstream bug number.Thanks in advance!

Changed in telepathy-gabble (Ubuntu):
importance: Undecided → Wishlist
status: New → Confirmed
Changed in telepathy-gabble:
importance: Undecided → Unknown
status: New → Unknown
Vish (vish) wrote :

Thanks for finding the upstream bug report.

Changed in telepathy-gabble (Ubuntu):
status: Confirmed → Triaged

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

Changed in telepathy-gabble:
importance: Unknown → Wishlist
Changed in telepathy-gabble:
status: Unknown → Invalid
discont (discont) wrote :

Upstream: https://bugs.freedesktop.org/show_bug.cgi?id=30419

I think it'll never happen. Use Gajim.

discont (discont) on 2011-11-01
Changed in telepathy-gabble:
importance: Wishlist → Unknown
status: Invalid → Unknown
Download full text (3.3 KiB)

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

Read more...

Changed in telepathy-gabble:
importance: Unknown → Medium
status: Unknown → Confirmed
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.