alt Hacker News> 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.
It entirely depends on the client. There is nothing in the protocol which means that clients have to store old keys, but many do - mainly so they have a copy that can be backed up on the server to support migrating between devices, and for history sharing, as you say. However you absolutely could configure a locked-down Matrix client which discards megolm keys after receipt.
> 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.
Yup, this is fair - and agreed that implementations could and should discard unexpected messages in those sessions. There's nothing in the protocol that stops that (but also it's not explicitly covered in the spec).
We can fix this though; thanks for flagging it (and sorry if we missed it in the RHUL research...)
It may have been easy to miss them! IIRC, we didn't discuss these as explicit "problems", per se, just design trade-offs with particular implications. We even discuss at the end of the second paper whether its worth reconsidering PCS and FS altogether in many circumstances. This is because it is quite common to compose messaging with backup/multi-device setups that undermine (some understandings of) PCS and FS (all over the place, not just in the Matrix ecosystem).
On that note, a quick correction from my side. I suggested that: "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."
But I think this is way easier said than done because (with the history sharing architecture that is currently used) it is difficult for a fresh device to meaningfully distinguish historical Megolm sessions and active ones. Other designs get around this by re-encrypting the plaintexts rather than the session keys, but this would be quite a big change.