element-hq
Unable to set up a secure backup in application
Steps to reproduce
Created new account; Verified account; closed application and then re-launched. Get an initial dialogue message "Set up Secure Backup; Safeguard against losing access to encrypted messages & data" with Later & Continue as options. However when trying to select Continue nothing happens, message does not go away, and no indicator is presented to the user that anything is even attempted. Only option is to select 'Later' to remove the message.
Outcome
What did you expect?
Expected that clicking the continue button to actually /continue/ to setting up the backup, or at the very least provide feedback to the user as to why it could NOT perform such an action so as to allow the user to try and take corrective action if needed.
What happened instead?
Nothing, clicking on continue had zero effect and did not even remove the dialogue. Only means to continue using the application was to click on 'later' which then upon the next launch get the same message again.
Operating system
Windows Server 2022 21H2
Application version
1.11.93
How did you install the app?
https://element.io/download
Homeserver
matrix.org
Will you send logs?
Yes
Looks like the account may have some kind of legacy 4S setup with a non-default key and the app is not handling it gracefully.
doubtful as it's a brand-new / fresh account and first-time install on the OS. So unless it's creating an old/legacy setup /by default/ in 1.11.93 (which I would say would be a MAJOR failure in the code) this would be false.
That's more strange then. Have you logged into the account from any other clients?
Have installed element on two other devices (also fresh, one linux one android) and in each case the exact same issue occurred. So it really appears to be a problem with the code base across platforms.
Then it's a problem that was coded the same way across each application. If windows (x64); linux/ubuntu 24.04 (x64) and android 14 all show the same issue, then logically it's either due to all platforms referencing the same external and getting stuck the same way, or all platforms coded the same way with a similar implementation problem.
Or there being issue with the other part of the system that's in common: Your server or account.
true, but the sever is matrix.org; and have now created a second account with the same problem (in a VM (esxi) fresh OS install, windows 10ltsc), so as to not bring over anything from the other tests). Not discounting it, but have tried to limit as much as possible from the user perspective.
Having the same issue mate, hope it's fixed
If it helps, I'm running Element using the vectorim/element-web image on docker with Conduwuit. The backup seems to work if you reset your keys at least once though.
I have this issue too.
I see this in the dev console:
rageshake.ts:69 Error bootstrapping secret storage Error: Could not decrypt m.cross_signing.master because none of the keys it is encrypted with are for a supported algorithm
at async CreateSecretStorageDialog.tsx:257:30
I reset keys, device verification, nothing helped. I can't create key backup in Windows Element-desktop, Linux Element-desktop, Android Element X.
Hi,
I have the same issue on my user. I'm self-hosted and issue happens on all type of devices:
- Element Android: 1.6.36, matrix SDK version 1.6.36 (5179f934) Crypto version: Rust SDK 0.9.0 (bb57311) Vodozemac 0.8.1 on this device, when I open the Recovery Key menu, I have a popup Cannot find secrets in storage
- Element X: 25.04.3 (202504030)
- Element desktop: 1.11.99 Crypto version: Rust SDK 0.10.0 (3cc301d), Vodozemac 0.9.0
- Element Web: v1.11.99
Both Synapse server: 1.126.0 and 1.128.0
Thanks for investigate this
The logs contain the following:
2025-03-08T18:38:11.635Z D SecurityManager: getSecretStorageKey: request for 4S keys [svYxtfLlkD7iydzLuVLUPlFinyCtHDKF] for secret `m.cross_signing.master`: looking for key svYxtfLlkD7iydzLuVLUPlFinyCtHDKF
2025-03-08T18:38:11.635Z I Default empty getSecretStorageKey() => null
2025-03-08T18:38:11.635Z D SecurityManager: getSecretStorageKey: request for non-default key svYxtfLlkD7iydzLuVLUPlFinyCtHDKF: not prompting user
2025-03-08T18:38:11.635Z I Default catchAccessSecretStorageError() => void
2025-03-08T18:38:11.635Z E SecurityManager: accessSecretStorage: error during operation Request for non-default 4S key
Error: Request for non-default 4S key
at Object.getSecretStorageKey (vector://vector/webapp/bundles/4858aa408f4ad56a6748/init.js:1:141177)
at async c.getSecretStorageKey (vector://vector/webapp/bundles/4858aa408f4ad56a6748/3878.js:2:401624)
at async c.get (vector://vector/webapp/bundles/4858aa408f4ad56a6748/3878.js:2:401021)
at async C.bootstrapCrossSigning (vector://vector/webapp/bundles/4858aa408f4ad56a6748/1787.js:1:14207)
at async re.bootstrapCrossSigning (vector://vector/webapp/bundles/4858aa408f4ad56a6748/1787.js:1:51797)
at async vector://vector/webapp/bundles/4858aa408f4ad56a6748/init.js:1:143069
at async P (vector://vector/webapp/bundles/4858aa408f4ad56a6748/init.js:1:142239)
at async N (vector://vector/webapp/bundles/4858aa408f4ad56a6748/init.js:1:142344)
at async onPrimaryClick (vector://vector/webapp/bundles/4858aa408f4ad56a6748/element-web-app.js:1:55604)
As @dbkr said, this means that there is a problem with the secret storage on the account, likely due to a bug in a client.
Unfortunately, it's going to be rather difficult, this long after the event, to figure out which client caused that corruption and how. It looks like it wasn't the client that we have logs from (or at least, it's been going on for longer than the logs go back).
@stevecs:
- Have you now got your account working? I can't see anything obviously wrong on the server side, but it's possible I'm missing something.
- You mentioned that you were able to reproduce the problem on a fresh account. I'd be interested to know if this is still the case.
We're tracking a proper fix to this at https://github.com/element-hq/element-web/issues/29553, by the way.
Unfortunately, it's going to be rather difficult, this long after the event, to figure out which client caused that corruption and how. It looks like it wasn't the client that we have logs from (or at least, it's been going on for longer than the logs go back).
* Have you now got your account working? I can't see anything obviously wrong on the server side, but it's possible I'm missing something. * You mentioned that you were able to reproduce the problem on a fresh account. I'd be interested to know if this is still the case.
I think we've done all we can here without any further information