Broken Secret Storage Setup

[MichaelErjemenko]

Steps to reproduce

1. Create new SSO Account and sign in for the first time with the web client
2. Create a private room
3. Set up secret storage using a recovery key / without passphrase
4. Send a message
   => The message has a red shield.
   The security page in the settings shows that the session is connected with the secret storage and the cross signing is setup. The session page shows that this session is not trusted.
5. Sign out
   
6. and sign in again. The dialog for entering the recovery key appears several times but it doesnt help to decrypt the message.
   
   7 . Endless many POST matrix/client/v3/keys/query requests with 200 Response. It stops when clicking on the "Upgrade" button in the Encryption upgrade available modal / dialog. (See /keys/query loop in unverified sessions #27165)
7. In the security settings it is shown that the session "is not backing up your keys" in the secret storage.
   
8. Connecting to the secret storage leads to an error dialog Unable to restore backup when having entered the correct recovery key. The console prints (v1.11.64): Error: the signing key is missing from the object that signed the message
   

Outcome

What did you expect?

After step 4: The session should be trusted after setting up they secret storage.
After step 5: Entering the recovery key a single time and being directed to the chat with decrypted messages.

What happened instead?

After step 4: The session is not trusted.
After step 5: I had to enter the recovery key several times and the messages were not decrypted afterwards.

Operating system

Windows

Browser information

Google Chrome 123.0.6312.124

URL for webapp

No response

Application version

Element Web v1.11.64

Homeserver

Synapse v1.101.0

Will you send logs?

No

[MichaelErjemenko]

Some additional information:

There are no db entries at the server for the tables e2e_cross_signing_keys, e2e_cross_signing_signatures for this user.
The following tables seem to have "normal" entries:

• account_data: m.cross_signing.master, m.cross_signing.user_signing, m.cross_signing.self_signing, m.megolm_backup.v1, m.secret_storage.default_key, m.secret_storage.key.
• e2e_room_keys_versions: one version 1 entry with algorithm m.megolm_backup.v1.curve25519-aes-sha2, ...
• e2e_room_keys: one version 1 entry
• e2e_device_keys_json: one entry with device_id equals to the current device's id
  The following request can just be found one time (v1.11.61) / three times (v1.11.64) in the network tab of the developer tools of the browser. The request fails with a 401
  POST /_matrix/client/unstable/keys/device_signing/upload
  The tab doesn't show any device_keys/upload request.

Environment

The sign in is performed via SSO.
The above test was done for (at least) the settings:

Setting 1

Repository name	commit hash	version
element-web	ba2336a	v1.11.61
matrix-react-sdk	f96606acebaeea99e98c3a827575c76a68f37a5c	v3.95.0
matrix-js-sdk	78d05942a35a764ca2ae0de153ae38adf1d7c934	v31.5.0

Setting 2

Repository name	commit hash	version
element-web	180a1a2	v1.11.64
matrix-react-sdk	adc805828da3a5cc1f2a9dccc05ce83430166ff8	v3.97.0
matrix-js-sdk	e4937e62226a90428a66194cb2eb389c94fd848b	v32.0.0

[richvdh]

Please can you send a bug report from within your client after step 3?

[MichaelErjemenko]

Sorry but this is not possible. The urls and other information must not be published and I cannot guarantee to replace all information in the debug logs with a placeholder.

[richvdh]

Hrm, tricky. I've not been able to reproduce this at all, so without logs it's going to be hard to proceed.

[richvdh]

Some of the later stages of this sound much like #27252

[flesueur]

Hi,

I encounter this precise case, I can reproduce all the steps. Element 1.11.65 using SSO.

It appears starting from 1.11.58 when the rust crypto is activated ; 1.11.57 is ok.

I uploaded debug logs after step 3. I can also provide test accounts in my environment if you want to reproduce.

As proposed in #27252 , resetting cross-signing keys after this initial step solves this problem.

Cheers,
François

[richvdh]

I uploaded debug logs after step 3. I can also provide test accounts in my environment if you want to reproduce.

Sorry for the delay in coming back to this. Unfortunately we had to remove your logs due to a potential key exposure (CVE-2024-34353). If you (or anyone else) can reproduce this, could you please upload debug logs again?

[richvdh]

I'm closing this as we're still lacking logs, or a way to reproduce it.