initial commit
This commit is contained in:
commit
c941bee2c6
3 changed files with 125 additions and 0 deletions
1
.gitignore
vendored
Normal file
1
.gitignore
vendored
Normal file
|
|
@ -0,0 +1 @@
|
||||||
|
*.pdf
|
||||||
2
Makefile
Normal file
2
Makefile
Normal file
|
|
@ -0,0 +1,2 @@
|
||||||
|
all:
|
||||||
|
groff -ms omemo-discord.ms -T pdf > omemo-discord.pdf
|
||||||
122
omemo-discord.ms
Normal file
122
omemo-discord.ms
Normal file
|
|
@ -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 a new issue