moparisthebest
/
xeps
mirror of https://github.com/moparisthebest/xeps
1
0
Fork 0
Code Issues Releases Wiki Activity

XEP-0384: define encrypted element

This commit is contained in:
Marvin W 2020-03-08 13:35:34 +01:00
parent 5e434f9334
commit 928d6ffd63
No known key found for this signature in database
GPG Key ID: 072E9235DB996F2A
1 changed files with 24 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

34
xep-0384.xml
View File

@ -400,14 +400,7 @@
<li>SHOULD contain a &lt;from/&gt; affix element.</li>
<li>MUST contain a &lt;to/&gt; affix element whenever a message is sent via a group chat (MUC/MIX). This is used to prevent the server from silently converting a group message into a private message and vice versa.</li>
</ul>
</section3>
<p>
The &content; element is encrypted as described in the section about <link url="#protocol-message_encryption">Message Encryption</link>.
</p>
<p>
The ciphertext that is the encrypted &content; element is then encoded using base64 and placed as text content into the &payload; element.
</p>
<example caption="Plaintext SCE content element"><![CDATA[
<example caption="Plaintext SCE content element"><![CDATA[
<content xmlns='urn:xmpp:sce:0'>
<payload>
<body xmlns='jabber:client'>
@ -417,8 +410,27 @@
<rpad>...</rpad>
<from jid='romeo@montague.lit'/>
</content>]]>
</example>
<example caption="Sending a message"><![CDATA[
</example>
</section3>
<section3 topic='Encryption' anchor='encrypt'>
<p>
The &content; element is encrypted as described in the section about <link url="#protocol-message_encryption">Message Encryption</link>.
The client MUST use fresh, randomly generated key AES-256 with.
The SCE &content; element is encrypted using this key (TODO)
</p>
<p>
The 32-byte AES key and the 32-byte HMAC are concatenated and the result of this concatenation is encrypted using the corresponding long-standing OMEMO session for each intended recipient device.
Clients SHOULD only consider the devices on the 'urn:xmpp:omemo:1:devices' node of each recipient (i.e. including his own devices node, but excluding itself).
</p>
</section3>
<section3 topic='Message structure description' anchor='message-structure-description'>
<p>
An OMEMO encrypted message is specified to include an the &lt;encrypted&gt; element in the 'urn:xmpp:omomo:1' namespace. It always contains two child nodes, the &lt;header&gt; and the &payload; element.
The &lt;header&gt; element has an attribute named 'sid' referencing the device id of the sending device and contains one or multiple &lt;keys&gt; elements, each with an attribute 'jid' of one recipient JID as well as one or multiple &lt;key&gt; elements.
A &lt;key&gt; element has an attribute named 'rid' referencing the device id of the recipient device. The ciphertext that is the key and HMAC encrypted using the long-standing OMEMO session for that recipient device is encoded using base64 and places as text content into the &lt;key&gt; element.
The ciphertext that is the encrypted &content; element is encoded using base64 and placed as text content into the &payload; element.
</p>
<example caption="Sending a message"><![CDATA[
<message to='juliet@capulet.lit' from='romeo@montague.lit' id='send1'>
<encrypted xmlns='urn:xmpp:omemo:1'>
<header sid='27183'>
@ -437,6 +449,7 @@
</encrypted>
<store xmlns='urn:xmpp:hints'/>
</message>]]></example>
</section3>
</section2>
<section2 topic='Receiving a message' anchor='usecases-receiving'>
<p>When an OMEMO element is received, the client MUST check whether there is a &lt;keys&gt; element with a jid attribute matching its own bare jid and an inner &lt;key&gt; element with an rid attribute matching its own device ID. If this is not the case the message was not encrypted for this particular device and a warning message SHOULD be displayed instead. If such an element exists, the client checks whether the element's contents are an OMEMOKeyExchange.</p>
@ -454,6 +467,7 @@
<p>If a OMEMOKeyExchange is received as part of a &xep0313; catch-up and used to establish a new session with the sender, the client SHOULD postpone deletion of the private key corresponding to the used PreKey until after MAM catch-up is completed. If this is done, the client MUST then also send a normal OMEMO encrypted message with an empty SCE payload before sending any payloads using this session, to trigger re-keying. (as above) This practice can mitigate the previously mentioned race condition by preventing message loss.</p>
<p>As the asynchronous nature of OMEMO allows decryption at a later time to currently offline devices client SHOULD include a &xep0334; &lt;store /&gt; hint in their OMEMO messages. Otherwise, server implementations of &xep0313; will generally not retain OMEMO messages, since they do not contain a &lt;body /&gt;</p>
<p>When a client receives the first message for a given ratchet key with a counter of 53 or higher, it MUST send a heartbeat message. Heartbeat messages are normal OMEMO encrypted messages where they SCE payload does not include any elements. These heartbeat messages cause the ratchet to forward, thus consequent messages will have the counter restarted from 0.</p>
<p>When a client receives the message from a device id that is not on the device list, it SHOULD try to retrieve that user's devices node directly to ensure their local cached version of the devices list is up-to-date.</p>
</section1>
<section1 topic='Implementation Notes' anchor='impl'>
<!-- TODO: I think this is still true? -->