omemo over discord, a draft paper
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long. 3.8KB

  1. .TL
  2. OMEMO over Discord
  3. .AU
  4. Luna Mendes
  5. .AB
  6. This paper describes what implementors could do to provide end-to-end encryption
  7. on Discord using the OMEMO standard from XMPP.
  8. This is a draft document.
  9. .AE
  10. .NH
  11. Disclaimer
  12. .PP
  13. An OMEMO session can not be fully carried out over Discord due to limitations
  14. of the Discord API. This paper goes in more detail on overcoming such
  15. limitations using a third-party.
  16. .NH
  17. Key negotiation / distribution
  18. .PP
  19. Negotiating keys and prekeys in OMEMO use the User's originating XMPP server for
  20. key storage and XEP-0163: Personal Eventing Protocol to signal device
  21. key fetches and changes.
  22. .PP
  23. Discord does not provide any semantics to what XEP-0163 provides, so
  24. implementors are allowed to improvise, and implement a generic pub/sub server.
  25. .B "However"
  26. notice that the protocol such a server provides can leak metadata about who is
  27. talking with who, and so, extra care must be given to implementations going down
  28. such paths.
  29. .PP
  30. .nr step 1 1
  31. Another approach would be leveraging existing Discord mechanics to provide key
  32. fingerprint material to the users via client profiles, however such an approach
  33. would not work because:
  34. .IP \n[step] 2
  35. The maximum size for profile entries is too low to fit key material.
  36. .IP \n+[step]
  37. Discord does not send USER_UPDATE events when those change. The client would
  38. need to send a DM to every user about the key change, so that the other users
  39. fetch the new user profile with the new keys.
  40. .NH
  41. Key verification
  42. .PP
  43. Keys must be verified out of band to prevent a MITM attack by Discord when
  44. negotiating the keys.
  45. .NH
  46. On the subject of search
  47. .PP
  48. Message search is something that is claimed to not work once you decide on using
  49. a cryptosystem, however, search is possible. There are two approaches to it:
  50. .NH 2
  51. Client-side search
  52. .PP
  53. The first one decides that the Discord Client stores the message plaintext on
  54. itself. The first obvious drawback is the overhead a client must have to do a
  55. search, and that is even more expensive when you consider the Web technologies
  56. powering the Client.
  57. .NH 2
  58. Server-side search
  59. .PP
  60. This involves a
  61. .I "separate"
  62. server that the client can send encrypted message history to.
  63. .PP
  64. When searching, the client can ask for a batch of messages, decrypt, then
  65. search through them. However the obvious drawbacks are that you need a separate
  66. server with storage, and the implied bandwidth and decryption costs of searching
  67. this way.
  68. .NH 2
  69. Conclusion
  70. .PP
  71. All XMPP clients use client-side message storage for unencrypted operation.
  72. However, due to how Discord works, users assume the storage is server-side,
  73. causing a conflict of interests in the part of what users assume Discord works
  74. onto how a theoretical OMEMO-over-Discord provider provides.
  75. .NH
  76. On the subject of JavaScript
  77. .PP
  78. Notice that all the work described here can go to waste if Discord is still able
  79. to send you maliciously crafted JavaScript for the client to execute and dump
  80. all its private keys to Discord.
  81. .PP
  82. Because of that, it is recommended to design a new client that is fully native
  83. and extensible to carry on the high expectations of a cryptosystem. "Signing
  84. a plugin" is not enough, as Discord can still send their own JavaScript that
  85. messes with the plugin's operation after signature verification.
  86. .PP
  87. The bottom line is that if you can't trust the runtime then it is not secure.
  88. Another case where this line of thought is valid is in ProtonMail, where they
  89. can send you malicious JavaScript that just records everything. ProtonMail
  90. answers that such attacks are not worrisome when we have things like SNI.
  91. .PP
  92. The author is in the "side" that if you can't trust ProtonMail from sending
  93. malicious JavaScript code, then you can't use ProtonMail. It might be more
  94. nuanced than that, considering how the client is open and "can" be "built"
  95. by people if wanted.