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

"Unable to decrypt: The sender's device has not sent us the keys for this message." (The UISI bug) #2996

Closed
18 of 25 tasks
richvdh opened this issue Jan 19, 2017 · 68 comments
Closed
18 of 25 tasks
Labels
A-E2EE O-Frequent Affects or can be seen by most users regularly or impacts most users' first experience S-Critical Prevents work, causes data loss and/or has no workaround T-Defect T-Epic Issue is at Epic level Z-UISI Unable to decrypt errors

Comments

@richvdh
Copy link
Member

richvdh commented Jan 19, 2017

Update 2023-02-27

This issue is now superceded by element-hq/element-meta#245

Historical information follows.


This message (or, less often, the closely related "OLM.UNKNOWN_MESSAGE_INDEX") can be caused by a number of things. This bug serves as a reference to the reasons we know about.

Client-specific bugs:

Protocol/server things:

Unexplained:

@richvdh richvdh added the A-E2EE label Jan 19, 2017
@ara4n ara4n added T-Defect S-Critical Prevents work, causes data loss and/or has no workaround P1 labels Jan 20, 2017
@ara4n ara4n changed the title "Unable to decrypt: The sender's device has not sent us the keys for this message." "Unable to decrypt: The sender's device has not sent us the keys for this message." (The UISI bug) Mar 19, 2017
@ara4n
Copy link
Member

ara4n commented Apr 1, 2017

For anyone reading this looking for a workaround, the best advice currently is that if you suddenly find yourself unable to decrypt messages from someone, ask them to open up your contact details on their client. This should force their Riot to resync its copy of your device list, increasing the chance that the next message sent will actually be encrypted for your current device.

If this doesn't work, you have no choice but create a new room (or worst case, export your session keys, logout, login and import your session keys), until the workaround in #3553 is implemented (or this meta-bug is finally closed up)

@lampholder lampholder added this to the RW002 milestone Apr 3, 2017
@lampholder
Copy link
Member

Making forward progress on this requires either @richvdh to hop back into it, or for him to hand over to somebody else.

@lampholder lampholder modified the milestones: RW003 - candidates, RW002 - candidates Apr 3, 2017
@lampholder lampholder removed this from the RW003 - candidates milestone Apr 24, 2017
@ara4n
Copy link
Member

ara4n commented May 4, 2017

I just spent a while reviewing all of the known remaining UISI causes with @richvdh. UISI bugs fall into two broad categories:

Wedged olm sessions:

Missing megolm keys:

Rich estimates UISIs to roughly be caused 50/50 split between the two.

