To Becomes Bitcoin’s Go-To Platform, Nostr Will Have To Solve Its Key Management Issues

As Bitcoiners turn to Nostr as a censorship-resistant communication platform, user key management problems will arise.

This is an opinion editorial by Shinobi, a self-taught educator in the Bitcoin space and tech-oriented Bitcoin podcast host.

I suggest, before reading this, that you read the prior article I wrote explaining what Nostr is and how it works at a high level. You should then have a good idea of the core design of the system at that point, so now let’s take a look at likely problems that are going to occur as it grows in adoption. With the platform becoming a popular one for the Bitcoin community, these problems are ones to be aware of.

As I discussed in the prior article, user public/private key pairs are integral to how Nostr works as a protocol. There are no usernames, or any type of identifiers that a relay server is in control of, to associate to individual users. It is simply those users’ keys that are completely under their control.

This functions as a tight binding between the actual user and how they are identified by others that prevents any relay server from unbinding those two things, i.e., giving someone’s identifier to another user. This solves one of the biggest fundamental problems of platforms used for communication between people: the lack of control over users’ own identities. But it also introduces all of the problems of key management that someone possessing a private key runs into. Keys can be lost and keys can be compromised and if such an event were to occur, users have no one to go to for assistance, just like with Bitcoin. There is no customer support to recover anything. You lose it, that’s it.

This is going to inevitably necessitate a scheme for users to rotate from one keypair to another in a way that is verifiable and discoverable for other users that they interact with through the protocol. The entire protocol is based around proving that an event came from a specific user (identity key), so all of those guarantees go out the window once someone’s keys are compromised.

How do you handle that? Just go check their Twitter account? Well, then that’s not a very decentralized system, ultimately, if you require using a centralized platform where they are not in control of their identity to verify their Nostr identity.

Have other users attest to the legitimacy of a new key? That doesn’t address situations such as mass key compromises, or not knowing anyone close to them well enough to trust their attestation.

Nostr needs an actual cryptographic scheme tying the rotation of one key to another. There is a proposal from developer fiatjaf for a basic scheme that could potentially solve this issue. The basic idea would be to take a long set of addresses derived from a single master seed, and create a set of “tweaked” keys similar to how Taproot trees are committed to a Bitcoin key. Taproot takes the Merkle tree root of the Taproot tree and “adds” it to the public key to create a new public key. This can be replicated by adding that Merkle tree root to the private key in order to attain the matching private key for the new public key. Fiatjaf’s idea is to chain commitments going backwards from the end to the beginning so that each tweaked key would actually contain a proof that the next tweaked key was used to create it.

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.