Matrix (the protocol)? No thank you.

Matrix (the protocol)? No thank you.

I see that in the community of those who say they love privacy the Matrix protocol continues to be exalted, making them believe that it is as safe as Signal, (that is, as much as signal would be if it had not used some libraries to build the server) with an abuse absurdity of the word E2EE.

The thing that is particularly bothering me in all of this is that those who use the Matrix, or suggest using it, continue to talk as if they are equally sure of the Signal protocol, which they are not: Matrix is ​​a compromise.

I try to explain why.

The Signal / Olm / Double Ratchet cryptography protocol, depending on the jargon you want to use, uses a method for generating unique keys that is recursive. What does it mean?

It means that during the conversation you are not always encrypting your message with the same key, but the key changes (is updated) with each message you send.

  1. hello (key: 6f0378f21a495f5c13247317d158e9d51da45a5bf68fc2f366e450deafdc8302)
  2. how are you (key: 615452c145c402b73764ddecdd5a76e59faa25b68258474cfd259536c1c39a06)
  3. He is at home? (key: 5c2fb30bed30bd2cce6700122cae3c8b839cbffbca29a6e95408b32290a16ba4)

the trick is what is also used with google authenticator, that is a function that works only "forward" but cannot "go back". The result is that even if someone steals key number two, they won't be able to read message number three, because the key is different.

Obviously the server and the client must be synchronized, so while you open an account you do nothing but establish the initial value and the number of messages used.

So far so good. But you know that chat protocols are not used to communicate person-to-person, but client-to-client: it means that maybe you have a client on your computer, one on your beautiful mobile phone, one on the sgrauso one, and so on.

And now the question is: how can all clients be synchronized? I mean, if you have multiple cell phones and you write to the same room, but the cell phones don't know exactly what number of messages they are, how do they line up? And if they lined up, how would they be sure they lined up in the right way?

The solution chosen is almost always that of associating your mobile phone (the MSISDN, that is the telephone number) to the client. Then, using a QRCODE, you can add other devices, but only to use a web interface: then the server, which is always aligned with the primary client, will take care of the key and the iteration you are in .

But not only. Even if a laptop is stolen from you, to cut it out just make sure that it is disassociated with the key, generating another one, which instead works for the other clients, and here the stolen laptop would no longer be able to communicate or read anything.

In short:

  • Each message is encrypted with a different key. If an attacker gets the key to a message, he can only decrypt that message.
  • If the client does not keep each of these keys, each message can be decrypted only once, because the key changes each time it is read.
  • If an attacker gains access to the data that generates the keys (the key ratchet), he can decrypt the messages only until the participants in the conversation complete a send-reply cycle (because the DH brace that is used to generate the key module will be replaced).
  • The attacker cannot decrypt past messages because he does not have the passed keys
  • Once decoded, the messages are in "deniability": It is not possible to prove that the other party sent them.

Good.

Everything is fine? No.

We are talking about a protocol that works between Me and You. If there are only two of us, it is radically safe, and moreover I will always be able to be sure that you are really you, since anyone else would not have the passwords, and even if he had stolen the client device (mobile phone or laptop) , on the first message the two would be misaligned, and a new DH would be generated.

But if for example we enter a room with many people, and we have two clients, what happens? If the two clients are like Signal or Whatsapp, in reality we will have ONLY ONE DH, shared via qcode via the web and generated at the moment, and therefore we would have no problems.

But especially, since we have not shared the DH with each of the participants, and it has been changed with each message, how do we decode past messages, and how do we distinguish two clients of the same person?

Matrix solves the problem with a compromise: it stops using the "hard" algorithm, the safe one, and makes you use a less powerful algorithm to find an algorithm. This algorithm is called "MegOlm". ( https://gitlab.matrix.org/matrix-org/olm/blob/master/docs/megolm.md )

MegOlm's problem is that compared to the classic Double Ratchet (like Signal's), this implementation is less robust, and loses some security features.

You can see it here, under Limitations: https://gitlab.matrix.org/matrix-org/olm/blob/master/docs/megolm.md#limitations


Why is this bad for the user?

  • because encryption requirements are removed, for example you no longer have the same certainty of talking to whoever you think you are talking, as you would with OLM / Double Ratchet.
  • IT IS NOT TOLD TO THE USER.

If you read the security and privacy cazzari that speak everywhere, you will see that they will describe Matrix as an alternative to signal, implying that you have the same level of security as a client who takes care to keep OLM and a single DH.

And the saddest thing is that the problem could be solved: instead of sharing a DH with anyone with a given verified phone number, the verification could be done using an OTP (One Time Password) such as Google Authenticator, or some Open source OTP.

Matrix (the protocol)? No thank you.
These, to be clear.

So, when you repudiate Signal because "it is not transparent" and then go to Matrix, which does not inform the user of the fact that he may not really talk to whoever he thinks he is talking to, it seems to me only right to raise your hand and say "er … no".

Matrix (the protocol)? No thank you.

Why this is bad for the community:

after this "compromise" to security, MegOlm is safe when an XMPP / Jabber server is when using a client (Dino, for example) with OMEMO and OpenPGP.

Indeed, slightly less, because Dino allows you to set whether you want "Blind Trust by default" or not, while Matrix ALWAYS does Blind Trust:

Matrix (the protocol)? No thank you.
On Dino (XMPP / Jabber) you can disable the Blind Trust by Default.

But the difference is that using a simple RaspBerry anyone can host a lightweight server like Prosody in their home using the home router. It is easy to self-host, and on a Raspi 4 it can handle hundreds of users.

When we talk about Matrix, however, we are talking about an implementation that requires at least 4GB of RAM and a very powerful processor, to accommodate ONE user. And I'm not kidding.

In a nutshell, self-hosting is becoming more difficult (which would allow various organizations to easily and economically build hosts for their users, at the expense of communities, who may need to be able to run everything with little money. countries where the main chat servers are all monitored.


In general, I find the Hype per matrix extremely harmful, because:

  • provides a false sense of security
  • does not correctly inform the user of the compromise in progress
  • limit selfhosting to those rich enough to pay for a powerful server

and therefore, I'm sorry… but the Matrix doesn't.


Leave a Reply

Your email address will not be published.