4 ms·

I was on a team that evaluated moving a significant portion of a product that should be used for government/healthcare onto Matrix. There were several drawbacks

by dotdi 8mo ago

I was on a team that evaluated moving a significant portion of a product that should be used for government/healthcare onto Matrix. There were several drawbacks that made us NOT go this route: - Olm/Megolm does not offer forward secrecy for group messaging - Olm/Megolm does ensure end-to-end encryption for message data, but not for metadata. - Federation makes it challenging to be GDPR compliant - Synapse is very heavy, other implementations are less production ready - For better or worse, the matrix foundation is under UK jurisdiction. I'm sure I forget some of the nuance, but these were some of the major points. However, there are several government entities in Germany, France, Poland, etc, that can live with the limitations and DO self-host Matrix servers. I won't go into the pair of high-severity vulns in 2025 (and the somewhat difficult mitigation) because that could hit anyone.

Buxato 8mo ago
Thanks for the info, what do you think about Delta chat?
- dotdi 8mo ago
  The cryptography is sound, however, it's also frequently changing, in addition to straying from standards more or less. This makes it difficult to give a firm answer. This ETH (i.e. Zurich) paper[0] identified several exploitable vulnerabilities (bad), which were quickly addressed by delta chat (good). So overall, I'd see it as a good messenger, but with downsides. [0]: https://www.usenix.org/system/files/usenixsecurity24-song-yuanming.pdf https://www.usenix.org/system/files/usenixsecurity24-song-yu...
  - Buxato 8mo ago
    Thank you :)
Arathorn 8mo ago
> Olm/Megolm does not offer forward secrecy for group messaging Megolm does provide forward secrecy - just in blocks of messages. If a message key gets stolen, an attacker could decrypt subsequent messages from that sending device until the next session begins: by default this happens either after 100 msgs have been sent, a week has elapsed, or if the room membership changes. Most folks consider this to be adequate perfect secrecy. In terms of the Matrix Fdn being incorporated in the UK… I guess that means one shouldn’t use the Internet, given IETF is US incorporated? :)
- dotdi 8mo ago
  > In terms of the Matrix Fdn being incorporated in the UK… I guess that means one shouldn’t use the Internet, given IETF is US incorporated? :) The outputs of the IETF are RFCs. The Matrix foundation does more directly oversee the "de-facto" Matrix, so has more influence, could bow to government pressure or changing laws, etc. etc.
  - Arathorn 8mo ago
    Hmmm. The main difference between the Matrix Fdn publishing a spec (https://spec.matrix.org https://spec.matrix.org) made out of Matrix Spec Changes (https://spec.matrix.org/proposals https://spec.matrix.org/proposals) versus IETF only publishing RFCs is simply that the Matrix Fdn also maintains a consolidated version of the spec. I'm not sure that makes the protocol governance fundamentally more vulnerable to govt influence?
    - pseudalopex 8mo ago
      They said they were sure they forgot some of the nuance. UK company Element took server development from UK company Matrix Foundation would have been forgettable nuance. Or they evaluated Matrix before possibly.
- danjones-crypto 8mo ago
  Re. security of old keys/sessions/messages after compromise of some current state (i.e. notions like forward security): Do Matrix clients still keep the oldest version of the Megolm ratchet they have ever received? When I last looked (around 2024), the libraries maintained by the Matrix.org core team did. This means that, while Megolm has a ratchet that can be used to provide forward security, no Matrix implementation that I am aware of does this. This seems to me to be because other features of the Matrix specification rely on continued access to these old keys (like Megolm key backups and history sharing). Re. security of new keys/sessions/messages after compromise of some current state (i.e. notions like post-compromise security, future secrecy): My understanding is that, while a _sender_ will rotate Megolm sessions every 100 or so messages, recipients tend not to: clients will accept ciphertexts sent from those old sessions for an indefinite period of time. Again, I haven't been following developments in the Matrix world for a little while, so please correct me if I'm wrong. This seems (to me) to be for similar reasons to the above: recipients keep around the recipient sessions so they can be backed up and shared with new devices (for history sharing). But (!) Matrix could get way better authentication guarantees if they just _disabled accepting messages_ from these old sessions at the same schedule as the sender stops using them. -- These are not a unreasonable compromises (there aren't too many attempts to square this circle, and most that I'm aware of are quite academic) but it's worth making clear that just because Olm/Megolm/the Matrix spec have particular features, it doesn't mean they are used properly to give the security guarantees we would naively expect from their composition. At least, this is the case for almost all Matrix clients that I'm aware of.
user32489318 8mo ago
Which tool did you guys end up using?
fsflover 8mo ago
> - Federation makes it challenging to be GDPR compliant Can you elaborate? AFAIK when everything is encrypted, GDPR compliance is trivial.

by dotdi 8mo ago

Buxato 8mo ago

Thanks for the info, what do you think about Delta chat?

dotdi 8mo ago
The cryptography is sound, however, it's also frequently changing, in addition to straying from standards more or less. This makes it difficult to give a firm answer. This ETH (i.e. Zurich) paper[0] identified several exploitable vulnerabilities (bad), which were quickly addressed by delta chat (good). So overall, I'd see it as a good messenger, but with downsides. [0]: https://www.usenix.org/system/files/usenixsecurity24-song-yuanming.pdf https://www.usenix.org/system/files/usenixsecurity24-song-yu...
- Buxato 8mo ago
  Thank you :)

