Cannot verify devices on account with working 4S but no published public cross-signing keys

[richvdh]

Suppose you have a user account, where SSSS has been set up, and contains the private cross-signing keys, but the public keys have never been published. See https://github.com/element-hq/element-web/issues/27253.

Now, when you log in on the account:

1. You are prompted for your 4S passphrase:
2. Enter 4S passphrase.
3. You are prompted a further two times for 4S passphrase.
4. It still fails, even after all that: Console reports:

       WARN matrix_sdk_crypto::store: No public identity found while importing cross-signing keys, a /keys/query needs to be done
       Error bootstrapping cross-signing Error: the signing key is missing from the object that signed the message
           at module.exports.__wbindgen_error_new (index.js:9867:1)
           at matrix_sdk_crypto_wasm.wasm.wasm_bindgen::JsError::new::ha883f446bf57a3fd (matrix_sdk_crypto_wa…-0881f436:0x17b4bac)
           at matrix_sdk_crypto_wasm.wasm.matrix_sdk_crypto_wasm::future::future_to_promise::{{closure}}::h69162113e82d4886 (matrix_sdk_crypto_wa…-0881f436:0x1607641)
           at matrix_sdk_crypto_wasm.wasm.<T as futures_util::fns::FnOnce1<A>>::call_once::h66e7cefc41dc8442 (matrix_sdk_crypto_wa…-0881f436:0x18ad0b4)
           at matrix_sdk_crypto_wasm.wasm.<futures_util::fns::MapErrFn<F> as futures_util::fns::FnOnce1<core::result::Result<T,E>>>::call_once::{{closure}}::h94a11c4d36abd7a7 (matrix_sdk_crypto_wa…-0881f436:0x1906219)
           at matrix_sdk_crypto_wasm.wasm.core::result::Result<T,E>::map_err::h61ac269bc4134dbe (matrix_sdk_crypto_wa…-0881f436:0x13dd6bb)
           at matrix_sdk_crypto_wasm.wasm.<futures_util::fns::MapErrFn<F> as futures_util::fns::FnOnce1<core::result::Result<T,E>>>::call_once::h14b9005db0a46cbf (matrix_sdk_crypto_wa…-0881f436:0x1967c2a)
           at matrix_sdk_crypto_wasm.wasm.<futures_util::future::future::map::Map<Fut,F> as core::future::future::Future>::poll::hd56fd2c68aa16e05 (matrix_sdk_crypto_wa…m-0881f436:0xf54621)
           at matrix_sdk_crypto_wasm.wasm.<futures_util::future::future::Map<Fut,F> as core::future::future::Future>::poll::h38cc453636d8daec (matrix_sdk_crypto_wa…-0881f436:0x18ae3fb)
           at matrix_sdk_crypto_wasm.wasm.<futures_util::future::try_future::MapErr<Fut,F> as core::future::future::Future>::poll::h05eb7142cd1307b3 (matrix_sdk_crypto_wa…-0881f436:0x18ad953)
           at /home/rav/work/matrix-rust-sdk/crates/matrix-sdk-crypto/src/store/mod.rs:1212
   
           (anonymous) @ CreateCrossSigningDialog.tsx:163
   

