what's needed for proper key rotation? who is working on this?
Login to reply
Replies (18)
👀
Don’t worry key management is *the* only real problem in cryptography
NIP-46 is the best option for delegation, in my opinion, because you can have a lot of control over exactly what event kinds the NIP-46 provider may automatically sign, automatically reject, or ask every time for, whereas an actual private key that has been authorized to sign on behalf of a mastwr key would need a note somewhere on the relays indicating not only that the delegated key can sign on behalf of the master key, but what sorts of event kinds it is permitted to sign for.
That's not to mention the immense amount of complexity key delegation would add to Nostr.
I provided some links to dev discussion of the issue and why it atill hasn't become a thing on Nostr here:
View quoted note →
View quoted note →
"Cryptography turns every problem into a key management problem"
LOL. Yes!
If I had to do it myself from my ignorant savant point of view: I'd want a 3-2-1 sort of thing on my profile. (3 backups, 2 mediums and 1 remote location.)
To validate my key today in a sovereign way, I have nip-05. Gimme 2 more ways, one in a different medium and one in a remote location.
Which.. I could have: a secondary nip-05 different locations, check. The one outside the internet is harder to parse automagically. Unless of course I could gather my homies around a 40, a blunt and have them unfollow my old key and follow my new one. Different medium, check.
Likely all of the above has been tested and disproved, but who knows?
IMO, web-of-trust key signing attestations and revocation as similar to PGP.
i proposed a scheme for separating identity from authorization in a manner similar to web sessions. this lets you better protect your actual identity key, avoids guessing whether a rotation was valid, can be verified without external requests, and in the event of loss is basically the same as bulk nip-09 deletions
GitHub
NIP-102: Subkey Attestation by ynniv · Pull Request #1450 · nostr-protocol/nips
This NIP defines a way to separate identity from authentication using hierarchical deterministic (HD) keys. This allows people to use one key pair ...
I agree the inability to do key rotation in Nostr is a major concern. It’s one of several things that make me sometimes think of making a derivative protocol that fixes some of the problems that have cropped up with Nostr. So far I’ve resisted the temptation.
View quoted note →
this, yes
cc @david i think graperank can help here
Had a discussion on this topic recently
View quoted note →
Thats quite interesting and might play nicely with my prototype of ZK and bip-85 hierarchical nostr keys
The zk can assert ownership/relationship of another key, doesn't help if the root is compromised though. So ideally you would never use the root for anything other than generating other keys. (Which can also do the same)
GitHub
GitHub - wujifoo/nostr-bip-85-prototype
Contribute to wujifoo/nostr-bip-85-prototype development by creating an account on GitHub.
We were musing on something similar but it needs widespread use of NIP-03 to be effective and lots of client coordination:
View article →
A single key per person and for life is too core to how the protocol works. Everything is built on top of that. It's the core of the core of the core. Rotate-able subkeys are a non-starter.
All you've got is a bunker-esque solution or a protocol fork.
Yep! This is exactly how I imagined it would work.
"Oh Vinney's mom says this is Vinney's new npub? welp, that settles it [everything updates accordingly]"
...Also pretty nuts that graperank-flavored WoT can solve nostr's "big scary nsec problem".
Although I'm kind of an extremist here - I don't think there is much subjective WoT can't solve. Trust is humanity's superpower; welding it onto global-scale networks and lightspeed information transfer is..... unimaginable.
Frostr