Troubleshoot Nostr Key Management Issues – Bitcoin Magazine

[ad_1]

This is an opinion piece 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 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 basic design of the system at this point, so let’s now look at the issues that may arise as it is adopted. With the platform becoming popular for the Bitcoin community, these issues need to be considered.

As I explained in the previous article, public/private user key pairs are integral to the operation of Nostr as a protocol. There are no usernames, or any type of ID controlled by a relay server, to associate with individual users. It is simply the keys of these users which are entirely under their control.

It works as a tight link between the real user and how they are identified by others, which prevents any relay server from separating those two things, i.e. giving out someone’s id to another user. This solves one of the biggest fundamental problems of platforms used for communication between people: the lack of control over the identity of users. But it also introduces all the key management issues that someone with 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 turn to for help, just like with Bitcoin. There is no customer support to recover anything. You lose it, that’s all.

This is inevitably going to require a scheme that allows users to move 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 proof that an event originated from a specific user (identity key), so all of those guarantees are gone once someone’s keys are compromised.

How are you going to handle this? Just check out their Twitter account? Well, it’s not a very decentralized system, at the end of the day, if you need to use a centralized platform where they don’t check their identity to verify their Nostr identity.

Are other users attesting to the legitimacy of a new key? This does not resolve situations such as mass key compromises or not knowing someone close enough to trust their attestation.

Nostr needs an actual cryptographic scheme linking rotation from one key to another. There is a proposal from developer fiatjaf for a base schema 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 “adjusted” 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 this Merkle tree root to the private key to get the corresponding private key for the new public key. Fiatjaf’s idea is to chain commits working backwards from the end to the beginning so that each modified key actually contains proof that the next modified key was used to create it.

So imagine starting with the Z key, the last in the chain. You would modify that with something, then go back and create a modified version of the Y key using the modified Z key (Z’ + Y = Y’). From there you would take Y’ and then use that to modify X (Y’ + X = X’). You would do this up to key A, to get A’, and from there start using that key. When compromised, the user can broadcast an event containing the unmodified key A and the modified key B’. This would contain all the data necessary to show that B’ was used to generate A’, and users could immediately stop following A’ and follow B’ instead. They would definitely know that B’ is that user’s next key and they should follow it instead.

This proposal still has some problems though. First, you have to generate all the keys you would use in advance and there is no way to pivot to a whole new set of keys. This could be solved by committing to a master key in this scheme that could legalize such rotations, or simply by generating a very large set of keys from the start. Either way would be a valid way to go, but would ultimately require keeping a root key or keying material safe and exposing only the individual hotkeys to Nostr clients.

This scheme, however, does nothing to protect users or provide an identity recovery mechanism in the event that root key material is lost or is itself compromised. Now, that’s not to say there are no benefits to the fiatjaf scheme, there absolutely are, but it’s important to stress that no single solution solves all problems.

To pontificate a bit on the potential solutions here, imagine instead of a chain of modified keys as he proposes, that a key is modified with a master cold key which should also be used to sign the turning event of a key to another. You have key A’, which is derived by adding A and M (the primary key), and the spin 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 potentially add redundancy against loss and provide a secure mechanism for key rotation. It also opens the door to using services to help recover or distribute some of these keys to trusted friends. It offers the same flexibility as multisig with Bitcoin itself.

NIP26 is also a proposal that could be very useful to deal with this problem. This specifies a protocol extension to events allowing a signature of one key to authorize another key to publish events on its behalf. The “token”, or proof of delegation signature, would then be included in all events posted by the second public key on behalf of the first. It can even be time-limited so that delegation tokens automatically expire and need to be renewed.

Ultimately, however it is solved, this problem must be solved for Nostr in the long run. A protocol based entirely on public/private key pairs used as identities cannot gain traction and adoption if the integrity of those identities cannot be protected and maintained for users. It will ultimately come down to constantly having to 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 way to sow confusion. and practice censorship.

Key management and security issues are big problems with a very large design space full of compromises and weak points, but these are issues that will need to be addressed in the context of Nostr for it to work. In my next post, I’ll summarize some of the issues I see arising with respect to relay server architecture and scaling issues that Nostr developers will have to deal with given the base data structures on which Nostr is built.

For anyone reading this and wondering why I didn’t mention Decentralized IDs (DIDs): Yes, it’s a potential solution to these issues that I think is pretty comprehensive. However, the Nostr developers seem very hesitant to integrate DIDs into the protocol or clients as this would create external dependencies outside of the Nostr protocol. If you are unfamiliar with the technical workings of DIDs and are interested, this Level 39 article is a very well-written summary of how they work.

This is a guest post from Shinobi. The opinions expressed are entirely their own and do not necessarily reflect those of BTC Inc or Bitcoin Magazine.

[ad_2]