Encryption for message relationships

[uhoreg]

Event relationships are currently sent unencrypted so that they may be aggregated server-side. However, they may contain information that we do not want to be plain-text (e.g. we don't want the server to know if a user reacted with a 👍 or 👎 ). We should figure out a way to encrypt them. matrix-org/matrix-spec-proposals#1849 includes some thoughts on how to do encryption, and sorunome and deepbluev7 have also given some thoughts at matrix-org/matrix-spec-proposals#1849 (comment)

[Sorunome]

There was yesterday? two days ago? recently! a lengthy discussion about this in the spec room with multiple people. While multiple ideas were pitched, the things everyone seemed to agree on were:

1. Have a copy of m.relates_to in the cyphertext, so that after decrypting a client has the full metadata on the relationship
2. Do not have the cleartext rel_type in the event. Some were in favour of leaving it out at all, not allowing the server to aggregate it, while others proposed way to encrypt the type (and event Id) to allow the server to aggregate arbitrary strings.

[Sorunome]

Idea developed together with nico on how to maybe do encryption of event_id (and maybe rel_type, soru might prefer it to not be aggregatable at all): Have the attribute in plaintext be sha_512(event_id + enc_key + value), where enc_key is the (base64'd?) aes decryption key for the message this one refers to, event_id is the event_id of the message it refers to, and value is the value that it would have in plaintext.

So then the cyphertext of a reaction would read

{
  "type": "m.reaction",
  "content": {
    "m.relates_to": {
      "event_id": "$orig_event",
      "rel_type": "m.annotation",
      "key": "🦊",
    }
  }
}

And the event would then read

{
  "type": "m.room.encryption",
  "body": {
      // normal encrypted stuff
      "m.relates_to": {
        "event_id": sha512("$orig_event" + base64_aes_key_of_orig_event + "$orig_event"),
        "rel_type": sha512("$orig_event" + base64_aes_key_of_orig_event + "m.annotation"), // soru would prefer to leave this one out
    }
  }
}

That way the server can still aggregate random strings, clients can calculate the random strings as they can decrypt messages, and clients have the proper / real relation in the megolm cyphertext.

hereby it is crucial to only include event_id (and rel_type), and NOT key, or anything else, as the server can otherwise know which relation type it is, ruining the whole hashing. This might also be important for MSCs like matrix-org/matrix-spec-proposals#2730

[bkil]

Could we perhaps consider using a HMAC construction for enhanced security?

• https://en.wikipedia.org/wiki/HMAC#Design_principles

[Mikaela]

Does this issue include case where responses to messages-that-cannot-be-decrypted reveal the original message when view source is pressed?

[MazeChaZer]

@Mikaela no, that problem is covered in #368, and also in the MSC matrix-org/matrix-spec-proposals#2781.