OMEMO support

[nesium]

Aparte seems to have added support for this in the past so we might have a look there.

• XEP-xxxx: OMEMO Media sharing
• ImageDownloader: Downloads encrypted images from HTTP Host

The outstanding tasks, roughly…

• [x] Build session before sending a message instead of on startup (https://xmpp.org/extensions/xep-0384.html#rules)
• [ ] Handle failures when starting a session: Failed to start OMEMO session with [email protected]'s device 593776093. Reason: JsEncryptionService threw an error: JsValue(Error: Identity key changed
• [x] Subscribe to PubSub Node for new devices
• [x] Start session when new devices come online
• [x] When a PEP update of the own device list is received, check whether the own device is included (XEP-0384):

  This step presents the risk of introducing a race condition: Two devices might simultaneously try to announce themselves, unaware of the other's existence. The second device would overwrite the first one. To mitigate this, devices MUST check that their own device id is contained in the list whenever they receive a PEP update from their own account. If they have been removed, they MUST reannounce themselves.

• [ ] MAM Catchup:

  If an OMEMOKeyExchange is received as part of a message catch-up mechanism (like Message Archive Management (XEP-0313) [5]) 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 the catch-up is completed. If this is done, the client MUST send an OMEMO encrypted message with empty SCE payload right after the key exchange is completed, to forward the ratchet and to move away from the possibly double-used PreKey. This practice can mitigate the previously mentioned race condition by preventing message loss.

• [ ] Reset sessions:

  OMEMO's forward secrecy and backup/restore mechanisms don't play well together. Restoring old data can lead to desynchronized, "broken" sessions. Because these cases exist, clients MUST offer a way to manually replace broken sessions. It is advisable to have a session replacement option per recipient/per chat, if applicable. Otherwise, at least an application-global session reset MUST be available.

• [ ] Send heartbeat messages:

  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 empty OMEMO messages as per Sending a message. These heartbeat messages cause the ratchet to forward, thus consequent messages will have the counter restarted from 0.

• [x] Handle unknown Device ID:

  When a client receives a 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.

• [ ] Disable OMEMO globally:

  When the user of a client deactivates OMEMO for an account or globally, the client SHOULD delete the corresponding bundles and device ids from the PEP nodes. That way other clients should stop encrypting for that account.

• [x] Handle empty OMEMO messages:

  A special case are empty OMEMO messages, which are used in various places throughout the protocol purely to manage sessions and not to transfer content. With empty OMEMO messages, the step of creating and encrypting the <payload/> element is skipped. Instead of encrypting the key and authentication tag of the <payload/> ciphertext with the Double Ratchet session, 32 zero-bytes are encrypted with the Double Ratchet session directly. The resulting OMEMOKeyExchange or OMEMOAuthenticatedMessage are put into <key> elements as usual, but the <payload/> element is omitted altogether, so that the <encrypted> element only contains a <header>.

• [x] Encrypt message updates (reactions as well?)
• [ ] Allow managing devices & bundles (delete the invalid ones for [email protected])
• [ ] Support OMEMO in groups and private channels as well (introduce "Private Group")
• [ ] Encrypt files as well?
• [ ] Provide data to JS bindings so that we can show a contact's devices, their fingerprint and let our user verify them