Thanks for your work! So a user can mitigate this by keeping encryption enabled and also enabling the option to never send encrypted messages to unverified sessions?
> Does this mean that Matrix does not provide confidentiality and/or authentication?
> Matrix and its implementations can, after today’s fixes, provide confidentiality and authentication assurances against malicious homeservers, if users act as follows. Each user must enable cross-signing and perform out-of-band verification with each of their own devices, and with each user they interact with.2 They must then remain vigilant: any warning messages or icons must be spotted and investigated. In the Element user interface, this requires checking the room icon and each individual message they receive (in some cases, past messages can retroactively receive a warning). Note that such warnings could be expected behaviour (for example if the message was decrypted using a server-side Megolm backup or through the “Key Request protocol”). Users would need the expertise to investigate these warnings thoroughly and, if an issue is found, recover from it. If you follow these instructions without fail, Matrix can provide you with confidentiality and authentication.
> This places an unnecessary burden on users of Matrix clients, limits the user base to those with an understanding of the cryptography used in Matrix and how it is used therein, and is impractical for daily use. The burden this places on users is unnecessary and the result of the design flaws we highlight in our work (this is our “Simple confidentiality break” attack). Whilst this issue will persist after today’s fixes, a remediation is planned by the Matrix developers for a later date.
> Some of our other attacks against Matrix’s flagship client Element are based on implementation flaws and, thus, were able to break its confidentiality and authentication guarantees even when the steps above were followed (prior to today’s patches). As of today, most of these issues should be fixed (see above), but we have not independently verified this. The Matrix developers report that other clients are not affected but, similarly, we have not independently verified this.
It still looks like users that enable the previously mentioned option and/or verify sessions accordingly are fine. I'm just trying to clarify a simple guideline for users looking to continue using Matrix securely with confidence.
"if you follow these instructions without fail, Matrix can provide you with confidentiality and authentication." I was hoping the researchers could clarify these simple mitigation instructions to protect users, assuming they already know how to use Element.
Yes. I have used Matrix professionally for years and it's pretty simple for me to understand and follow what is unnecessarily editorialized here to keep my conversations safe. I don't understand why this language is not being simplified to keep Matrix users safe, as that should be the highest goal of this entire situation.
> Does this mean that Matrix does not provide confidentiality and/or authentication?
> Matrix and its implementations can, after today’s fixes, provide confidentiality and authentication assurances against malicious homeservers, if users act as follows. Each user must enable cross-signing and perform out-of-band verification with each of their own devices, and with each user they interact with.2 They must then remain vigilant: any warning messages or icons must be spotted and investigated. In the Element user interface, this requires checking the room icon and each individual message they receive (in some cases, past messages can retroactively receive a warning). Note that such warnings could be expected behaviour (for example if the message was decrypted using a server-side Megolm backup or through the “Key Request protocol”). Users would need the expertise to investigate these warnings thoroughly and, if an issue is found, recover from it. If you follow these instructions without fail, Matrix can provide you with confidentiality and authentication.
> This places an unnecessary burden on users of Matrix clients, limits the user base to those with an understanding of the cryptography used in Matrix and how it is used therein, and is impractical for daily use. The burden this places on users is unnecessary and the result of the design flaws we highlight in our work (this is our “Simple confidentiality break” attack). Whilst this issue will persist after today’s fixes, a remediation is planned by the Matrix developers for a later date.
> Some of our other attacks against Matrix’s flagship client Element are based on implementation flaws and, thus, were able to break its confidentiality and authentication guarantees even when the steps above were followed (prior to today’s patches). As of today, most of these issues should be fixed (see above), but we have not independently verified this. The Matrix developers report that other clients are not affected but, similarly, we have not independently verified this.
https://nebuchadnezzar-megolm.github.io/