Element iOS ignores m.secret_storage.default_key?

[dbkr]

I have a client that has somehow ended up with several SSSS keys, most of which are empty (fine) and another two of which one has a passphrase and one doesn't. The default key is set to the one with the passphrase but iOS is allegedly not offering passphrase auth, suggesting it's picking up the other key rather than the default.

[langleyd]

From my tests element iOS does use m.secret_storage.default_key to select the appropriate key and seems to be selecting correctly in the case where there are multiple SSSS keys.

Looking at the code however, a corruption of the locally stored client account data could give rise to the creation of multiple keys and potentially the issue of no passphrase being offered.

With our current implementation If m.secret_storage.default_key is missing from the client account data locally, the recovery key returned is nil. In our checks for wether SSSS needs to be setup we would then determine the user needs to setup, and this could cause multiple keys.

Similarly if m.secret_storage.default_key is missed we might not offer the passphrase entry in the UI as we don't have a way of selecting a key from those available.

A workaround for the user would be to clear the cache if that option is available in the UI or else logout(clearing data) and back in.

Without knowing the source of the corruption or reproducible steps, we could try to improve the user experience by making the client more gracefully recover from the corrupt state.

One potential approach to make this more robust could be to validate both the state of crypto and account data on launch before we proceed to setup or key/passphrase entry. If the check fails we could give the user a way to recover(hard logout? reset cache button? just auto reset cache?).