Unable to decrypt errors after Synapse restart (for some E2EE chats with unverified devices)

[fearedbliss]

Hello,

I've noticed that sometimes when I restart my Synapse server, only for E2EE chats (private 1-on-1 or private group chats) where there are unverified devices (In this case most of my chats are unverified since the current verification process w/o cross signing is not good for long-term device approval and thus verifying at the moment is pointless if you are logging in/out frequently or from different devices). I've noticed that if I don't restart, everyone can communicate fine for the duration of the homeserver instance running the same process, etc. However, once I restart my synapse server, as people continue chatting, one or more people start to complain that there are not able to read the messages (unable to decrypt). In this case, the workaround I've given the users is that the sender for the message for which they can't read, needs to "verify" (let's say using legacy verification to speed things up) the person who cannot read their message. Once they verify the target device, it seems that the next message the original sender sends, can now be read by the target user.

Ticket #6363 that's going out with 1.6 seems very similar to the above error but since it mentions public chats, I'm not sure if this issue is the same or different. I'm making the ticket so this doesn't get lost in the Synapse Admin channel when I first mentioned it recently.

As for my current configuration:

Server:
Debian 10 (Latest Updates)
Synapse 1.5.1 (Direct, Not Docker/Etc)

Clients:
Latest versions of Riot Android, Riot iOS, and one machine on the Riot Web React App (on Linux) depending on the user.

[richvdh]

I'm struggling to understand your description, but I think you're saying that you're seeing occasional decryption failures, and you think it's related to device verification and/or server restarts.

Verification shouldn't be necessary for E2E to work, and I'd be surprised if it was actually related to server restarts rather than that being coincidental.

Either way, the best way to get a resolution is to report bugs against the relevant clients, and send rageshakes from both the sending client and the receiving client. It's essentially impossible to track down E2E failures without that information.

I'm going to close this as a duplicate of element-hq/element-web#2996. Thanks for the report though!

[fearedbliss]

@richvdh that's correct rich. The above is a description of what's happening and specifically what combination is necessary to be able to try and replicate this. I do strongly believe that this is a specific mixture of non-verified devices, and server restarts. As I said before, normally E2EE conversations work well and don't usually have a problem with failure to decrypt, however, I only ever notice things breaking with my home server restarts. Something is happening where the session of something of specific people, lose the keys for an existing (non verified) sender in the chat room, and then from that point on any new messages sent by that person will not be able to be decrypted. The sender of the message needs to verify the person for them to basically "re-send" their keys to that person, and thus allow that person to read their messages again.

I didn't open the bug with a particular implementation since I believe it's Synapse related and the current mixture of clients I have at the moment are using all riot clients and riot web

[richvdh]

either way, we'll need client-side logs from both sides to understand what's going on.

[fearedbliss]

@richvdh yup, I sent these logs a few weeks ago and messaged you on the matrix channel as well when we last discussed this issue. The logs were connected to a different issue that was similar to this one as well, however I've opened this ticket to make sure the issue doesn't get lost and also with the recent work with #6363