Set up Secure Backup shows when it's already set up

[HarHarLinks]

Steps to reproduce

1. boot up Element Desktop some day

Outcome

What did you expect?

I am still connected to my secure backup, and there is no false error.

What happened instead?

I receive the message asking me to set up secure backup. Clicking continue asks me to reset my identity instead, which I definitely do not want nor do I see why i would suddenly need to! I have my backup key safely stored in my password manager.

This is extremely scary and confusing. It is also harder than before to tell if my backup appears to be connected or not, since the settings basically don't show anything anymore.

Operating system

Arch

Application version

Element Nightly version: 2025060201 Crypto version: Rust SDK 0.11.0 (404ca47), Vodozemac 0.9.0 - but the same happens on app.element.io

How did you install the app?

aur, but the same happens on app.element.io

Homeserver

synapse 1.131.0

Will you send logs?

Yes

[richvdh]

It is also harder than before to tell if my backup appears to be connected or not, since the settings basically don't show anything anymore.

The settings that were there before were basically nonsense at best, and a pack of lies at worst, so don't read too much into that.

Nevertheless, this clearly isn't working as intended. There seems to be a combination of several failure modes here.

The first problem is that your account is in a weird state. From the logs:

2025-06-28T12:00:25.796Z D SecurityManager: accessSecretStorage: bootstrapCrossSigning
2025-06-28T12:00:25.796Z D SecurityManager: getSecretStorageKey: request for 4S keys [d4H2aCsBhpMJsaHUjSEcMgkvptMePwAu] for secret `m.cross_signing.master`: looking for key d4H2aCsBhpMJsaHUjSEcMgkvptMePwAu
2025-06-28T12:00:25.796Z I Default empty getSecretStorageKey() => null
2025-06-28T12:00:25.796Z D SecurityManager: getSecretStorageKey: request for non-default key d4H2aCsBhpMJsaHUjSEcMgkvptMePwAu: not prompting user

In other words, your cross-signing keys are stored in 4S, but encrypted via some secret which is not (any longer?) your recovery key. I don't know how/when that happened.

We detect this situation and show a toast about it, but we show the wrong toast. This problem will be fixed by #30230, so we will instead show "Secret storage out of sync" or somesuch.

Then there is the fact that, even if it were the right toast, we don't handle non-default 4S keys well. This is tracked at #29553, though I suspect the symptoms have changed considerably since that was opened.

[HarHarLinks]

So, what to do now?

