Known issue decrypting previous messages

There's a big known known issue where when signing into a new session, cross-signing does not work, you cannot verify the session in any way (not even with the security key) and/or access the Secure Backup. This seems to be caused by a bug in the current (as of writing) Element web interface as well as some third party clients, which actually causes the client not to be able to use the Secure Storage which is used for both for the Secure Backup as the Cross Signing key.

If this happens to you:

  • You can't access previous encrypted messages (both private messages sent one on one and the ones in encrypted rooms)
  • Your session is unverified to others (red shield in Element). Some people have set their client to not send their public key to those sessions, resulting in even new messages not being decrypted.

If you have no issues on signin, verifying your session, entering your security key, etc. then proceed to Other/related issues and workarounds below.

The below “fix” is the result of trial and error and has successfully been used on two accounts on this and another server.

Proceeding with the steps below, means you'll loose access to anything not currently decrypted on the device you will use to fix the problem. What's decrypted on that device is the baseline.

Given the above, consider which device to use if you have more then one to choose from, or try to backup the keys manually before you proceed using the “Export E2E Room Keys” option, so you can later restore them once you have a working Secure Backup again to import them to.

  1. Make sure you have device with a session that considers itself verified (even if other devices don't agree) and that this is an official Element app (either mobile or desktop) but not the web-version. 1)
  2. Sign out of everything else but that one device.
  3. On this device, first reset cross-signing.
  4. Then delete and reset the key backup (I had it create a different key, without a passphrase, and stored that to a text file for the clean-ness and verifiability of the process).

Next time when signing in to either a new client or the web-interface, it'll hopefully ask you to verify with another device, and it will work (either with QR-code or the Emoji-comparison) by doing so from the device/session you used for the above process.

Result is that the session is verified and automatically gains access to the now restored keysafe without having to enter the security-key. This is also why the session you start with most likely needs to consider itself verified, which is why it's added as a prerequisite above.

Because it is the result of trial and error, you might have to try these steps more then once until it succeeds.

Other/related issues and workarounds

While you should have no issues talking to people in encrypted rooms or chats, you'll only be able to see the history from that session, as keys from previous sessions can not be saved and restored. On top of that, some message in encrypted rooms won't get decrypted if people have a certain setting enabled.

Some people have enabled one or more of these settings:

  • “Never send encrypted messages to unverified sessions from this session” on account level.
  • “Manually verify all remote sessions” on account level.
  • “Never send encrypted messages to unverified sessions in this room from this session” for a specific room.

If this is the case, due to the cause of the issue, you most likely will only see unable to decrypt when they send a message either one on one or in an encrypted room. The temporary workaround is the same as below, or for them temporarily disable the relevant setting(s).

The only way to talk to people while this is broken and retain history, is in an unencrypted room. Create a new room, make sure to leave it fully unencrypted in the settings, then invite the person or persons you'd like to talk too.


1)
In my case, this was Element iOS which I verified trough another device. The other device didn't recognise it as verified, which is part of the problem, but the important part is the app itself considered itself verified.