So, imagine starting with key Z, the last one in the chain. You would tweak this with something, and then go backwards and create a tweaked version of key Y using the tweaked Z key (Z’ + Y = Y’). From here you would take Y’ and then use it to tweak X (Y’ + X = X’). You would do this all the way back to key A, to get A’, and from there, begin using that key. When it is compromised, the user can broadcast an event containing the untweaked key A and tweaked key B’. This would contain all of the data needed to show B’ was used to generate A’, and users could immediately stop following A’ and follow B’ instead. They would know definitively that B’ is that user’s next key and to follow that instead.
This proposal still has some problems though. First, you have to generate all of the keys you would ever use ahead of time and it has no way to rotate to a whole new set of keys. This could be dealt with by committing to a master key in this scheme that could notarize such rotations, or simply generating a very large set of keys from the beginning. Either path would be a valid course to take, but ultimately would require keeping a root key or key material safe and only exposing individual hotkeys to Nostr clients.
This scheme, however, does nothing to protect users or offer a mechanism for identity recovery in the event that the root key material is lost or is itself compromised. Now, this isn’t to say that there is no benefit to fiatjaf’s scheme, there absolutely is, but it’s important to make the point that no solution solves every problem.
To pontificate a bit on potential solutions here, imagine instead of a chain of tweaked keys like he proposes, that a key is tweaked with a master cold key that must also be used to sign the event rotating from one key to another. You have key A’, which is derived by adding A and M (the master key), and the rotation event would be A, M and B’ (generated by adding B and M) with a signature from M. M could be a multisig threshold key — two of three, three of five, etc. This could potentially add redundancy against loss as well as provide a secure mechanism for key rotation. This opens the door as well to using services to aid in recovery, or spreading some of those keys around to trusted friends. It offers all of the same flexibility as multisig does with Bitcoin itself.
NIP26 is also a proposal that could be very useful in handling this problem. This specifies a protocol extension to events allowing a signature from one key to authorize another key to post events on its behalf. The “token,” or signature proof of delegation, would then be included in all events posted by the second public key on the first’s behalf. It can even be time limited so that delegation tokens automatically expire and have to be renewed.
Ultimately, however it is solved, this problem has to be solved for Nostr in the long term. A protocol based entirely on public/private key pairs being used as identities cannot gain traction and adoption if the integrity of those identities cannot be protected and maintained for users. That eventually will boil down to having to constantly use out-of-band and centralized platforms to verify new keys and coordinate people following your new identity when something is lost or compromised, and at that point, those other platforms become a means to sow confusion and engage in censorship.
Issues of key management and security are big problems with a very large design space full of trade offs and pain points, but they are problems that are going to have to be solved within the context of Nostr for it to work. In my next article, I will summarize some issues that I see cropping up in regards to relay server architecture and scaling issues that Nostr developers will have to confront given the basic data structures that Nostr is built on.
For anyone reading and wondering why I haven’t mentioned decentralized identifiers (DIDs): Yes, that is a potential solution to these problems that, in my opinion, is quite comprehensive. However, Nostr developers seem very hesitant to integrate DIDs into the protocol or clients due to the fact that it would create external dependencies outside of the Nostr protocol. If you are not familiar with how DIDs work on a technical level and are interested, this article by Level 39 is a very well written summarization of how they work.
This is a guest post by Shinobi. Opinions expressed are entirely their own and do not necessarily reflect those of BTC Inc or Bitcoin Magazine.
