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.
> 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...)