| This is discussed by the research team who reported these issues (I'm one of those researchers) at: https://nebuchadnezzar-megolm.github.io/ > Are these attacks design flaws in the Matrix specification? > We will explain this one by one by using the name of the attacks previously defined: > a. Simple confidentiality break: The root cause of this attack is the fact that room management messages are not authenticated, which is a design flaw in the protocol itself, as no mechanism was specified for authentication of such messages. > b. Attack against out-of-band verification: This attack exploits an insecure implementation choice enabled by a design flaw in the specification as there is no domain separation enforced there. > c. Semi-trusted impersonation: This is mostly implementation bug supported by a lack of guidance on the processing of incoming key shares in spec. > d. Trusted impersonation: This is an implementation error as no check is performed to check whether Olm is used for encryption or not. > e. Impersonation to confidentiality break: This is an implementation error as no check is performed to check whether Olm is used for encryption or not. > f. IND-CCA break: This theoretical attack exploits a protocol design flaw. On the viability of the discussed countermeasure: > While the Matrix specification does not require a mitigation of this behaviour, when a user is added to a room, Element will display this as an event in the timeline. Thus, to users of Element this is detectable. However, such a detection requires careful manual membership list inspection from users and to participants, this event appears as a legitimate group membership event. In particular, in sufficiently big rooms such an event is likely to go unnoticed by users. |