Difference between revisions of "XMPP E2E Security"

From XMPP WIKI
Jump to navigation Jump to search
m (Add a link I left out for AUthenticity)
(Remove useless column; of course they all work for chats. If we ever have one that doesn't we can add this back.)
Line 30: Line 30:
!colspan="5" |Security property
!colspan="5" |Security property
!colspan="2" |Communication patterns
!colspan="2" |Communication patterns
!colspan="4" |Compatibility with XMPP
!colspan="3" |Compatibility with XMPP
|-
|-
![https://en.wikipedia.org/wiki/Digital_signature#Authentication Authenticity]
![https://en.wikipedia.org/wiki/Digital_signature#Authentication Authenticity]
Line 39: Line 39:
!One-to-One
!One-to-One
!Groupchat
!Groupchat
!Online chats
!Offline messages
!Offline messages
!Multiple resources
!Multiple resources
Line 52: Line 51:
|Yes
|Yes
|Yes (with limitations)
|Yes (with limitations)
|Yes
|Yes
|Yes
|Yes
|Yes
Line 65: Line 63:
|Yes
|Yes
|No
|No
|Yes
|Yes
|Yes
|Yes (if same keypair at all resources)
|Yes (if same keypair at all resources)
Line 78: Line 75:
|Yes
|Yes
|No
|No
|Yes
|No
|No
|No
|No

Revision as of 19:01, 16 October 2018

This page aims to provide an overview, comparison and evaluation of existing and proposed end-to-end security solutions for XMPP, after providing the characteristings of the XMPP setting with regard to communication and the security of it.

Proposals

XEP-0384: OMEMO Encryption (Signal / Text Secure)

Recommendation: Implement.

OMEMO is based on the Signal double ratchet and provides forward secrecy, compatibility with history retrieval for devices that are already part of the ratchet, and a number of other benefits over legacy encryption mechanisms. It has had an independent third party audit (see related links at bottom).

XEP-0027 (legacy PGP)

Recommendation: do not implement unless compatibility with legacy clients is required.

One of the first proposals for end-to-end security is based on PGP and described in XEP-0027.

The way XEP-0027 uses PGP, it doesn't provide protection from replay attacks. It also only encrypts messages and doesn't sign them, so they could be replaced with different correctly encrypted messages on the wire.(Source: chat in xsf@m.x.o) Thus it has been obsoleted by the XMPP Council in it's meeting on 2014-03-12.

OTR (Off-the-record Messaging)

Recommendation: do not implement unless compatibility with legacy clients is required. .

OTR is a crypto protocol, specifically designed to secure instant messaging conversations. Its usage in XMPP is documented (but not standardized) in https://xmpp.org/extensions/xep-0364.html

Comparative Overview

Proposal Security property Communication patterns Compatibility with XMPP
Authenticity Integrity Encryption Forward secrecy Malleability One-to-One Groupchat Offline messages Multiple resources Discovery of support
OMEMO (XEP-0384) Yes ? Yes Yes ? Yes Yes (with limitations) Yes Yes Yes
Legacy PGP (XEP-0027) No (messages only encrypted, not signed) No Yes No N/A Yes No Yes Yes (if same keypair at all resources) No
OTR Yes Yes Yes Yes Yes Yes No No No No

Related Documents

Discussion

If you have any questions or comments regarding this page, please join the XSF chatroom at xsf@muc.xmpp.org.