However, all of the 'missing megolm key' class of bugs can be worked around by giving users a way of recovering missing megolm keys - and in some cases (broken federation; matrix-org/synapse#2165) this is the only plausible solution. In turn, if we had a way of recovering missing megolm keys, we'd also have a way to share history to new devices - the infamous 'share history' bug (#2286).

Therefore the suggestion is to focus entirely[1] on solving the problem of sharing megolm keys, given the value of solving both the 'missing megolm key' bugs as well as the 'sharing history' feature is greater than the value of solving the individual bitty 'wedged olm session' bugs (which all have different solutions). This means setting aside UISI hell and forging ahead and solving history sharing (#2286) or at least a subset of it. This could well include improving the UX for sharing history by supporting cross-signed keys (#2714).

[1] We can probably progress the 'multiple tabs' problem (#2325) in parallel. And the plan is to finish the devicelist race #3796 first.

@richvdh
Copy link
Member Author

richvdh commented May 5, 2017

element-hq/element-meta#1143: If you reuse node-localstorage and share curve25519 keys between different device IDs, Olm wedges <-- NOT A BUG FOR RIOT.

Well, it is a bug for riot, in that if anyone uses the js-sdk in the obvious manner, riot fails to talk e2e with the resultant client. It's arguable whose fault that is - ideally both ends would be fixed. But it's not a bug for riot inasmuchas it doesn't affect riot<->riot comms.

...possibly other bugs where the act of loading the target's MemberInfo kicks the sender into refreshing their device list?

AFAIK the only thing that loading the MemberInfo would solve these days is #3796.

@ara4n
Copy link
Member

ara4n commented May 6, 2017

writing https://github.com/vector-im/riot-web/issues/2286#issuecomment-299605919 made me realise that perhaps we can also improve the experience here in general with better error messages. For instance, do we have any way of detecting when an Olm session has got wedged, such that we can complain about that (and perhaps reset it?) rather than just whine about missing megolm keys?

@richvdh
Copy link
Member Author

richvdh commented May 6, 2017

Yes, we can certainly improve this. We can give the user feedback about failing to decrypt to_device messages (though they tend to get replayed at initial sync, so we'd have to think how to avoid false positives). element-hq/riot-android#800 randomly, covers that. If we can get it reliable, we can start a new Olm session to try and unwedge things. We can also consider giving better feedback from the sender's end (#2494).

In general it's hard to tell the cause of any particular UISI, because you can't correlate it to a to_device you couldn't decrypt.

@pik
Copy link

pik commented May 6, 2017

If users restore a device backup or tab whilst the existing device is still around and active, Olm will wedge.
If you reuse node-localstorage and share curve25519 keys between different device IDs, Olm wedges <-- NOT A BUG FOR RIOT<->RIOT.

While it is possible at the moment I don't really like the idea of the same keys on multiple devices (this is surely a security risk). Notably also device_keys changing while device_id remains the same is another way to wedge olm sessions (the client sharing the megolm session key thinks they sent keys to the associated device, but that device has new keys and cannot decrypt the olm session).

@richvdh
Copy link
Member Author

richvdh commented May 8, 2017

@pik: please take your questions about element-hq/element-meta#1143 and #3822 to the relevant bugs.

Another thing we should consider on this bug is a way for the recipient to distinguish "the sender failed to send to you" vs "the sender chose not to send to you" (either they blocked you or your device explicitly, or because they had the 'Never send encrypted messages to unverified devices from this device' setting (matrix-org/matrix-js-sdk#336) checked).

  • basically we should be able to distinguish between "it went a bit wrong" and "expected behaviour".

Of course that would probably mean the sender sending a "you're blocked' notification to the recipient, but that wouldn't be hard.

@richvdh
Copy link
Member Author

richvdh commented May 8, 2017

Added #3845 for the "blocked vs failure" sidebar

@wildcard-f8

This comment was marked as spam.

This was referenced Aug 31, 2022
@tehoblivious

This comment was marked as spam.

@richvdh
Copy link
Member Author

richvdh commented Nov 14, 2022

We're closing this in favour of element-hq/element-meta#245, which needs a whole load of updates, but is probably still more up-to-date than this issue (and there's no point having two issues tracking the same thing)

@richvdh richvdh closed this as completed Nov 14, 2022
@nituladaboneko
Copy link

wow

5y later
and this is still an unresolved issue

was excited to move our team from google hangouts to element

but alas
another poor quality open source project

@vmario89
Copy link

vmario89 commented Dec 2, 2022

we are using element for 2.5 years now and for us the errors have gone completely. it works stable 99% of time. element + matrix are not a poor source project, but your opinion

@shmerl
Copy link

shmerl commented Jan 22, 2023

This is still happening (encrypted room, one user joining from iOS element client can't ready any messages with such error showing up). Doesn't happen with Web and Android clients. So can be iOS specific at this point.

@ShadowJonathan
Copy link
Contributor

iOS is currently going through a rewrite, so after that (Element X) replaces the current iOS app, those issues would most likely be resolved, as it uses the more-vetted rust-based matrix SDK to do crypto.

@shmerl
Copy link

shmerl commented Mar 23, 2023

Is there some status page for Element X for iOS to track the progress?

@ShadowJonathan
Copy link
Contributor

ShadowJonathan commented Mar 23, 2023

Element X is at https://github.com/vector-im/element-x-ios, the room is here.

There is a "Meta" repository for element now, where there are issues tagged with Element X iOS. I don't know where the central "project" board for Element X is, but it's likely that its not entirely public, as it is the domain of Element's Product Team.

The best way to "track" Element X's progress is to join the room, join the testflight, provide feedback (so you can help it along), and then finally notice that the testflight stops updating, and everyone is talking about the "better" Element app currently available for download in the store.

(Please keep in mind that the issues on the meta repo are not meant to be commented on, they're meant to be a way for the element team to communicate resources, and so adding noise would not help)

@richvdh
Copy link
Member Author

richvdh commented Mar 23, 2023

Please keep in mind that the issues on the meta repo are not meant to be commented on

I'm not sure that's true? element-meta is used to track issues that span more than one Element client implementation. Comments on issues in it are as welcome there as in the individual repositories.

That said:

  • element-meta does have a relatively high proportion of "tracker" issues which exist only to link out to other, more granular issues. Typically discussion is more appropriate on the lower-level issues than the tracker issues.
  • comments along the lines of "why isn't this thing ready yet" aren't going to be terribly helpful in any case.

@pylapp
Copy link

pylapp commented Nov 28, 2023

Followed the following steps and it worked like a charm:

  • export all my keys
  • log out
  • kill the all
  • log in with recovery sentence

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-E2EE O-Frequent Affects or can be seen by most users regularly or impacts most users' first experience S-Critical Prevents work, causes data loss and/or has no workaround T-Defect T-Epic Issue is at Epic level Z-UISI Unable to decrypt errors
Projects
None yet
Development

No branches or pull requests