Restoring a phone (or browser tab) from backup will break Olm if the other device still exists.

[ara4n]

the Double Ratchet is strictly 1:1 device, and if you have two devices trying to respond simultaneously everything will break, causing UISIs.

[ara4n]

Not sure what the best mitigation is here other than user education.

[richvdh]

the Double Ratchet is strictly 1:1 device, and if you have two devices trying to respond simultaneously everything will break, causing UISIs.

The concern is less about having two devices trying to respond simultaneously (which would be a problem, but doesn't happen with a simple backup/restore), but that a backup/restore rolls back the olm session state, making it useless.

The main mitigation is (as per Sesame which considers this scenario) allowing devices to start a new session - and then allowing the user to actually do so (possibly with some sort of Panic button).

[dbkr]

The conclusion on this as of today is that we should do this: the caveat is that we lose the trust established by having the shared ratchet state, falling back to the trust from the identity keys, so if somehow the device identity keys were compromised but not the ratchet state, this would allow the attacker to intercept messages. I'm struggling to imagine a situation where this would be the case though.

This will involve implementing matrix-org/matrix-spec-proposals#1596

Convo: https://matrix.to/#/!uewiilduiDRfPomIha:matrix.org/$1540918172317069dhnme:matrix.org

[dbkr]

My current plan for this goes as follows:

• Make js-sdk obey specify how to handle multiple olm sessions with the same device matrix-org/matrix-spec-proposals#1596
• Make js-sdk establish a new olm session with the opponent device when it fails to decrypt a message on a session. This should mean the next keyshare from that device will use the new session, but the session key in the failed message will still be lost forever.
• Add nack messages to the spec and re-send keys to the device when we get a nack, We'd probably do this by checking against the list of device we've sent keys to, but this is only stored in memory atm, so would only work until you restarted the device. (Actually rather than inventing separate nacks, we could probably just use keyshare requests).
• Save outbound session info to persistent storage so we can re-send keys even after we reload
• Prune old sessions

I'll probably do the first two items now and leave the rest for another time

[dbkr]

The solution for this ended up being matrix-org/matrix-spec-proposals#1719 (ie. rather than most of the checkboxes above)

[jryans]

@dbkr, should this still be on the workflow board as In Test? It sounds like a different approach was taken...?

[jryans]

Ah, or maybe it's fixed by matrix-org/matrix-js-sdk#780, which is linked from matrix-org/matrix-spec-proposals#1719.