matrix-doc

This is a great example of why key-sharing exists today... and why it shouldn't. In theory, you should be able to pick up and old client and decrypt new messages and history on it absolutely fine. However, in practice, Matrix's E2EE publishes 100 one-time keys (OTKs) on your server to let other devices establish secure 1:1 channels with you if you're offline - and if you go offline and that pool of OTKs exhausts, then new sessions won't get set up and you won't receive keys for new messages... giving the misbehaviour you're seeing. Now, you're right that key-sharing is a useful way to fudge around that failure mode. But an even better way to fix it would be to find a way to stop the OTK pool exhausting - and that's precisely what MSC2732 is: https://github.com/uhoreg/matrix-doc/blob/fallback_keys/prop.... This provides a last-ditch key

Yes, Matrix is properly end-to-end encrypted (with all keys generated clientside) and has been independently audited as such: https://www.nccgroup.trust/us/our-research/matrix-olm-crypto.... We have gone to huge efforts to prevent MITMs via device verification and cross signing - which specifically addresses both problems of a) losing chat history when you move between devices (via https://github.com/uhoreg/matrix-doc/blob/e2e_backup/proposa...) and b) requiring cross-signing when you log in on a new device, to spread trust to new logins, as per https://github.com/uhoreg/matrix-doc/blob/cross-signing2/pro.... All keys are stored clientside, with the exception of if you enable serverside key backup, when they are then encrypted and optionally stored serverside to allow you to recover your history if you lose all your devices.

From a user perspective, you'd either log out of a device and log back in (thus getting a new device key), or you can hit a big reset button on your cross-signing state if you want to blow away your master key and start over (which isn't so much rotation as revocation, but should be adequate). https://github.com/uhoreg/matrix-doc/blob/cross-signing2/pro... has the details from the implementor's perspective. See also https://github.com/uhoreg/matrix-doc/blob/cross-signing2/pro... EDIT: in theory you could also rotate all keys from a client by creating a new master signing key and then re-publishing all your existing cross-signing signatures with the new keys. This sounds like quite a good way to grandfather in untrustworthy attestations though; it might be safer to start over. The current implementation doesn't support this.

The backed up keys are encrypted against a client-generated Curve25519 public key, with new session keys being added incrementally (so you don't need to provide the key after you set it up)[1]. Personally I don't see it as much more of a risk than trusting them to host the ciphertext of your messages. People have different threat models. When chatting with my family, it's more important that we have a permanent history of our messages rather than the worry of them getting leaked. But if you're a whistleblower you have a different set of requirements. [1]: https://github.com/uhoreg/matrix-doc/blob/e2e_backup/proposa...

https://github.com/uhoreg/matrix-doc/blob/cross-signing2/pro... is the spec for this, fwiw

yeah, this is a good example where a temporary(?) web-of-trust could work. in retrospect, i think the cross-signing proposal (https://github.com/uhoreg/matrix-doc/blob/cross-signing2/pro...) has some thoughts about how transitive trust between users could work, but i'm failing to find it now. I've raised a bug to track: https://github.com/matrix-org/matrix-doc/issues/1886 - thanks!