Requirements on encryption change from time to time. New technologies pop up and crypto protocols get replaced by new ones. There are also different use-cases that require different encryption techniques.
For that reason there is a number of encryption protocols specified for XMPP, amongst them OMEMO and OpenPGP for XMPP.
Most crypto protocols share in common, that they all aim at encrypting certain parts of the message that is being sent, so that only the recipient(s) can read the encrypted content.
OMEMO is currently only capable to encrypt the messages body. For that reason the body of the message is being encrypted and stored in a <payload/> element, which is added to the message. This is inconvenient, as it makes OMEMO quite inflexible. The protocol cannot be used to secure arbitrary extension elements, which might contain sensitive content as well.
<message to='juliet@capulet.lit' from='romeo@montague.lit' id='send1'>
<encrypted xmlns='eu.siacs.conversations.axolotl'>
<header>...</header>
<!-- the payload contains the encrypted content of the body -->
<payload>BASE64ENCODED</payload>
</encrypted>
</message>The modern OpenPGP for XMPP XEP also uses <payload/> elements, but to transport arbitrary extension elements. The difference is, that in OpenPGP, the payload elements contain the actual payload as plaintext. Those <payload/> elements are embedded in either a <crypt/> or <signcrypt/> element, depending on whether or not the message will be signed and then passed through OpenPGP encryption. The resulting ciphertext is then appended to the message element in form of a <openpgp/> element.
<signcrypt xmlns='urn:xmpp:openpgp:0'>
<to jid='juliet@example.org'/>
<time stamp='...'/>
<rpad>...</rpad>
<payload>
<body xmlns='jabber:client'>
This is a secret message.
</body>
</payload>
</signcrypt>
<!-- The above element is passed to OpenPGP and the resulting ciphertext is included in the actual message as an <openpgp/> element -->
<message to='juliet@example.org'>
<openpgp xmlns='urn:xmpp:openpgp:0'>
BASE64_OPENPGP_MESSAGE
</openpgp>
</message>Upon receiving a message containing an <openpgp/> element, the receiver decrypts the content of it, does some verity checks and then replaces the <openpgp/> element of the message with the extension elements contained in the <payload/> element. That way the original, unencrypted message is constructed.
The benefit of this technique is that the <payload/> element can in fact contain any number of arbitrary extension elements. This makes OpenPGP for XMPPs take on encrypting message content way more flexible.
A logical next step would be to take OpenPGP for XMPPs <payload/> elements and move them to a new XEP, which specifies their use in a unified way. This can then be used by OMEMO and any other encryption protocol as well.
The motivation behind this is, that it would broaden the scope of encryption to cover more parts of the message, like read markers and other metadata.
It could also become easier to implement end-to-end encryption in other scenarios such as Jingle file transfer. Even though there is Jingle Encrypted Transports, this protocol only protects the stream itself and leaves the metadata such as filename, size etc. in the clear. A unified <encrypted/> element would make it easier to encrypt such metadata and could be the better approach to the problem.
4 responses to “Unified Encrypted Payload Elements for XMPP”
This sounds like a good idea and is definitely needed for xmpp.
It is of utmost importance for XMPP to reduce the amount of (cleartext) metadata accumulating on all those federated servers.
thank you for sharing
[…] Schaub a écrit à propros de la nouvelle XEP “OpenPGP for XMPP” pour expliquer comment elle résoud le problème du chiffrement de n’importe quel élément des messages, et par conséquent surpasse certaines limitations d’OMEMO qui ne peut chiffrer que le corps du […]
I was try hard to understand, but its too difficult to me..
(I was the type of person who need a teacher to explain me directly..