I'm a tad worried about getting rid of key-sharing. I seem to use this every once in a while. Pretty much any time I use a client I haven't used in a while. I guess I could just get the keys from the backup, but then I need to have THAT key, which is a bit inconvenient.
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 which can be used to set up 1:1 sessions even if you run out of OTKs, which is marginally inferior to using a different OTK every time, but in practice really isn't a disaster (see the MSC for details).
However, fallback keys are relatively new and aren't implemented on all clients yet (matrix-js-sdk has them, but matrix-ios-sdk is implementing this coincidentally this week)... and so until they land, we still need keyshare requests to paper over this limitation.
But in future, hopefully it will be almost unheard-of to need a keyshare request, and we can change them to be an entirely manual or out-of-hand mechanism of some kind, and avoid classes of bugs like the vuln in question here in future.
> In theory, you should be able to pick up and old client and decrypt new messages and history on it absolutely fine.
No? Assume the lost/stolen/forgotten device has outdated (or no) protection around its keys - and it should be rotated out as soon as possible?
I'd rather not have to worry about if my old phone is in my drawer at home, or in an mi6 office (or more likely, with an estranged spouse or a journalist)?
if you think the device has been lost then you should obviously kick it off your account immediately, and it'll be immediately rotated out of all the conversations it was in.
otherwise, do you really want to rely on the OTK pool exhausting as a very handwavey way to provide post-compromise security? A much better solution would be to have a firmer metric for your server to explicitly kick out your devices after N days of inactivity. Relying on some weird bug like OTK pool exhaustion for security purposes is horrible.
However, my point still stands that fallback keys are a good idea - you should kick the device out deliberately (manually or with a timer) rather than rely on a protocol quirk meaning that E2EE randomly breaks after some period of inactivity(!)
Each OTK is a Curve25519 key (or ed25519 key, i forget) - so 32 bytes. So 100 takes up 3.2KB of storage on each client for the private keys, and the same on the server for the public keys, so it's not a big concern :) We could do bigger pools, but it's just punting the problem.
100 seems like a reasonable middle-ground between "that's a lot of storage to address a rare edge case" (e.g. say this was 3.2TB) and "most people will never need 10".
