nip-41 Identity management

[gzuuus]

This proposal is a best-effort research to improve existing key management proposals.

To do this, I've studied the previous proposals on the subject (prsNip41, prNip-37, prNip-109) and how other protocols such as gpg achieve their robustness.

All the ideas, processes and concepts in this research can be seen as an extension of prNip-41 by Pablo, as they are heavily based on it, and are designed with simplicity and backward compatibility in mind.

Consider this a work in progress and a starting point for designing a better system for managing identities in nostr.

Viewable here: Nip-41

[gzuuus]

Motivation

• Nostr is an evolving network that aims to provide strong digital identities that allow content creators to retain the value of their contributions, even in the event of key leakage, loss or theft.
• The current security model of 1 person, 1 key can be weak.
• New field for nostr software: Key managment tools
• Ultimately, these ideas can lead to a richer and more valuable network as users have a safer and more robust way to maintain the value, reputation and web of trust they have created.

Key differences with prNip-41

• Concept of secured identity and simple identity
• Concept of Master keypair and subkeys
• Concept of revocation certificate and its proofs

[staab]

I like this, especially the introduction of hierarchical keys and user passwords for a better happy path, although it's a little outside my wheelhouse to actually evaluate. I do think it's unlikely that the majority of clients will implement this, maybe a special purpose crawler could be created which would watch for these events specifically, then DM users to notify them of a key rotation.

[gzuuus]

I like this, especially the introduction of hierarchical keys and user passwords for a better happy path, although it's a little outside my wheelhouse to actually evaluate. I do think it's unlikely that the majority of clients will implement this, maybe a special purpose crawler could be created which would watch for these events specifically, then DM users to notify them of a key rotation.

Yes, hierarchical keys introduce a well-tested way to have a robust identity system, and from a UX perspective it also makes sense because users only need to keep one pair of keys, the master key pair.
I agree that not all clients will implement this 100%, so I have tried to design this to be backwards compatible and not break anything, so the most unhappy path would be to issue a kind1 from your active subkey to say publicly that you are rotating identities, and then people can go to a specialised client like the one you mention to verify, or as you say, communicate via dm. This is something I thought about a lot when I was conceiving this idea, making a specialised client to provide this service. I'm also working on a desktop client to securely manage your keys, something like a Sparrow Wallet for nostr identities.
What I really want is for all of us to validate the design and make it suitable for the use case.

[gzuuus]

Im personally interested in the subkey part, though I recognize there are a few different ways to do this. Thanks for getting the ball rolling.

I'll point out another motivation for subkeys is here:

Cryptography expert Maxim Orlovsky states:

It is not about the nonce collisions but about a bias in the nonce randomness 1-2 bits of bias (in all 256 bits, i.e. < 1% of bias) is enough to leak the private key over many thousands of sigs (in nostr opinion leaders may have millions of them).

1-2 bit bias - is much lower than JavaScript-based pseudorandom generations, which means most of nostr clients are vulnerable.

Further discussed in academic paper:

Attacks on Schnorr signatures with biased nonces

This is a compelling reason to use the master key and subkey design. Otherwise, if this is a viable attack surface (I haven't done enough research to know if it is), it clearly means that all of our identities will be compromised at some point. Thanks for sharing

[Semisol]

This is a compelling reason to use the master key and subkey design. Otherwise, if this is a viable attack surface (I haven't done enough research to know if it is), it clearly means that all of our identities will be compromised at some point. Thanks for sharing

this is not a viable attack on bip340 signatures at all. bip340 mixes in the private key and message along with whatever generated randomness is used (using sha256 of concatenated values), plus nearly all JS crypto libraries don't use math.random (biased) and instead use crypto.getRandomValues (not biased, as good as /dev/random), and all of the ones nostr clients use do, so a nonce cannot be repeated on two distinct messages (message is mixed into the nonce) and it can't be predicted by anyone without the key (private key is mixed in)

don't trust, verify

[fiatjaf]

Is this like @pablof7z's NIP-41 proposal for preparing the next key to migrate beforehand and then migrating to it when you lose the previous? But instead of preparing beforehand you need a master key to coordinate?

[gzuuus]

Is this like @pablof7z's NIP-41 proposal for preparing the next key to migrate beforehand and then migrating to it when you lose the previous? But instead of preparing beforehand you need a master key to coordinate?

Yes, exactly, secure identities, being backed by a master keypair, do not need to define keys beforehand, or OTS to coordinate the rotation of a subkey. It is a source of truth, and therefore no other proofs are needed to perform these actions.

But if the user's master keypair is compromised then the proofs described in the nip are necessary to coordinate a master keypair rotation.

[fiatjaf]

Sounds confusing. Sorry, I'll try to read it again soon.

[gzuuus]

Sounds confusing. Sorry, I'll try to read it again soon.

In a nutshell, what I propose is to use a defined identity as a source of truth, this would be the master keypair and could be stored cold, thus the master identity that backs up another identity (subkey). The master identity never changes and the subkey can eventually change if it is leaked or stolen.

Thanks, would be great to have some good design on top of that.

[RandyMcMillan]

Aren't you just reinventing bip-0085? The root key is used to derive child keys?

[vitorpamplona]

I just want to offer a more straightforward way of migrating identities: #1056

[gzuuus]

Aren't you just reinventing bip-0085? The root key is used to derive child keys?

Well, you could consider that we are applying it to nostr in a way that makes sense and can be used to improve security and UX. Actually in the proposal we use BIP32 for deterministic derivation, BIP85 uses BIP32, so I understand that it can be confusing, but afaik the main difference between the derivation used in BIP85 and BIP32 is that in BIP85 we have m/44'/{app_no}'/{index} where the seed is generated taking into account the second and third levels of the derivation path, and in BIP32 it would only be the third m/44'/1237'/{account/subkey}'.

[gzuuus]

I just want to offer a more straightforward way of migrating identities: #1056

I like it, the flow is similar to what is presented here, but eliminating the proofs necessary to take a key rotation event as valid. Do you think these proofs could be added to your proposal?
It would be ideal to segregate the complexity of this into different nips to achieve modularity and composability.

[vitorpamplona]

Do you think these proofs could be added to your proposal?

I think so. The goal of the other proposal is to offer a way to move current keys to new key schemes so that we can introduce the idea of key derivation to most users today. I strongly believe that most of these identity management proposals are held back by their need to make it work with current keys. #1056 starts something everyone can implement that can get us out of this hole we put ourselves into.

[gzuuus]

Yes, I agree, the keys that old users have could be considered compromised since they were used on insecure clients at the beginning, and copied and pasted to as many current clients.
The solution that I propose here for that is in the section

Creating a secured identity

But on second thought I think it can be improved because first it would be convenient to successfully migrate to a new and fresh key(for this makes sense #1056), then create the checkpoint event and this would be the way that would give more security when creating a secured identity.