3 ms·

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 messag

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/proposals/2732-olm-fallback-keys.md 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.

pkulak 5y ago
Thank you for writing that all out. I wasn't familiar with most of these details.
criticaltinker 5y ago
> 100 one-time keys (OTKs) on your server Is 100 a safe default for devices with limited memory, or are there other more salient constraints that I'm ignorant of?
- Arathorn 5y ago
  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.
  - Groxx 5y ago
    With 1 million users all doing this, it's 3.2GB. 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".
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 ago
  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.
  - e12e 5y ago
    Belt and suspenders. It should be possible to kick a device, and be a timeout.
    - Arathorn 5y ago
      It 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 ago
        As long as the timer is passive (key expires) rather than active (key expunged).

pkulak 5y ago

Thank you for writing that all out. I wasn't familiar with most of these details.

criticaltinker 5y ago

> 100 one-time keys (OTKs) on your server Is 100 a safe default for devices with limited memory, or are there other more salient constraints that I'm ignorant of?

Arathorn 5y ago
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.
- Groxx 5y ago
  With 1 million users all doing this, it's 3.2GB. 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".

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 ago
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.
- e12e 5y ago
  Belt and suspenders. It should be possible to kick a device, and be a timeout.
  - Arathorn 5y ago
    It 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 ago
      As long as the timer is passive (key expires) rather than active (key expunged).