122 lines
3.8 KiB
Text
122 lines
3.8 KiB
Text
.TL
|
|
OMEMO over Discord
|
|
|
|
.AU
|
|
Luna Mendes
|
|
|
|
.AB
|
|
This paper describes what implementors could do to provide end-to-end encryption
|
|
on Discord using the OMEMO standard from XMPP.
|
|
|
|
This is a draft document.
|
|
.AE
|
|
|
|
.NH
|
|
Disclaimer
|
|
|
|
.PP
|
|
An OMEMO session can not be fully carried out over Discord due to limitations
|
|
of the Discord API. This paper goes in more detail on overcoming such
|
|
limitations using a third-party.
|
|
|
|
.NH
|
|
Key negotiation / distribution
|
|
|
|
.PP
|
|
Negotiating keys and prekeys in OMEMO use the User's originating XMPP server for
|
|
key storage and XEP-0163: Personal Eventing Protocol to signal device
|
|
key fetches and changes.
|
|
|
|
.PP
|
|
Discord does not provide any semantics to what XEP-0163 provides, so
|
|
implementors are allowed to improvise, and implement a generic pub/sub server.
|
|
.B "However"
|
|
notice that the protocol such a server provides can leak metadata about who is
|
|
talking with who, and so, extra care must be given to implementations going down
|
|
such paths.
|
|
|
|
.PP
|
|
.nr step 1 1
|
|
Another approach would be leveraging existing Discord mechanics to provide key
|
|
fingerprint material to the users via client profiles, however such an approach
|
|
would not work because:
|
|
|
|
.IP \n[step] 2
|
|
The maximum size for profile entries is too low to fit key material.
|
|
|
|
.IP \n+[step]
|
|
Discord does not send USER_UPDATE events when those change. The client would
|
|
need to send a DM to every user about the key change, so that the other users
|
|
fetch the new user profile with the new keys.
|
|
|
|
.NH
|
|
Key verification
|
|
|
|
.PP
|
|
Keys must be verified out of band to prevent a MITM attack by Discord when
|
|
negotiating the keys.
|
|
|
|
.NH
|
|
On the subject of search
|
|
|
|
.PP
|
|
Message search is something that is claimed to not work once you decide on using
|
|
a cryptosystem, however, search is possible. There are two approaches to it:
|
|
|
|
.NH 2
|
|
Client-side search
|
|
|
|
.PP
|
|
The first one decides that the Discord Client stores the message plaintext on
|
|
itself. The first obvious drawback is the overhead a client must have to do a
|
|
search, and that is even more expensive when you consider the Web technologies
|
|
powering the Client.
|
|
|
|
.NH 2
|
|
Server-side search
|
|
|
|
.PP
|
|
This involves a
|
|
.I "separate"
|
|
server that the client can send encrypted message history to.
|
|
|
|
.PP
|
|
When searching, the client can ask for a batch of messages, decrypt, then
|
|
search through them. However the obvious drawbacks are that you need a separate
|
|
server with storage, and the implied bandwidth and decryption costs of searching
|
|
this way.
|
|
|
|
.NH 2
|
|
Conclusion
|
|
|
|
.PP
|
|
All XMPP clients use client-side message storage for unencrypted operation.
|
|
However, due to how Discord works, users assume the storage is server-side,
|
|
causing a conflict of interests in the part of what users assume Discord works
|
|
onto how a theoretical OMEMO-over-Discord provider provides.
|
|
|
|
.NH
|
|
On the subject of JavaScript
|
|
|
|
.PP
|
|
Notice that all the work described here can go to waste if Discord is still able
|
|
to send you maliciously crafted JavaScript for the client to execute and dump
|
|
all its private keys to Discord.
|
|
|
|
.PP
|
|
Because of that, it is recommended to design a new client that is fully native
|
|
and extensible to carry on the high expectations of a cryptosystem. "Signing
|
|
a plugin" is not enough, as Discord can still send their own JavaScript that
|
|
messes with the plugin's operation after signature verification.
|
|
|
|
.PP
|
|
The bottom line is that if you can't trust the runtime then it is not secure.
|
|
Another case where this line of thought is valid is in ProtonMail, where they
|
|
can send you malicious JavaScript that just records everything. ProtonMail
|
|
answers that such attacks are not worrisome when we have things like SNI.
|
|
|
|
.PP
|
|
The author is in the "side" that if you can't trust ProtonMail from sending
|
|
malicious JavaScript code, then you can't use ProtonMail. It might be more
|
|
nuanced than that, considering how the client is open and "can" be "built"
|
|
by people if wanted.
|