mirror of https://github.com/moparisthebest/xeps
Add SCE usage and remove some Signal references
This commit is contained in:
Paul Schaub
parent
5013178488
commit
c662094c6f
67
xep-0384.xml
67
xep-0384.xml
|
|
@ -1,5 +1,7 @@
|
|||
<?xml version='1.0' encoding='UTF-8'?>
|
||||
<!DOCTYPE xep SYSTEM 'xep.dtd' [
|
||||
<!ENTITY content "<content/>">
|
||||
<!ENTITY payload "<payload/>">
|
||||
<!ENTITY % ents SYSTEM "xep.ent">
|
||||
%ents;
|
||||
]>
|
||||
|
|
@ -90,21 +92,18 @@
|
|||
external complexity.
|
||||
</p>
|
||||
<p>
|
||||
This XEP defines a protocol that leverages the SignalProtocol encryption to provide
|
||||
This XEP defines a protocol that leverages the Double Ratchet Algorithm to provide
|
||||
multi-end to multi-end encryption, allowing messages to be synchronized
|
||||
securely across multiple clients, even if some of them are offline. The SignalProtocol
|
||||
is a cryptographic double ratched protocol based on work by Trevor Perrin
|
||||
and Moxie Marlinspike first published as the Axolotl protocol. While the
|
||||
protocol itself has specifications in the public domain, the
|
||||
protobuf-based wire format of the signal protocol is not fully
|
||||
documented. The signal protocol currently only exists in GPLv3-licensed
|
||||
implementations maintained by OpenWhisperSystems.
|
||||
securely across multiple clients, even if some of them are offline.
|
||||
The Double Ratched protocol is based on work by Trevor Perrin
|
||||
and Moxie Marlinspike and was first published as the Axolotl protocol.
|
||||
The specification for the protocol is available in the public domain.
|
||||
</p>
|
||||
</section2>
|
||||
<section2 topic='Overview' anchor='intro-overview'>
|
||||
<p>
|
||||
The general idea behind this protocol is to maintain separate,
|
||||
long-standing SignalProtocol-encrypted sessions with each device of each contact
|
||||
long-standing Double Ratchet-encrypted sessions with each device of each contact
|
||||
(as well as with each of our other devices), which are used as secure key
|
||||
transport channels. In this scheme, each message is encrypted with a
|
||||
fresh, randomly generated encryption key. An encrypted header is added to
|
||||
|
|
@ -125,8 +124,9 @@
|
|||
of inter-client history synchronization is achieved.
|
||||
</p>
|
||||
<p>
|
||||
OMEMO currently uses version 3 SignalProtocol. Instead of a Signal key
|
||||
server, &xep0163; (PEP) is used to publish key data.
|
||||
While in the future a dedicated key server component could be used to distribute
|
||||
key material for session creation, the current specification relies on PEP to publish
|
||||
and acquire key bundles.
|
||||
</p>
|
||||
</section2>
|
||||
</section1>
|
||||
|
|
@ -376,19 +376,36 @@
|
|||
</section2>
|
||||
<section2 topic='Sending a message' anchor='usecases-messagesend'>
|
||||
<p>
|
||||
In order to send a chat message, its <body> first has to be
|
||||
encrypted. The client MUST use fresh, randomly generated key with
|
||||
AES-256..
|
||||
The 16 bytes key and the GCM authentication tag (The tag SHOULD have at least
|
||||
128 bit) are concatenated and for each intended recipient device,
|
||||
i.e. both own devices as well as devices associated with the contact, the
|
||||
result of this concatenation is encrypted using the corresponding
|
||||
long-standing SignalProtocol session. Each encrypted payload key/authentication tag
|
||||
tuple is tagged with the recipient device's ID. The key element MUST be
|
||||
tagged with a prekey attribute set to true if a PreKeySignalMessage is being
|
||||
used. This is all serialized into a MessageElement, which is transmitted
|
||||
in a <message> as follows:
|
||||
In order to send a chat message, extension elements that are deemed sensible first have to be
|
||||
encrypted. For this purpose, extensions that are only intended to be accessible to the recipient
|
||||
are placed inside a &xep0420; &content; element, which is then encrypted using a message key.
|
||||
For this reason OMEMO defines its own SCE profile.
|
||||
</p>
|
||||
<section3 topic='SCE Profile' anchor='sce'>
|
||||
<p>
|
||||
An OMEMO SCE &content; element
|
||||
</p>
|
||||
<ul>
|
||||
<li>MUST contain an <rpad/> affix element. This is used to prevent an attacker from gaining insights about the content of a message based on the length of the ciphertext.</li>
|
||||
<li>MAY contain a <time/> affix element. This can be used to prevent the server from modifying the order in which messages from different sending devices have been sent.</li>
|
||||
<li>SHOULD contain a <from/> affix element.</li>
|
||||
<li>MUST contain a <to/> 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 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[
|
||||
<content xmlns='urn:xmpp:sce:0'>
|
||||
<payload>
|
||||
<body xmlns='jabber:client'>
|
||||
Hello World!
|
||||
</body>
|
||||
</payload>
|
||||
<rpad>...</rpad>
|
||||
<from jid='romeo@montague.lit'/>
|
||||
</content>]]>
|
||||
</example>
|
||||
<example caption="Sending a message"><![CDATA[
|
||||
<message to='juliet@capulet.lit' from='romeo@montague.lit' id='send1'>
|
||||
<encrypted xmlns='urn:xmpp:omemo:1'>
|
||||
|
|
@ -402,7 +419,9 @@
|
|||
<!-- ... -->
|
||||
</keys>
|
||||
</header>
|
||||
<payload>BASE64ENCODED</payload>
|
||||
<payload>
|
||||
-- MESSAGE-KEY-ENCRYPTED CONTENT ELEMENT --
|
||||
</payload>
|
||||
</encrypted>
|
||||
<store xmlns='urn:xmpp:hints'/>
|
||||
</message>]]></example>
|
||||
|
|
|
|||
Loading…
Reference in New Issue