Arathorn 8mo ago

> Olm/Megolm does not offer forward secrecy for group messaging Megolm does provide forward secrecy - just in blocks of messages. If a message key gets stolen, an attacker could decrypt subsequent messages from that sending device until the next session begins: by default this happens either after 100 msgs have been sent, a week has elapsed, or if the room membership changes. Most folks consider this to be adequate perfect secrecy. In terms of the Matrix Fdn being incorporated in the UK… I guess that means one shouldn’t use the Internet, given IETF is US incorporated? :)

dotdi 8mo ago
> In terms of the Matrix Fdn being incorporated in the UK… I guess that means one shouldn’t use the Internet, given IETF is US incorporated? :) The outputs of the IETF are RFCs. The Matrix foundation does more directly oversee the "de-facto" Matrix, so has more influence, could bow to government pressure or changing laws, etc. etc.
- Arathorn 8mo ago
  Hmmm. The main difference between the Matrix Fdn publishing a spec (https://spec.matrix.org https://spec.matrix.org) made out of Matrix Spec Changes (https://spec.matrix.org/proposals https://spec.matrix.org/proposals) versus IETF only publishing RFCs is simply that the Matrix Fdn also maintains a consolidated version of the spec. I'm not sure that makes the protocol governance fundamentally more vulnerable to govt influence?
  - pseudalopex 8mo ago
    They said they were sure they forgot some of the nuance. UK company Element took server development from UK company Matrix Foundation would have been forgettable nuance. Or they evaluated Matrix before possibly.
danjones-crypto 8mo ago
Re. security of old keys/sessions/messages after compromise of some current state (i.e. notions like forward security): Do Matrix clients still keep the oldest version of the Megolm ratchet they have ever received? When I last looked (around 2024), the libraries maintained by the Matrix.org core team did. This means that, while Megolm has a ratchet that can be used to provide forward security, no Matrix implementation that I am aware of does this. This seems to me to be because other features of the Matrix specification rely on continued access to these old keys (like Megolm key backups and history sharing). Re. security of new keys/sessions/messages after compromise of some current state (i.e. notions like post-compromise security, future secrecy): My understanding is that, while a _sender_ will rotate Megolm sessions every 100 or so messages, recipients tend not to: clients will accept ciphertexts sent from those old sessions for an indefinite period of time. Again, I haven't been following developments in the Matrix world for a little while, so please correct me if I'm wrong. This seems (to me) to be for similar reasons to the above: recipients keep around the recipient sessions so they can be backed up and shared with new devices (for history sharing). But (!) Matrix could get way better authentication guarantees if they just _disabled accepting messages_ from these old sessions at the same schedule as the sender stops using them. -- These are not a unreasonable compromises (there aren't too many attempts to square this circle, and most that I'm aware of are quite academic) but it's worth making clear that just because Olm/Megolm/the Matrix spec have particular features, it doesn't mean they are used properly to give the security guarantees we would naively expect from their composition. At least, this is the case for almost all Matrix clients that I'm aware of.

user32489318 8mo ago

Which tool did you guys end up using?

fsflover 8mo ago

> - Federation makes it challenging to be GDPR compliant Can you elaborate? AFAIK when everything is encrypted, GDPR compliance is trivial.