Prompted to request keys from other devices, even when it won't help

[jacotec]

Steps to reproduce

1. Element Web failed to decode a single message in an encrypted chat
   

2. The banner to request the keys from another device is displayed:
   

3. Although the messages reads fine on my iPhone and iPad (Element IOS), klicking the "Request key" button does not work, even if I have the IOS app open in the same chat.

4. Clearing the cache does not solve the issue

5. Logging into the web browser (Element-Web) shows the same messages as non-decryptable and the "Request key" button does not work at all here also

Message Raw data shows a "duplicate message index":

"msgtype": "m.bad.encrypted",
    "body": "** Unable to decrypt: DecryptionError: Duplicate message index, possible replay attack: 

Outcome

What did you expect?

First of all, I expect that the open and running Element Desktop App should be able to decrpty an incoming message.
But even if it misses a message key, the request from other devices should work at all.

What happened instead?

Although open and running, it misses two times the first message from the other party (both times it was the first text message after a picture was sent).

Klicking on "Request key from other device" does not work at all, now I have constantly the banner active in Element-Desktop and Element-Web.

The same issue is present in Element-Web!

Additional comment:

I found this issue which seems to cover the root cause: #16428
Unfortunately this is open since more than two years although it's tagged as S-Major.

I have the feeling that in fact the message is not missing the keys, but Element-Web (and Desktop) both by mistake interprete these messages as a "possible replay attack" due to whatever reason. That would explain why the "request keys" is not working (as in reality it is not missing keys) and why it appears on all Desktop and Web sessions even after clearing the cache.

Operating system

Windows

Application version

Version von Element: 1.11.29 Version von Olm: 3.2.12

How did you install the app?

Official Element download page

Homeserver

Synapse 1.81

Will you send logs?

No

[uhoreg]

The issue here is that your Element already has the key, but any decryption error triggers the prompt to request keys from other devices, which won't work in this case.

The issue of why you're getting a "Duplicate message index" is a separate matter, and is an issue on the sender side. I don't suppose you know what kind of device the sender is using?

[angloromanticism]

This is happening on sender and receiver, error only shows up on one my element desktop instance (Android/IOS various distros are fine), other user using IOS.

[jacotec]

@uhoreg The sender is an iDevice (iPhone, iPad) in all cases. Meanwhile I tracked this down to a point where I can reproduce it:

• Send an image from the iDevice in Element-IOS via the Share Extension (i.e. from the picture gallery)
• The next text message after this picture is causing the issue in Element-Web, but reads fine in all mobile apps (IOS and Android)

I guess I'll file an issue in Element-IOS as well ...

[uhoreg]

Thanks for opening the issue in Element-iOS

[kumarunster]

exactly the same, the room is getting unusable. The issue started to appear after auto update of element app on iOS devices.

1. Users gets untrasted
2. even after exchanging keys/verifiying session with emojis or qr code, users still stay with red shields.
3. '** Unable to decrypt: DecryptionError: Duplicate message index, possible replay attack:' messages appear
4. Element client started to show "Open another device to load encrypted messages" overlay

any suggestion how to fix?

[jacotec]

@kumarunster 3 and 4 can be related to the issue with the Share Extension in Element-IOS. Did you look at my referenced issue over there?

[arcuru]

Stepping back a little bit, the iOS and Android clients decrypt these messages without error or even a warning, and Element Web doesn't allow you to decrypt them at all.

Which behavior is correct? And which client needs a fix?

The Element team needs to discuss among themselves the right way to handle this across clients, because right now there are two different experiences, one of which gives a scary error message and another that gives no warning at all.

I am not an expert on the matrix protocol's crypto, but on a surface read this check may be overly restrictive and possibly based on a misread of the megolm spec.

[t3chguy]

Which behavior is correct? And which client needs a fix?

Web's. iOS and Android seem to be ignoring the possibility of a session replay attack

The Matrix spec says

Clients must guard against replay attacks by keeping track of the ratchet indices of Megolm sessions. They should reject messages with a ratchet index that they have already decrypted. Care should be taken in order to avoid false positives, as a client may decrypt the same event twice as part of its normal processing.

Android and iOS are spec non-compliant here. The Matrix spec doesn't say anything about comparing contents, only the ratchet indices.

[soda-pop-ice-cream]

I have same issue.
element-ios send me image, and only one session(schildichat-android) managed to decrypt it, other sessions had same error as @jacotec
I exported encryption keys from schildichat-android, imported them to element-android, and image was decrypted. But when i try to import those keys in to element-web or element-desktop, they just silently close after import and nothing changes.

[hieronymousch]

Have the same issue on element-web, seems to come only from iOS users in the same room... VERY annoying. It seems to be triggered by sending a picture, the next message is almost always in an encrypted state and unable to decrypt. No issues on Android. For the sender everything seems fine.
Tried veryifing by QR code, key phrase & importing E2EE keys, nothing changes

[kumarunster]

it is now simple not usable anymore. Even conversation on ios client are now garbige.

[jacotec]

@kumarunster Try to have the sender giving the command

/discardsession

in the affected room. That might help.

But you're right, it's super annoying and unfortunately there is no option to skip the "mandatory default E2EE" in direct chat rooms. A config option on the server here would have been a better choice unless E2EE really works for every situation.

Even more unfortunate that the Element-IOS devs seem to more or less ignore to fix the root causes

element-hq/element-ios#7499
matrix-org/matrix-rust-sdk#1960

of this issue although so many users are suffering from it.

[kumarunster]

@jacotec thanks for the insights
we just abandoded the private chat and created a uncrypted unpublic room, which is a nonsense, if the communication should stay secure.

[richvdh]

I think this banner has now been removed (not least because it never actually helped)