5. Press "Cancel". EW now launches.
6. Under "Security & Privacy":
7. Click "Verify this session"
8. You are prompted (yet again) for 4S passphrase.
9. Entering correct password returns you to "Verify this session" dialog. Console reports:

       Error: the signing key is missing from the object that signed the message
           at module.exports.__wbindgen_error_new (index.js:9867:1)
           at matrix_sdk_crypto_wasm.wasm.wasm_bindgen::JsError::new::ha883f446bf57a3fd (matrix_sdk_crypto_wasm.wasm-0881f436:0x17b4bac)
           at matrix_sdk_crypto_wasm.wasm.matrix_sdk_crypto_wasm::future::future_to_promise::{{closure}}::h69162113e82d4886 (matrix_sdk_crypto_wasm.wasm-0881f436:0x1607641)
           at matrix_sdk_crypto_wasm.wasm.<T as futures_util::fns::FnOnce1<A>>::call_once::h66e7cefc41dc8442 (matrix_sdk_crypto_wasm.wasm-0881f436:0x18ad0b4)
           at matrix_sdk_crypto_wasm.wasm.<futures_util::fns::MapErrFn<F> as futures_util::fns::FnOnce1<core::result::Result<T,E>>>::call_once::{{closure}}::h94a11c4d36abd7a7 (matrix_sdk_crypto_wasm.wasm-0881f436:0x1906219)
           at matrix_sdk_crypto_wasm.wasm.core::result::Result<T,E>::map_err::h61ac269bc4134dbe (matrix_sdk_crypto_wasm.wasm-0881f436:0x13dd6bb)
           at matrix_sdk_crypto_wasm.wasm.<futures_util::fns::MapErrFn<F> as futures_util::fns::FnOnce1<core::result::Result<T,E>>>::call_once::h14b9005db0a46cbf (matrix_sdk_crypto_wasm.wasm-0881f436:0x1967c2a)
           at matrix_sdk_crypto_wasm.wasm.<futures_util::future::future::map::Map<Fut,F> as core::future::future::Future>::poll::hd56fd2c68aa16e05 (matrix_sdk_crypto_wasm.wasm-0881f436:0xf54621)
           at matrix_sdk_crypto_wasm.wasm.<futures_util::future::future::Map<Fut,F> as core::future::future::Future>::poll::h38cc453636d8daec (matrix_sdk_crypto_wasm.wasm-0881f436:0x18ae3fb)
           at matrix_sdk_crypto_wasm.wasm.<futures_util::future::try_future::MapErr<Fut,F> as core::future::future::Future>::poll::h05eb7142cd1307b3 (matrix_sdk_crypto_wasm.wasm-0881f436:0x18ad953)
   

[richvdh]

For now, I think the best workaround is to "Reset" cross-signing from the "Security & Privacy" page.

[venimus]

I have the same issue. Not reproducible in 1.11.53 (can't pinpoint the breaking version, but looks like ~1.11.6x). Same is with app.element.io. I have SSO only enabled if that matters

[davidmehren]

Two of my colleagues experienced this bug recently. The "connect to Key Backup" button resulted in an error message and the signing key is missing from the object that signed the message appeared in the console.

Of note is that the "Reset" button under key backup in settings did not help. It creates a new recovery key, but cross-signing is still not set up after that. When you then try to set up cross signing, it wants a recovery key, but not the recovery key that was just created by resetting key backup. Very confusing.

What finally helped was the "reset all" in the recovery key prompt dialog box. That created another new recovery key, but both key backup and cross-signing were working after that.

[venimus]

Two of my colleagues experienced this bug recently. The "connect to Key Backup" button resulted in an error message and the signing key is missing from the object that signed the message appeared in the console.

Of note is that the "Reset" button under key backup in settings did not help. It creates a new recovery key, but cross-signing is still not set up after that. When you then try to set up cross signing, it wants a recovery key, but not the recovery key that was just created by resetting key backup. Very confusing.

What finally helped was the "reset all" in the recovery key prompt dialog box. That created another new recovery key, but both key backup and cross-signing were working after that.

same behavior, had to downgrade the client to 1.11.55

[richvdh]

I think this is more "Element R roundoff" than "UTD fixes"; updating the workstream accordingly

[kegsay]

https://github.com/element-hq/element-web/issues/26322 feels like a common way for real people to hit this, which would explain why we see this more in the wild and not at all in tests.

[Viajaz]

This seems to occur if a user has performed multiple sessions in the same browser without setting up the Secure Backup with Security Key and then finally does so. During our evaluation with users, this was a major UX problem that caused data loss and horrible user feedback.

I would actually prefer a configuration flag in Element Web that simply forces the user to setup Secure Backup/Security Key/Security Phrase before continuing, a similar UI workflow to requiring the Security Key itself once it's configured.

[t3chguy]

@Viajaz https://github.com/element-hq/element-web/blob/develop/docs/e2ee.md#requiring-secure-backup

[iamtakingiteasy]

@Viajaz https://github.com/element-hq/element-web/blob/develop/docs/e2ee.md#requiring-secure-backup

~~This is not an element-web setting, but rather server-wide one, potentially affecting every client for something that is an issue of element-web of specific versions and/or configuration.~~

~~Consider the case of multiple element instances of various versions on different subdomains. This should be configurable from element-web instance-local config.json to not require a workaround for a workaround in form of also having different server proxy domains to serve different .well-known endpoints.~~

Nevermind, https://github.com/element-hq/element-web/blob/develop/docs/config.md#homeserver-configuration already provides .well-known content override.

[richvdh]

This remains a problem. The only real difference is that the wording of the dialog has changed: we prompt you for your recovery key rather than your "security phrase". We still ask you three times, and it still fails in much the same way.