** Unable to decrypt: The sender's device has not sent us the keys for this message. **

[waclaw66]

Steps to reproduce

1. There are some historical messages sent from my devices.
2. Element Web shows just ** Unable to decrypt: The sender's device has not sent us the keys for this message. **
3. Newly created Element Android session can decrypt them properly.

Outcome

What did you expect?

Element Web should be able to decrypt historical messages when newly created Element Android session can do it.

What happened instead?

Element Web cannot decrypt some historical messages for some reason. Clicking to Re-request encryption keys from your other sessions works only if another Element Android session is online, another Element Web sessions are not able to help (obviously because suffer with the sam bug).
Seems Element Web cannot retrieve message keys directly from homeserver, but re-requesting them from devices works, that's strange. Nevertheless those keys has to be present on homeserver because newly created Element Android sessions can retrieve them.

Operating system

Windows 10

Application version

Element: 1.9.4 Olm: 3.2.3

How did you install the app?

No response

Homeserver

own

Will you send logs?

Yes

[Palid]

@waclaw66 try cross-verifying sessions that have those keys between themselves and request keys again. We're currently not properly informing users about the need of cross-verification of sessions properly, and this seems like one of those issues.

[waclaw66]

@waclaw66 try cross-verifying sessions that have those keys between themselves and request keys again. We're currently not properly informing users about the need of cross-verification of sessions properly, and this seems like one of those issues.

All those sessions are cross-verified.

[waclaw66]

I have tried to filter /_matrix/client/r0/sendToDevice/m.room_key_request/ requests from journal. It turned out that these requests come from Element Web only as a fallback retrieval when console error message Error decrypting event (id=$fIy7...): DecryptionError[msg: The sender's device has not sent us the keys for this message., session: FaX....] is shown.
On the other hand a new session of Element Android can retrive all message keys without that sendToDevice requests at first bite. Element Web doesn't, there have to be some Element Android devices online to retrive those message keys from them.

[waclaw66]

Now tested on app.element.io with matrix.org account. The same problem...

Account sessions cross-signed, key backup properly set up, Elelement Android no problem.

[waclaw66]

I have discovered that the only way how to avoid those ** Unable to decrypt... messages is not to cross-sign with another device, but to use recovery passphrase instead. All message are immediately show as decrypted then.

[tepozoa]

This happens to me regularly using both Firefox and Chrome on two different laptops, with the Android client being the "not broken" device used for fixing it every time it happens; but it's inconsistent on when it happens. I notice that the session_id changes which is possibly a trigger.

1. app.element.io is running in a browser tab, friend sends message A (working)
2. log out of the webapp, close browser which clears cache, reboot
3. log into the webapp, supply Security Key in 2nd login dialog (I store it in my password manager)
4. the friend sent a message while I was rebooting and it now cannot be decrypted; friend did not use a different device or do anything on their side except type a new message and hit send
5. go through the cross-signing emjoi verification between webapp + Android, it technically works but message still can't be decrypted
6. shift+refresh browser tab, webapp reloads but states latest message can't be decrypted
7. click the link to try cross-signing keys again and it then magically decrypts without actually cross-signing

The last two steps 6-7 happen sporadically (I'd say < 20% of the time), but steps 1-5 happen quite often (at least 50% of my webapp logins if not more towards 70%). But sometimes, the exact same process logging back in "just works" and decrypts all new messages received during the webapp being logged out.

I manually used the View Source option of the two messages which just happened this morning and had me digging for this bug report, and verify that the friend's device_id and sender_key ARE THE SAME, which means that it did/does in fact have that key and can in fact decrypt the old message received before the reboot if it used the key, but a new message sent from their same device with the same key fails after the reboot because... something is broken in the code somewhere.

What is different in the source - besides the ciphertext and date/time stamp type things is the session_id value:

message received before logging out

  "content": {
    "algorithm": "m.megolm.v1.aes-sha2",
    "device_id": "AAAAAAAAAA",
    "sender_key": "BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB",
    "session_id": "CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC"
  },

message received after logging out, reboot, log in, provide Security Key

  "content": {
    "algorithm": "m.megolm.v1.aes-sha2",
    "device_id": "AAAAAAAAAA",
    "sender_key": "BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB",
    "session_id": "DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD"
  },

The message about not having the key to decrypt may be erroneous, as I have the key, know the key and it's in there (and could see all pre-reboot messages using that key); it's the new message with the same key and a different session_id which is failing to decrypt properly.