commit c941bee2c653d06e73aeeb27cdc87f9d8e32719e
Author: Luna <git@l4.pm>
Date:   Wed Mar 13 01:08:34 2019 -0300

    initial commit

diff --git a/.gitignore b/.gitignore
new file mode 100644
index 0000000..a136337
--- /dev/null
+++ b/.gitignore
@@ -0,0 +1 @@
+*.pdf
diff --git a/Makefile b/Makefile
new file mode 100644
index 0000000..ae496a9
--- /dev/null
+++ b/Makefile
@@ -0,0 +1,2 @@
+all:
+	groff -ms omemo-discord.ms -T pdf > omemo-discord.pdf
diff --git a/omemo-discord.ms b/omemo-discord.ms
new file mode 100644
index 0000000..5de88c3
--- /dev/null
+++ b/omemo-discord.ms
@@ -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.