3 ms·
> 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 dev
by e12e 5y ago
> 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)?
- Arathorn 5y agoif 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.
- e12e 5y agoBelt and suspenders. It should be possible to kick a device, and be a timeout.
- Arathorn 5y agoIt is already possible to kick a device (go to Settings: Security in Element, for instance). I've filed an issue at https://github.com/matrix-org/synapse/issues/10813 https://github.com/matrix-org/synapse/issues/10813 for inactivity timer logouts. 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(!)
- e12e 5y agoAs long as the timer is passive (key expires) rather than active (key expunged).