element-ios: Wrong message index when sending an image via Share Extension, message not decryptable in Element-Web, can break rooms when session-ID is affected!

I just want to jump in to emphasize the impact of this bug: We have real users that are getting these errors daily. Some of them have learned to live with it because they have to but deeply hate the app and will invite other users to jump out to other chat apps/platforms when possible. This is no way of growing the user base of matrix.

The root cause of this behaviour is stale cache for outbound group sessions between the main app and share extension, which run as two separate processes on the OS. This means they each need to open their own crypto database and do not share any in-memory cache.

1. Share extension sends an encrypted message, increments the ratched index, and saves changed session back to store
2. Main app resumed from background uses cached session to encrypt the next message, which still has the unchaged index. This causes the second message to have a duplicate index.

Note that this behaviour does not occur if the main app is not running, precisely because there are no values in cache and so the session has to be fetched from the store.

The most straightforward solution is to not use session cache and instead load the session from the store for each encryption. A more error-prone approach is to trigger cache refresh explicitely each time the app is brought to foreground

@Velin92 Any progress here? Why is this still “minor” as it 100% reproducibly appears with any use of the share extension at any single IOS user.

And there is the great analysis of the root cause by @Anderas … what else is missing to fix this?

This is a real showstopper issue …

What is the point in failing to decrypt in a replay attack. It can just highlight the user with warning that the message can be a replay attack.

@leematos Try to issue the command

/discardsession

into the DM. Should be done by both sides.

@Galbar 100% the same here. The additional mess is that the use of the Share Extension in encrypted rooms seems also to be responsible for the states where the room completely breaks and can be recovered only with a “/discardsession” on both sides. That seems to appear in situations where the cache inconsistency not only gives a wrong message ID but also a wrong (old) session ID because it recently changed in the main app.

@Velin92 @BillCarsonFr As this issue is IMHO responsible for >90% of all issues in encrypted rooms (which are default for DMs) and with the understanding that completely fixing the caching issue might take more time (although it’s more than worth it with all the trouble it causes for IOS users) - what about a quick hotfix by simply disabling the session cache and always read from the store until it’s finally fixed? Would the performance impact be noticeable at all?

this is happening without the “share” extension: sending plain text over iOS app sporadically returns the following when opening on MacOS desktop install: “type”: “m.room.message”, “content”: { “msgtype”: “m.bad.encrypted”, “body”: "** Unable to decrypt: DecryptionError: Duplicate message index, possible replay attack: "

@Velin92 Are there any plans to fix this encryption cache inconsistency in short term? I have daily complaints of my users regarding this, and the Share Extension is heavily used.