Document the unknown key-share attacks and mitigation (#29)

docs/olm.rst

@@ -298,6 +298,37 @@ and the IV :math:`AES\_IV_{i,j}` to give the cipher-text, :math:`X_{i,j}`.
 Then the entire message (including the Version Byte and all Payload Bytes) are
 passed through HMAC-SHA-256. The first 8 bytes of the MAC are appended to the message.
 
+Message authentication concerns
+-------------------------------
+
+To avoid unknown key-share attacks, the application must include identifying
+data for the sending and receiving user in the plain-text of (at least) the
+pre-key messages. Such data could be a user ID, a telephone number;
+alternatively it could be the public part of a keypair which the relevant user
+has proven ownership of.
+
+.. admonition:: Example attacks
+
+   1. Alice publishes her public Curve25519 identity key, :math:`I_A`. Eve
+      publishes the same identity key, claiming it as her own. Bob downloads
+      Eve's keys, and associates :math:`I_A` with Eve. Alice sends a message to
+      Bob; Eve intercepts it before forwarding it to Bob. Bob believes the
+      message came from Eve rather than Alice.
+
+      This is prevented if Alice includes her user ID in the plain-text of the
+      pre-key message, so that Bob can see that the message was sent by Alice
+      originally.
+
+   2. Bob publishes his public Curve25519 identity key, :math:`I_B`. Eve
+      publishes the same identity key, claiming it as her own. Alice downloads
+      Eve's keys, and associates :math:`I_B` with Eve. Alice sends a message to
+      Eve; Eve cannot decrypt it, but forwards it to Bob. Bob believes the
+      Alice sent the message to him, wheras Alice intended it to go to Eve.
+
+      This is prevented by Alice including the user ID of the intended recpient
+      (Eve) in the plain-text of the pre-key message. Bob can now tell that the
+      message was meant for Eve rather than him.
+
 IPR
 ---