Should we do away with 4S secret storage in favour of deriving everything deterministically from the recovery key?

[dkasak]

Suggestion

I just had a mad scientist idea: why do we bother with Secret Storage (4S component, "secure storage") instead of deriving all secrets (cryptographic identity, key, etc) deterministically from the Recovery Key (the thing with many names which we enter to access Secret Storage)?

Pros

• Improved reliability because there is no server involvement necessary
• Spec complexity reduction
• Code and attack surface area reduction due to a removal of a complex moving-part feature that is tricky to implement correctly
• Using this approach, a WebAuthn PRF-enabled key (e.g. a Yubikey) could directly act as your entire crypto identity
• We still retain the ability to:
  • Directly gossip derived secrets between devices, via encrypted to-device. So you can still grant access to parts of your identity and storage, and this access can even be partial.
  • Rotate individual secrets, by e.g. mixing in an incrementing counter value during derivation
• The recovery key becomes an (entirely?) client-side concept, divorced from the spec since it's just an input to a KDF. This would allow for faster iteration and improve experimentation with new approaches.

Cons

I'm listing all cons I can think of, but I'll attempt to argument why I believe they are not showstoppers.

1. Stealing a recovery key immediately grants you the ability to derive all secrets, whereas before you had to both steal the recovery key and separately steal secrets encrypted with it from the server (requiring a password or access token).
   • But you still need the password or access token to do anything useful with those secrets: steal message keys or messages, log in a new device, expose signed devices to others, etc. So it doesn't appear to materially change anything in terms of exploitation.
2. You can no longer rotate your recovery key without also rotating your identity and message key storage.
   • But how important is this use case really? Empirically, a user's primary concern is retaining access to their messages and nothing appears to change in that regard. Consider the possible scenarios:
     • You've lost all of your devices but you still remember the recovery key: Nothing changes.
     • You have at least one fully activated device but you've lost your recovery key: Your remaining device still has access to your message keys. The only change is you'll have to re-upload them after recovery key rotation.
     • You've lost all your devices and you forgot your recovery key: You've lost access to your messages under either approach.
3. The flow of holding off on creating a recovery key (such as implemented in e.g. Element X) until a user is ready to set it up no longer works.
   • However, a client can still generate and remember the recovery key in the client, and then use the exact same flow, which is to offer the user to "set up recovery" during the client's lifetime and warn them to save it just before they sign out.
     • Yes, this means the recovery key would remain cached for a longer period in the client that created it. But this doesn't materially change the current situation from a security perspective when all clients cache all secrets protected by the recovery key anyway.
   • The user could ignore all cues and destroy the initial client without saving the recovery key. This leads to the scenario described in point 2.
   • Alternatively, the client can simply choose not to use this flow and instead ask the user to set the recovery key up front.
4. The entropy of the passphrase now plays a more significant role since identical passphrases will lead to identical secrets.
   • It's never a good idea to use a low entropy recovery key anyway.
   • We can ensure uniqueness of the secrets by mixing in deterministic unique information during key derivation, such as the MXID.
   • Client can use BIP39-style passphrases as the recovery key. These are a great middle-ground that ensures both memorability and security (high entropy).

Is this insane? Am I missing something?