I can share the additional info that my SchildiChat Next 0.10.4-test1 based on Element X 25.06.3 is fine (in the sense that it doesn't complain). I could log into plain Element X and rageshake to send you more logs from a different perspective?

How could my 4S possibly no longer be encrypted by my recovery key without breaking? What's a non-default 4S key? Are we certain it is not the local Element Desktop that is confused about what my recovery key is? Can I check and/or set the presumably correct recovery key (according to my password manager)?

[richvdh]

How could my 4S possibly no longer be encrypted by my recovery key without breaking?

Well, it can't, in short. Your 4S is broken, and that's why EW is trying to warn you about it. It's making a pig's ear of it, but still.

What's a non-default 4S key?

https://spec.matrix.org/v1.15/client-server-api/#secret-storage may be helpful here, but to summarise:

The "default" 4S key is the key with the ID encoded by the account data m.secret_storage.default_key. That account data has the format:

{
    "key": "<key id>"
}

where <key id> refers to a second piece of account data, m.secret_storage.key.<key id>, which itself has the format:

{
    "algorithm": "m.secret_storage.v1.aes-hmac-sha2",
    "mac": "1ccEnOd98dGIPLCgm53DxDhLfg5/HSOsZ1N73jWMvDk=",
    "iv": "bG9LEBq6Ylcmr3PQsI8ERw==",
    "signatures": { /* ... */ }
}

That second piece of data tells clients about the 4S key (i.e., it is enough for a client to know if you have entered the correct key) without telling anyone what the actual key is.

Then, each secret (the three cross-signing keys, and the key backup key) are each encrypted using the 4S key, and stored in yet more account data such as m.cross_signing.master, like so:

{
    "encrypted": {
        "<key id>": {
            "iv": "FhYtsLVAot1vQvPlcvoDZQ==",
            "mac": "TSlNMqU2nOTCasivcmEVU98J9pfXyYc2PyiPYm8wL5Q=",
            "ciphertext": "DaYPUNUozWfoKA9OywP7GF8TLqq3mvhbufB1zo7gVZR3F3ZapMkZzoHT3h8="
        }
    }
}

So, we can tell which 4S key a given secret was encrypted with, given the JSON.

Note that all the above account data is designed to be shared with the server (which, for this purpose, we assume to be adversarial) and can therefore be shared freely.

Normally, we expect all your secrets to be encrypted with the same 4S key, and that key to be the key identified by m.secret_storage.default_key. But when something gets messed up, we end up with secrets encrypted with older keys, and clients start getting confused.

Are we certain it is not the local Element Desktop that is confused about what my recovery key is?

I am reasonably certain, yes: "request for non-default key" is a pretty clear diagnostic that your 4S has got messed up, as above; though you can inspect the account data yourself to confirm this. Feel free to reach out to me if you need a hand confirming this.

The interesting question is how/when this happened. If you have server-side logs, you may be able to find the PUT /account_data requests.

Can I check and/or set the presumably correct recovery key (according to my password manager)?

Well, what we need to do is reset recovery/4S. "Change recovery key" on the "Encryption" tab (your third screenshot) is the right button for that. However, Element no longer allows you to choose your own passphrase, so there will be no way to make it match what you have in your password manager.

[HarHarLinks]

where <key id> refers to a second piece of account data, m.secret_storage.key.<key id>, which itself has the format:

{
"algorithm": "m.secret_storage.v1.aes-hmac-sha2",
"mac": "1ccEnOd98dGIPLCgm53DxDhLfg5/HSOsZ1N73jWMvDk=",
"iv": "bG9LEBq6Ylcmr3PQsI8ERw==",
"signatures": { /* ... */ }
}

Idk if you already know via logs, but mine looks a bit different, i.e. no signatures:

{
  "type": "m.secret_storage.key.<default key id>",
  "content": {
    "iv": "[base64]",
    "mac": "[base64]",
    "algorithm": "m.secret_storage.v1.aes-hmac-sha2"
  }
}

Then, each secret (the three cross-signing keys, and the key backup key) are each encrypted using the 4S key, and stored in yet more account data such as m.cross_signing.master, like so:

{
"encrypted": {
"": {
"iv": "FhYtsLVAot1vQvPlcvoDZQ==",
"mac": "TSlNMqU2nOTCasivcmEVU98J9pfXyYc2PyiPYm8wL5Q=",
"ciphertext": "DaYPUNUozWfoKA9OywP7GF8TLqq3mvhbufB1zo7gVZR3F3ZapMkZzoHT3h8="
}
}
}

So, we can tell which 4S key a given secret was encrypted with, given the JSON.

Indeed, my m.cross_signing.* keys are encrypted with another of my m.secret_storage.key.*s, and indeed one that does have a signature as in your example above.

Normally, we expect all your secrets to be encrypted with the same 4S key,

Indeed they are.

and that key to be the key identified by m.secret_storage.default_key.

(They are not, as you already know.)

But when something gets messed up, we end up with secrets encrypted with older keys, and clients start getting confused.

"Older" seems to be assuming something, such as my default key is newer than my actually used key. Is there a way to be certain? The C2S API does not appear to provide this info. I have access to the server DB if that is of interest?

Are we certain it is not the local Element Desktop that is confused about what my recovery key is?

I am reasonably certain, yes: "request for non-default key" is a pretty clear diagnostic that your 4S has got messed up, as above; though you can inspect the account data yourself to confirm this. Feel free to reach out to me if you need a hand confirming this.

The interesting question is how/when this happened. If you have server-side logs, you may be able to find the PUT /account_data requests.

While I have server logs, they appear to not go back far enough.

I wonder why, when my cross signing account data clearly indicates a specific key being used, why clients should prefer the default key instead? (I also wonder why I would have multiple keys in the first place.)

Can I check and/or set the presumably correct recovery key (according to my password manager)?

Well, what we need to do is reset recovery/4S. "Change recovery key" on the "Encryption" tab (your third screenshot) is the right button for that. However, Element no longer allows you to choose your own passphrase, so there will be no way to make it match what you have in your password manager.

What will changing my recovery key do? I assume I will generate a new default_key and set up cross_signing to use it. That sounds like I need to consequently re-sign my recovery from all my devices, is that right? And on top, this is not a scary red option in the UI, so it seems like my "identity" will not be reset, i.e. others will not receive that notification? Will other users I have verified remain verified?

I guess setting my default key to the actual key in use (manually in devtools) is not an option?

It is strange that Element Web/Desktop is the only client out of those I use regularly that is complaining about this. I also use SchildiNext and Nheko regularly. Fractal 11.1 does not complain.

For fun, I tried logging in a new into Fluffychat 2.0 session. It does not accept my password manager's 4S recovery key, and it also believes it is only verified with itself, but after starting verification from Element Desktop I can complete Emoji verification and according to Fluffychat am now verified and online key backup is enabled without further complaints.

[richvdh]

Idk if you already know via logs, but mine looks a bit different, i.e. no signatures:

I didn't know that, but that's fine. 4S keys are no longer signed, that was a hangover from an older format. (It seems to have been removed from EW in matrix-org/matrix-js-sdk#1373).

By the way, none of this data is sensitive, particularly the key IDs: that's the whole point. It might be easier to have this conversation if you post actual key IDs.

But when something gets messed up, we end up with secrets encrypted with older keys, and clients start getting confused.

"Older" seems to be assuming something, such as my default key is newer than my actually used key. Is there a way to be certain? The C2S API does not appear to provide this info. I have access to the server DB if that is of interest?

You can tell the order that account data items were changed by looking at the stream_id column in the account_data table. The fact that some keys have signatures also points to them being older.

I wonder why, when my cross signing account data clearly indicates a specific key being used, why clients should prefer the default key instead? (I also wonder why I would have multiple keys in the first place.)

Well, the idea, at least as far as the Element clients go, is that anything other than your default key simply doesn't exist: the model is that you have your current recovery key, and that's what we go looking for.

Let's suppose you've got each of your secrets encrypted by a different key. Then you sign in on a new device, and try to verify it using a recovery key. You're going to have to enter 4 or 5 different 4S keys so that we can get all the secrets on that new device. Sounds pretty clunky. So in short: if your secrets aren't encrypted with the current "default" key, we flag that there's something wrong with your 4S.

What will changing my recovery key do? I assume I will generate a new default_key and set up cross_signing to use it.

Yes. It will generate a new default_key, and encrypt any secrets known by that device (hopefully: the three cross-signing secrets, and the megolm backup key) using the new 4S key.

That sounds like I need to consequently re-sign my recovery from all my devices, is that right?

No, recovery does not need to be signed.

And on top, this is not a scary red option in the UI, so it seems like my "identity" will not be reset, i.e. others will not receive that notification? Will other users I have verified remain verified?

Correct: "Change recovery key" does not change your cross-signing identity, so nobody else will see any change, and other users that you have verified will continue to be so.

I guess setting my default key to the actual key in use (manually in devtools) is not an option?

It is, actually. If you're sure that you should be using a specific 4S key, and you can see all four secrets are encrypted by that key, then changing m.secret_storage.default_key should be fine. It's certainly worth a go.

It is strange that Element Web/Desktop is the only client out of those I use regularly that is complaining about this. I also use SchildiNext and Nheko regularly. Fractal 11.1 does not complain.

For fun, I tried logging in a new into Fluffychat 2.0 session. It does not accept my password manager's 4S recovery key, and it also believes it is only verified with itself, but after starting verification from Element Desktop I can complete Emoji verification and according to Fluffychat am now verified and online key backup is enabled without further complaints.

Right. The fact that new sessions aren't accepting the expected recovery key is exactly the sort of failure I'd expect. EW is being proactive about detecting the problem (and yes, making a mess of it) in the hope that you can fix the problem before you lock yourself out of your account.

[HarHarLinks]

Here's what I got:

{
  "type": "m.secret_storage.default_key",
  "content": {
    "key": "mQ7Fvat5yqPlUZvDuz2m+AV7h53n70rP"
  }
}

{
  "type": "m.secret_storage.key.d4H2aCsBhpMJsaHUjSEcMgkvptMePwAu",
  "content": {
    "algorithm": "m.secret_storage.v1.aes-hmac-sha2",
    "iv": "fQs/kaO2Frg+Gg+AnvI6Wg==",
    "mac": "fZCA2qg53YkflxTpl7pbSYYKYrl7BqhfkcBcFbJTaLg=",
    "signatures": { /*...*/ }
  }
}

{
  "type": "m.secret_storage.key.mQ7Fvat5yqPlUZvDuz2m+AV7h53n70rP",
  "content": {
    "iv": "x0RsYZENbul9YWRfLDj6EQ==",
    "mac": "8s771/hrKCM8fCIIuP/Y1EelnGJBUkznUNsCDl7YTZ4=",
    "algorithm": "m.secret_storage.v1.aes-hmac-sha2"
  }
}

{
  "type": "m.secret_storage.key.qo2xwwRPtRtW+rIj4DLubtuUbi/A9Bct",
  "content": {
    "iv": "wJtjk8sBuUQRSx3lOmEiqQ==",
    "mac": "hIT6Iv0YG0kEe535YFN67jrDrUaZRcTMjbPavTeJBFA=",
    "algorithm": "m.secret_storage.v1.aes-hmac-sha2"
  }
}

as far as I can see, d4H2aCsBhpMJsaHUjSEcMgkvptMePwAu is used for all the stable 4S stuff

{
  "type": "m.cross_signing.master",
  "content": {
    "encrypted": {
      "d4H2aCsBhpMJsaHUjSEcMgkvptMePwAu": {
        "iv": "GX5H5UtLdA4a5geNgYWDPA==",
        "ciphertext": "HUGLB+vl7fVSVZ14tOrrgfY2KNOKvbA52gqdqoxOWiiicUcZ9xL+SKEx0aY=",
        "mac": "BuUpSG7kVFOXsJ6CIc3VmrErrik6Z/CNoQf6k6GhRok="
      }
    }
  }
}

{
  "type": "m.cross_signing.self_signing",
  "content": {
    "encrypted": {
      "d4H2aCsBhpMJsaHUjSEcMgkvptMePwAu": {
        "iv": "aJF99mcWfq4K6PldpHO7mw==",
        "ciphertext": "GVDXly+i2IpTDf5seg19Mx2bW+qdZP3lq1KSBCkh9fYaMmp5RovKBoG71pY=",
        "mac": "KTK0v6WYN50W9+j5GEFkeP1MeO/Ds5SxXYhUNGpa5rc="
      }
    }
  }
}

{
  "type": "m.cross_signing.user_signing",
  "content": {
    "encrypted": {
      "d4H2aCsBhpMJsaHUjSEcMgkvptMePwAu": {
        "iv": "AbulS+KvKucgb0ZKySAaQA==",
        "ciphertext": "mSpuoNnwy23rwj+jjk+tPdyfSetGAYThzrpmAy/Zua3wJ5nqLHYEp9wlbws=",
        "mac": "H1GiXryjVctqr4W21yrqH4v2WZwuQ+X34XAmCPtXNT8="
      }
    }
  }
}

{
  "type": "m.megolm_backup.v1",
  "content": {
    "encrypted": {
      "d4H2aCsBhpMJsaHUjSEcMgkvptMePwAu": {
        "iv": "XciSe3fZFid1oLE99oi4Kw==",
        "ciphertext": "U8X4XDx5PCvWu2vKuNgA1w6fMr6Q8zTUK4h5wOFDk7MFH3JY56qBKjJSibU=",
        "mac": "TAPLTA2xy7QbO0GPAjw6pNNvc5GBN+PJ3OvC5jF7M0k="
      }
    }
  }
}

The odd one probably causing our drama here is my current default mQ7Fvat5yqPlUZvDuz2m+AV7h53n70rP, which is used for

{
  "type": "org.matrix.msc3814",
  "content": {
    "encrypted": {
      "mQ7Fvat5yqPlUZvDuz2m+AV7h53n70rP": {
        "iv": "7Lk0xPN7TA9PZ/mzYc1rKg==",
        "ciphertext": "m9TpXvkFy7sYiQ5VYdPZJwJwF2560Z7HReyHtsrbaVpb4MYz7ZpBqHH97edaFBWo8eBrgMgedbdCMmrr8wZXg/HMcCBwIm3v+fxNTqarJiZZluD3FLucVd6MxHtlij+j12MP2dXv4k6F5uSS+sdY1ycbX4uzbvRHLdj3zOEqiXmnRMaU/OWWrlNDky+9LekbwPuF7sMoe2llNB+qpzewC2PPrqF6/f3Ox3mI/A==",
        "mac": "1z1Ker9V/jJxxmqtoyfrUU0ix7rUquFqdeM4PfBykqc="
      }
    }
  }
}

Dehydrated devices is not something I have consciously played with recently, certainly not while this issue arose.

I have now set the default key to d4H2aCsBhpMJsaHUjSEcMgkvptMePwAu manually i the understanding that in the worst case I can still "change recovery key". The immediate effect was that the warnings have disappeared from E Desktop.

[richvdh]

well, glad you got this fixed. I don't think there's anything more we can do now.

[HarHarLinks]

Thank you for this conversation. Are you sure you don't want to track the issue that Element will currently suggest a course of action (the red reset identity action) that is more disruptive than necessary (the not-red change recovery key action)?

[richvdh]

I'm 95% sure that #30230 means you won't hit that codepath.