Vanitasvitae @vanitasvitae@fosstodon.org

(First, I'm talking from my perspective and not on behalf of Eugen or the Mastodon project)

There's still a long way to go, but we're working on providing end-to-end encryption of chat-like messages in Mastodon.

The cryptographic protocol we're considering is basically that used in XMPP's OMEMO, Signal, and part of Matrix (part of Matrix, because Matrix also features another protocol, that provides weaker security but is much more efficient in group chats).

Like Matrix and OMEMO, your server will still know who you're talking with and when (Signal does manage to avoid that to a great extent).

Message Franking

There's one feature we are discussing that I want to talk about a bit: message franking. It's a scheme designed by Facebook to enable the receiver of a message to report it to their server without revealing other messages in the process.

Basically, it works by having the sender hash (using HMAC) the message with a key they generate just for signing that single message. They then encrypt that key together with the message. So, the hash is visible to the server, but not the message nor the key. So it cannot, at that point, be verified by the server or infer anything about the message or key.

The server then takes note of the hash, and who sent the message to whom. It then signs that note with its own key (that key can be private, it's not important). It could also encrypt it. Nobody but the server needs to be able to read and verify it, but it's also not super important if anyone else can.

Then the server gives that signed note, along with the message, to the receiver, and forgets about it.

Upon receiving the message, the receiver performs the usual checks, but now, it has the message and the HMAC key, so it is able to verify the HMAC hash. If the HMAC hash is invalid, that means the sender lied, and he won't be able to report it. So the receiver just discards it (it could display an error message to the user, but that's not important). Otherwise, the receiver can report it. How? By sending the message, along with the HMAC key and the signed note back to the server.

The server first decode/decrypts the note, verifies its signature so that it can be sure that it indeed made that note, and then, since it has the HMAC key, can finally check the HMAC hash and verify that the reported message is indeed the message that was sent.

To lie about the reported message, you'd have to find another message and another key that match the hash, which is exactly what the HMAC algorithm tries to make impossible, and for which there are no known attack to this day.

Since you need the key and the message, on its own, the key does not let you learn anything about the message. If you were almost sure you knew the message, you'd still need the key to verify it.

According to a paper (https://eprint.iacr.org/2017/664.pdf)—which I'm going to trust here, I intuitively understand the reasoning, but I don't have enough knowledge to be completely sure about it, the message franking construction isn't even needed because the underlying protocol already has the same properties, if you reveal just the right key. This means adding message franking doesn't make the deniability of the protocol actually weaker. Adding it just makes it easier to implement and also makes sure that you disclose exactly the message you were reporting and not a few more (the alternative would be to reveal the input to the key derivation function for one message, but it could be used for more than one message, although it would usually be a short amount of messages)