Currently NSEC is acting as a one key to rule them all concept. People are plugging their one key into all kind of apps, some secure, many not. If any of those apps are compromised, your entire account and every thing you logged into is compromised.
This is akin to using one password on all your accounts. It's bad OPSEC.
What I mean is we need a way to create multiple keys based on that ONE key pair, similar to creating a unique password for every account. This way, if one Nostr based app is comoromised only that "baby" key is compromised and not the "master" key that it came from. An option to "freeze" these keys or delete would be even better.
Master / Child key concept would be a game changer
Yes, it would. It was suggested before and some high level devs shot it down. I sincerely hope they reconsider.
WHY on earth.. That a sad thing..
Like wallets derived from master key?
Yup like a master/child keys system
Just allow clients to accept hash of the nsec
I'd also love to see sub keys that can somehow be neutered or destroyed. I imagine signing an event using something like a 2/3 multisig or whatever that essentially destroys the other keys for signing and replaces it with one only the holder of the master key(s) can see. A password reset like behavior. Of course, someone who gets the master key(s) would still become king. No way to fix that without offline protections like we have for Bitcoin.
100% this. Its the same reason I don't play with nostr apps, clients etc.. I'd love to have my Nostr nsec on, say, a cold card. Creating sub keys now and again, and being able to trash them and create new in the case ifva hack etc..
Oh yeah totally agree! One key to rule them all is a huge problem.
Akin to address reuse in BTC in 2010, we worked hard to solve that the manual direct way long before BIP32 made the issue trivially easy to avoid.
There's more value if folks can get intuitively comfortable with handling multiple keys, not necessarily the hard way but most likely that'll be most effective, before tools make it seem like magic.
nostr:nevent1qqspcjd9tnkk57r3dfut46htcjscc88udns7j0guvfu6jncm86hnl3cpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsygqhw9adf5sw9fp9eks2yx2kyjs2ffeufa5htuttzkflepl6gmedtqpsgqqqqqqs638v3r
I saw this. Looks cool. I am proposing something more robust where child keys can not only be derived from the master, but can be locked to an app or client, turned on, off, paused, or deleted.
I'm sure someone has thought of this before... But, you can just generate new key pairs for different things. Why use just one key pair?
I have separate keys for my home, car, work tool boxes, etc.
nostr:nevent1qqs97qk4s0jyt67cfylhc99n7p5vk5cmtlthcyk08ednv6xp7jfy6jspr3mhxue69uhkummnw3ezucnfw33k76twv4ezuum0vd5kzmqzyp8t3qcs666wm9wx6e4rjkea8n64nwzl4my0w6ga4l2qt2fwq4wk6qcyqqqqqqgqegnc9
I mean, sure, but why not just use multiple keys? You don't need anything more complicated.
That defeats the purpose of interconnectivity which is one of Nostr's big selling points. Until then I use Amber for everything I can, but their security hasn't been 3rd party audited, and that's understandable since an audit is ~$15-20k, but it's still important to note as Nostr grows.
I guess I'm not understanding how it's difficult to manage a few sets of keys. If you have the keys, how is it different than a more complicated set of child/parent keys.
This has always been my big beef with #Nostr.
Wasn't much of an issue when Nostr was just social media. But now it's growing into much more. So, now it's a big problem
Nip46 remote signer is close to this solution, although a device with the master key needs to be active to complete the signing. I think nip46 has a better trade-off balance because all clients don't need to support the solution to associate those events to your account.
Both your idea and nip46 have a common flooe: the master key must remain a secret.
https://github.com/vnuge/nvault
Intestesting project
Thank you! Unfortunately it's currently blocked by my noscrypt library, but it will get there eventually! I daily drive the dev version at the moment
O cool, its your work! I've been considering looking into the available self hosted server based remote signing options currently available.
That was the plan exactly! I like self hosting and I don't like moving my nsec around, like at all. As you can see nip46 is on the roadmap. I just want the nip to evolve a bit more from where it's at. The first iteration will likely only be WS direct server for privacy reasons!
Nice. How would you like nip46 to evolve?
I understand why relayed signer messages are useful for apps like amber and so on, but I believe it's a huge privacy (and security too) concern. I know we use initialization vectors in nip04 but I'm still not comfortable with the idea of privileged ciphertext data (with known formats) being hoovered by other sniffers. Basically I only want direct-to-signer connections, and at a minimum using nip44.
I shared my concerns on the nip repo a little while ago and I've settled until I can think of something better
https://github.com/nostr-protocol/nips/issues/1207
With certificates/delegates/master-child keys you don't have that problem. Master key can stay in cold storage and you can create 1 certificate/delegate per app or multiple.
If you are going to make a breaking change to the nostr protocol like this you might as well focus on key rotation because normal people don't use cold storage and even cold storage can get hacked.
Certificates/delegates imply key rotation, because you rotate the certificate/delegate. For reasons of security and repudiation. Only the master is permanent.
As to what "people do" they'll have to do what we tell them is the right thing to do.
Identity trees with optional public links would solve this.
You have a master identity/key which can generate child keys, you use a different child per site/service which you can show only the child identity, or you allow it to follow the tree up to a parent identity.
You only share the private key for the child with the site/service, so if it is leaked the damage is contained. The parent key can also sign messages for the child key, so you could still go in an override anything the child does etc.
The solution is for all clients to accept Amber or other signers. Too bad Apple only has one.
nostr:nevent1qqsw0t08tnr6vcsvcx6ps52ejr0gpdhc868t5zhjty3wjn0794vfwxgpr4mhxue69uhkummnw3ezucnfw33k76twv4ezuum0vd5kzmp0qgsyawyrzrttfmv4cmtx5w2m85702kdct7hv3amfrkhagpdf9cz46mgrqsqqqqqp0h57ep
Oddbean new post about login | logout