2024-06-07
Account recovery is still a hard problem in public key management
Soatok recently published their work on a part of end to end encryption for the Fediverse, Towards Federated Key Transparency. To summarize the article, it is about the need for a Fediverse public key directory and a proposal for how to build one (this is a necessary ingredient for trustworthy end to end encryption). Soatok is a cryptographer and security expert and I'm not, so I have nothing to say about the specifics of the proposed protocol and so on. But as a system administrator, one thing did catch my eye right away, and that is that Soatok's system has no method of what I will call "account recovery".
How this manifests in the protocol is that registering in the key directory is a one-way action for a given Fediverse identity. Once you (as a specific Fediverse identity) register your first key in the key directory, you cannot reset from this state and start over again. If you somehow lose all of your registered private keys, there is no natural or easy way out to register a new one under your current Fediverse identity and your only option is to start a new Fediverse identity, which can register from scratch.
(While the proposal allows you to revoke keys if you have more than one active one, it specifically doesn't allow you to revoke your last key. This has the additional effect that you can't advertise that all of your previous keys are no longer trusted and you can't be reached over whatever they enable at all. The closest you can come is to leave a single public key registered that you've destroyed the private key for, rendering it useless in practice; however, this still leaves people able to retrieve your 'current key' and then use it in things that will never work.)
Of course, there are good security reasons to not allow this sort of re-registration and account recovery, which is undoubtedly why Soatok's proposal doesn't attempt to include them. Telling the difference between account recovery by a good person and account recovery by an attacker is ultimately a very hard problem, so if you absolutely have to prevent the latter, you can't allow account recovery at all. Even partially and reasonably solving account recovery generally requires human involvement, and that is hard and doesn't scale well (and it's hard to write into protocol specifications).
However, I think it's meaningful to note the tradeoffs being made. One of the lenses to look at security related things is through the triad of confidentiality, availability, and integrity. As with any system that doesn't have account recovery, Soatok's proposal is prioritizing confidentiality over availability. Sometimes this is the right tradeoff, and sometimes it isn't.
To me, all of this demonstrates that account recovery remains a hard and unsolved problem in this area (and in a variety of others). I pessimistically suspect that there will never be good solutions to it, but at the same time I hope that clever people will prove me wrong. Good, secure account recovery would enable a lot of good things.