initial commit
This commit is contained in:
commit
c941bee2c6
|
|
@ -0,0 +1 @@
|
|||
*.pdf
|
||||
|
|
@ -0,0 +1,2 @@
|
|||
all:
|
||||
groff -ms omemo-discord.ms -T pdf > omemo-discord.pdf
|
||||
|
|
@ -0,0 +1,122 @@
|
|||
.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.
|
||||
|
||||
.NH
|
||||
Key negotiation / distribution
|
||||
|
||||
.PP
|
||||
Negotiating keys and prekeys in OMEMO use the User's originating XMPP server and
|
||||
XEP-0163: Personal Eventing Protocol to signal device key 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
|
||||
The second approach is leveraging the existing Discord protocol to provide, at
|
||||
least, key fingerprint material. Such an approach
|
||||
.I "could"
|
||||
involve the existing user profiles, and the fact that you can make a League of
|
||||
Legends entry without verification. USER_UPDATE events would be dispatched
|
||||
when such device keys change.
|
||||
|
||||
.PP
|
||||
If implementations go down the second approach, they could embed the key
|
||||
material inside the entries as well, but that might prove itself difficult,
|
||||
as there is a limit to how much you can insert on an entry. Same thing applies
|
||||
to the key fingerprints. Implementations should consider compressing. They
|
||||
should also consider a separate key server to give keys based on the key
|
||||
fingerprints so conversation can carry on.
|
||||
|
||||
.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.
|
||||
Loading…
Reference in New Issue