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 message" eror when trying to read older E2EE messages (including my own) in new web sessions #28116

Closed
strypey opened this issue Sep 28, 2024 · 4 comments
Labels
A-E2EE O-Uncommon Most users are unlikely to come across this or unexpected workflow S-Major Severely degrades major functionality or product features, with no satisfactory workaround T-Defect

Comments

@strypey
Copy link

strypey commented Sep 28, 2024

Steps to reproduce

I'm opening a new issue as requested here; #28090 (comment)

Using chat.iridescent.nz, the community-hosted Element-web app for matrix.iridescent.nz, I created a new session, and verified it from my Android session. I'm able to access all my rooms, but in all the encrypted rooms (including DMs), all previous messages say "unable to decrypt" (including my own).

It's not out of the question that there's some user error involved. But I've been using Matrix for about 5 years and I've tried everything I can think of, done some web searching, and followed various advice on joinmatrix.org etc. Nothing has worked so far.

When the problem last happened I was using LibreWolf 130.0-3, on Fedora 40 Mate-Compiz. Today I upgraded to LibreWolf 130.0.1-1, from the Fedora repos. Not sure which version of Element-web I was using when I first noticed the problem, but it persists now in If there's any more info I can supply to help you track down the bug, please let me know.

Outcome

What did you expect?

To be able to view E2EE messages in rooms and Direct Chats even when they were sent before I created the new session.

What happened instead?

Every message, including my own, displays an "unable to decrypt" error message instead of the message contents.

Operating system

Fedora 40 Mate-Compiz

Browser information

LibreWolf 130.0-3

URL for webapp

https://chat.iridescent.nz

Application version

Element version: 1.11.74 Crypto version: Rust SDK 0.7.1 (c8c9d15), Vodozemac 0.6.0

Homeserver

https://matrix.iridescent.nz

Will you send logs?

Yes

@dosubot dosubot bot added A-E2EE S-Critical Prevents work, causes data loss and/or has no workaround labels Sep 28, 2024
@florianduros florianduros added S-Major Severely degrades major functionality or product features, with no satisfactory workaround O-Uncommon Most users are unlikely to come across this or unexpected workflow and removed S-Critical Prevents work, causes data loss and/or has no workaround labels Oct 3, 2024
@richvdh
Copy link
Member

richvdh commented Oct 3, 2024

@strypey I don't see debug logs from your android device. Did you send them?

@strypey
Copy link
Author

strypey commented Oct 6, 2024

@richvdh

I don't see debug logs from your android device. Did you send them?

Yes. Would you like me to send them again? FYI I'm using the SchildiChat fork, not vanilla Element, in case that makes any difference.

@richvdh
Copy link
Member

richvdh commented Oct 6, 2024

Oh, maybe. @SpiritCroc: do you use a separate rageshake repo for SchildiChat?

@richvdh
Copy link
Member

richvdh commented Oct 23, 2024

Looking at your logs, there are lots of lines like this:

2024-09-28T11:13:46.449Z W Error decrypting event (id=$<redacted> type=m.room.encrypted sender=@strypey:matrix.iridescent.nz room=!<redacted> ts=2023-09-25T05:45:35.486Z): DecryptionError[msg: This message was sent before this device logged in. Key backup is working, but we still do not (yet) have the key., session: <redacted>]

and

2024-09-28T11:13:47.049Z I [PerSessionKeyBackupDownloader] No luck requesting key backup for session 1HtKuFD7gX2p78upX09Hb3h3bOWIpXFcR3UIH64NVps: M_NOT_FOUND: MatrixError: [404] No room_keys found (https://matrix.iridescent.nz/_matrix/client/v3/room_keys/keys/!<redacted>/<redacted>?version=2)

That tells us that the keys you are hoping to be in key backup, aren't. It sounds like you're expecting your SchildiChat instance to have backed up the keys; if it isn't, then that's a matter to take up with the maintainer of that client.

If you can get hold of logs for your SchildiChat instance, I can take a look at what might be going wrong but you'd need to approach the SchildiChat maintainers in the first instance.

@richvdh richvdh closed this as completed Oct 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-E2EE O-Uncommon Most users are unlikely to come across this or unexpected workflow 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