Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

possible to run out of one-time-keys on rarely-used devices #3187

Closed
Tracked by #2996
richvdh opened this issue Feb 9, 2017 · 6 comments
Closed
Tracked by #2996

possible to run out of one-time-keys on rarely-used devices #3187

richvdh opened this issue Feb 9, 2017 · 6 comments
Labels
A-E2EE P2 S-Major Severely degrades major functionality or product features, with no satisfactory workaround T-Defect

Comments

@richvdh
Copy link
Member

richvdh commented Feb 9, 2017

If you don't log into a device for ages, it is possible for the server to run out of one-time-keys, which means that new sender devices won't be able to send megolm keys to you

@richvdh
Copy link
Member Author

richvdh commented Feb 9, 2017

I'm a bit short on ideas of what to do about this. I'm not super-keen on the the signal-esque fallback-to-not-using-one-time-keys, because it significantly weakens the protocol - otoh it is a relatively simple fix. Other alternatives might involve getting the sender to share the sessions later (we might even be able to keep a list of devices we wanted to share with, but couldn't? Probably related to #3019?)

#2494 might help here - we could give the sender the choice to fall back to a less secure method?

@ara4n ara4n added T-Defect S-Major Severely degrades major functionality or product features, with no satisfactory workaround P2 labels Feb 9, 2017
@ara4n
Copy link
Member

ara4n commented Feb 9, 2017

I agree the Signal-style fallback is ming. Surely we can exploit megolm to help us out of this one: if we can't share megolm sessions to devices because Olm is dead, we'll need to queue the keys until that device is available again.

This could be done by OOB negotiation with a poor-man's "hit retry to try this message again" on the sender side, or we could do the whole https://github.com/vector-im/riot-web/issues/2286 thing to let the receiving device plead to receive keys from elsewhere in the room when it comes back to life.

Eitherway, it feels like we should just queue the session keys until we can send them.

@richvdh
Copy link
Member Author

richvdh commented Jun 20, 2017

Interesting to note that Wire gives an explicit "You haven't used this device for a while" notice.

@richvdh
Copy link
Member Author

richvdh commented Oct 18, 2017

@lampholder had this problem on a new device this evening. Hoping he and erik will share server logs to enlighten me.

@ara4n
Copy link
Member

ara4n commented Jun 4, 2020

mastodon/mastodon#13820 (comment) has useful discussion about this.

I think we should figure out whether it's a disaster or not to have an emergency key to wriggle out of OTK exhaustion or not.

More conversation about this at https://matrix.to/#/!YRyTcRVrJzaHGZrsur:matrix.org/$zGea0UHt_Pp2DM9KsuDNl4O1bwFFsyE3OmI3zQuun08?via=matrix.org&via=ensofia.com&via=matrix.gibberfish.org

I was trying to think of an attack like:

  • Alice's server admin Eve is trying to spy on her.
  • Eve notices that Alice has a login somewhere on a browser she never uses (e.g. that old Chrome session she never uses since she switched to FIrefox)
  • Eve snags a copy of Alice's local storage on her Chrome (e.g. via XSS), thus getting her id & OTK & backup OTK priv keys
  • Eve exhausts Alice's OTK pool (e.g. by just deleting them from Alice's acct)
  • Every time a new person starts an Olm session with Alice, Eve can now intercept and participate, using the backup OTK key, forever.

...but I guess the point is that by this point, Eve could also be populating up new non-backup OTKs.

@uhoreg
Copy link
Member

uhoreg commented Dec 13, 2021

This is fixed by fallback keys now

@uhoreg uhoreg closed this as completed Dec 13, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-E2EE P2 S-Major Severely degrades major functionality or product features, with no satisfactory workaround T-Defect
Projects
None yet
Development

No branches or pull requests

3 participants