ElementR: Unable to verify with security key after login

[florianduros]

Steps to reproduce

1. Login
2. Click on verify with security key
3. Upload security key
4. Click on continue
5. Back to Verify this device dialog

Enregistrement.de.l.ecran.2023-09-27.a.11.33.25.mov

Outcome

What did you expect?

I was expecting the device to be verified after the security key upload

What happened instead?

The device is not verified

Operating system

No response

Browser information

No response

URL for webapp

No response

Application version

No response

Homeserver

No response

Will you send logs?

Yes

[richvdh]

Hum, I can repeat this on non-rust crypto

[richvdh]

Can reproduce on current element release (Element version: 1.11.44)

[richvdh]

In the console:

 Error: Key type master from getCrossSigningKey callback did not match
    getCrossSigningKey CrossSigning.ts:155
    checkOwnCrossSigningTrust index.ts:1728
    bootstrapCrossSigning index.ts:869
    bootstrapCrossSigning client.ts:2861
    accessSecretStorage SecurityManager.ts:356
    usePassPhrase SetupEncryptionStore.ts:146
    usePassPhrase SetupEncryptionStore.ts:145
    SetupEncryptionBody SetupEncryptionBody.tsx:86
    unstable_runWithPriority scheduler.production.min.js:18

[richvdh]

The problem seems to be that the published public cross-signing key does not match the private cross-signing key in 4S. So it is specific to my and florian's test account. TBD how our accounts got into that state

[andybalaam]

Confirmed I am able to log in and verify my device with a security key on develop.element.io

[richvdh]

Our suspicion is that something in EWR broke this

[richvdh]

On my test account, the secret cross-signing keys in 4S were updated at account_data stream_id 2149904648. This is before May this year.

The public cross-signing key was updated at device_lists_stream stream_id 7874772749. This was around July this year. I am perfectly prepared to believe that I did something weird at that point.

[richvdh]

Florian's secret key was updated at account_data stream_id 2486950029 (about 2023-09-27 09:50:18 UTC).
The public key was updated at device_lists_stream id 8550863632 (about the same time).

These postdate the video above.

Prior to that: the public key was updated at device_lists_stream id 8543333091 (about 2023-09-26 15:24:16). Unfortunately we don't have any information on the previous private key update.

2023-09-26 15:24:09,972 - synapse.access.http.8080 - 465 - INFO - POST-80cc831d699900c6-CDG - <redacted ip> - 8080 - {@testing_florian1:matrix.org} Processed request: 0.622sec/0.028sec (0.008sec, 0.004sec) (0.013sec/0.136sec/6) 2B 200 "POST /_matrix/client/v3/keys/device_signing/upload HTTP/1.1" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:109.0) Gecko/20100101 Firefox/117.0" [0 dbevts]

This looks like an Element Web R implementation (because legacy crypto incorrectly uses an unstable endpoint).
We can also see the private key being updated at that point:

2023-09-26 15:24:02,946 - synapse.access.http.29101 - 465 - INFO - PUT-80cc82f50d5700c6-CDG - <redacted ip> - 29101 - {@testing_florian1:matrix.org} Processed request: 0.197sec/0.006sec (0.002sec, 0.000sec) (0.141sec/0.024sec/3) 2B 200 "PUT /_matrix/client/v3/user/%40testing_florian1%3Amatrix.org/account_data/m.cross_signing.master HTTP/1.1" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:109.0) Gecko/20100101 Firefox/117.0" [0 dbevts]

Will put this investigation on hold pending more info from Florian.

[florianduros]

Closing it, I'm unable to reproduce it right now

[Jeinzi]

I experience the same issue with element-desktop 1.11.52, crypto version Olm 3.2.15 as installed from the AUR, though I don't get the error message in the console.