This is an opinion editorial from Shinobi, a self-taught educator in the Bitcoin space and tech-oriented Bitcoin podcast host.
I suggest, before you read this, that you read the previous 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 by then, so now let’s take a look at potential issues that will occur as it grows in adoption. with platform becoming a popular one for the Bitcoin communityThese issues are the ones to be aware of.
As I mentioned in the previous article, the user’s public/private key pairs are an integral part of how Nostr as a protocol works. There are no usernames, or any kind of identifier that a relay server controls, to associate with individual users. It is simply the passwords of those users that are completely under your control.
This works as a tight link between the actual user and the way others identify them which prevents any relay server from untying those two things, i.e. giving someone’s identifier to another user. This solves one of the biggest fundamental problems of the platforms used for communication between people: the lack of control over the users’ own identities. But it also presents all the key management problems that someone who owns a private key runs into. Keys can be lost and keys can be compromised, and if such an event were to occur, users have nowhere to turn for help, just like with Bitcoin. There is no customer support to recover anything. You lose it, that’s all.
This will inevitably require a scheme for users to rotate from one key pair to another in a way that is verifiable and discoverable to other users they interact with through the protocol. The entire protocol is based on proving that an event came from a specific user (identity key), so all those guarantees are gone once someone’s keys are compromised.
How do you handle that? Just check his Twitter account? Well, so that’s not a very decentralized system, ultimately, if you need to use a centralized platform where they don’t have control of your identity to verify your Nostr identity.
Have other users attested to the legitimacy of a new key? That doesn’t address situations like massive key compromises, or not knowing anyone close to them well enough to trust their attestation.
Nostr needs a real cryptographic scheme that binds the rotation of one key to another. There’s a fiatjaf developer proposal for a basic schematic that could potentially solve this problem. The basic idea would be to take a long set of addresses derived from a single master seed and create a set of “modified” keys similar to how Taproot trees commit 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 to get the matching private key for the new public key. Fiatjaf’s idea is to chain commits back from end to beginning so that each modified key contains proof that the next modified key was used to create it.
So imagine starting with the Z key, the last in the chain. I would modify this with something, and then go back and create a modified version of the Y key using the modified Z key (Z’ + Y = Y’). From here, you would take Y’ and then use it to modify X (Y’ + X = X’). It would do all this up to the A key, to get A’, and from there, it would start using that key. When compromised, the user can broadcast an event containing the unchanged key A and the changed key B. This would contain all the data necessary to show that B’ was used to spawn A’, and users could immediately unfollow A’ and follow B’ instead. They would definitely know that B’ is that user’s next key and would follow that instead.
However, this proposal still has some problems. First, you have to generate all the keys you’d ever use ahead of time, and you have no way to rotate to a whole new set of keys. This could be fixed by committing to a master key in this scheme that could certify such rotations, or by simply generating a very large set of keys from scratch. Either path would be a valid course, but would ultimately require keeping a root key or key material secure and only exposing individual hotkeys to Nostr clients.
This scheme, however, does nothing to protect users or provide a mechanism for identity recovery in case the root key material is lost or compromised. Now, this is not to say that there are no benefits to the fiatjaf scheme, there absolutely are, but it is important to note that no one solution solves all problems.
To pontificate a bit about the possible solutions here, imagine that instead of a modified key chain as he proposes, a key is modified with a master cold key that should also be used to sign the event by rotating from one key to another. It has the key A’, which is obtained 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 of M. M could be a multisig threshold key: two out of three, three out of five, etc. This could add redundancy against loss and provide a secure mechanism for key rotation. This also opens the door to using services to help with recovery, or sharing some of those keys with trusted friends. It offers the same flexibility as multisig with Bitcoin.
PIN26 It is also a proposal that could be very useful in handling this problem. This specifies a protocol extension for events that allows a signature of one key to authorize another key to publish events on its behalf. The “token”, or proof of delegation signature, would be included in all events published by the second public key on behalf of the first. You can even have a time limit for delegation tokens to automatically expire and need to be renewed.
Ultimately, however it is resolved, this problem has to be resolved for Nostr in the long term. A protocol based entirely on public/private key pairs that are used as identities cannot gain traction or adoption if the integrity of those identities cannot be protected and maintained for users. Eventually, that will boil down to constantly having to use centralized, out-of-band 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 participate in censorship.
Key management and security issues are big issues with a very large design space full of trade-offs and pain points, but they are issues that will have to be resolved within the context of Nostr to make it work. In my next article, I’ll outline some issues I see arising regarding relay server architecture and scaling issues Nostr developers will have to deal with given the basic data structures Nostr is based on.
For anyone reading and wondering why I haven’t mentioned decentralized identifiers (DIDs): yes, that’s one possible solution to these problems that is pretty comprehensive in my opinion. However, Nostr developers seem very reluctant to integrate DID into the protocol or clients due to the fact that it would create external dependencies outside of the Nostr protocol. If you are unfamiliar with how DIDs work on a technical level and are interested, this Level 39 article is a very well written summary of how they work.
This is a Shinobi guest post. Opinions expressed are entirely their own and do not necessarily reflect those of BTC Inc or Bitcoin Magazine.
