room_key_requests not sent for messages in a thread

[jeffrson]

Steps to reproduce

When I log in from a new browser session some messages in threads apparently cannot be unencrypted. Those messages are available on other devices and can be read there.

AFAICT, indeed, only messages in threads are affected - some of these message had been sent by me.

I was able to somewhat fix it by temporarily loading an older version of element (1.11.16) where I could request keys for single messages. While I did this, threading (beta) was disabled, not by purpose, but it may have helped...
Returning to current version (1.11.24) keeps these messages unencrypted.

So to conclude, it seems, Element is missing messages when requesting keys.

PS: I'm afraid I cannot send log files because due to the workaround messages are okay now. However, the log I sent for #24720 should have had the issue.

Outcome

All messages are decrypted by downloading keys from other sessions.

Operating system

Windows

Browser information

Chrome 110.0.5481.178

URL for webapp

1.11.24

Application version

Element: 1.11.24 Olm: 3.2.12

Homeserver

synapse 1.77.0

Will you send logs?

No

[richvdh]

It seems like the server-side key backup should have provided the keys, so I'm not really sure why that didn't work for you.

However, I was able to reproduce this as follows:

1. Start with two test users, Alice and Bob.
2. In Bob's session, disable Secure Backup. (Clicking on 'Delete Backup' does this; I couldn't easily find another way.)
3. Start an encrypted DM from Alice to Bob.
4. Send a message from Alice to Bob.
5. Have Bob reply in a thread. Do not send messages outside the thread from Bob.
6. Start a new session for Bob. (Do not log out the existing one.)
7. Jump through the verify-new-device hoops.
8. At this point, all the messages in the room are UTD. room_key_requests should have been sent after the new session was created, but they will have been ignored as coming from an unverified device.
9. Click "resend key requests", wait a couple of seconds
10. Observe that messages outside the thread are now decryptable, but those sent in the thread are still UTD.

[jeffrson]

Thank you! That seems to reproduce the behaviour correctly.

PS: I'm not sure, if Secure Backup was disabled. Unfortunately, I don't quite understand yet, how key backups are handled (whether in browser store or indeed server-side). Making a backup is somewhat confusing ("This session is backing up your keys.", Restore, Delete, Reset).

[richvdh]

PS: I'm not sure, if Secure Backup was disabled.

It's possible that you were affected by some problem in Secure backup (or just that it can be slow to restore, see element-hq/element-meta#757).

(It's also possible that you never set it up, but it sounds like you have.)

In any case, that is the real bug here; we're planning to phase out room key requests (at least for this purpose).

Unfortunately, I don't quite understand yet, how key backups are handled (whether in browser store or indeed server-side).

They are stored, encrypted, on the server-side.

Making a backup is somewhat confusing ("This session is backing up your keys.", Restore, Delete, Reset).

I don't disagree with you there. But as long as the "✅ This session is backing up your keys" indicator is present on your original session, new sessions should automatically have pulled the keys for all your conversations from the backup.

Anyway, I'm going to close this as a WONTFIX. If you see similar problems in future, please send more debug logs and we can figure out why Secure backup didn't work for you.

[richvdh]

Making a backup is somewhat confusing ("This session is backing up your keys.", Restore, Delete, Reset).

FWIW, this is covered in element-hq/element-meta#1886.