Thread

🛡️
If you had a way to preserve your nostr identity so that you could recover from someone compromising your nsec and it required writing a note in your nostr client, would you do it? Repost for visibility, want to see what people think.

Replies (83)

Good idea. I've been thinking about this also. For now, before we have a technical solution, we could post a note and keep it in our public bookmarks. Below is the Npub of my account backup #1. I have set my main account to follow my backup account. I will keep the robot avatar for my backup until I use it. Possible hashtags to find the note: #Npub #MyNpub #MyNostrBackup #LeoFernevak #MyNostrLeoFernevak #MyNostrBackupLeoFernevak #NpubLeoFernevak @Leo Fernevak
I proposed this in March. Would be neat if there was a more elegant/smooth way to do it: —— Subject: Suggestion on a method to ensure continuity of your identity if your nsec is ever compromised, without relying on 3rd party verification Problem: Unless your Nostr npub is tied to an external identity (ie you have a podcast, website, twitter handle, etc) that can be used to re-validate your identity, compromise of your nsec means there is no reliable way to confirm that another npub is actually yours. You can’t use the old keys to confirm its you using the new keys because it could be anyone using your compromised key to pose as the new you. Solution: I think a simple way to solve this is to pre-verify that you own a particular npub (a set of backup keys) that can be used in the future to reestablish your identity. In the event your nsec in compromised at a future time, you can use the uncompromised backup nsec to point people to your new pubkey. Example sequence of events: Event 1: Publish note from npub1: “npub2 is my backup npub. I confirm I own it and will only use it to inform of my new npub3 in the future if nsec1 is compromised” Event 2 (future/eventual possibility): nsec1 is accidentally compromised, user initiates switch protocol Event 3: publish note from npub2: “npub1 is compromised, I am moving to npub3 which is___” Event 4: publish note from npub1 (compromised but followed by others) and npub3: “I am back on Nostr. You can confirm npub3 is a continuation of npub1 by referencing npub1 note ___ and npub2 note___. Please follow me at npub3 and stop following me on the compromised npub1” No one else can use npub1 to claim a fake new account because they can’t publish to npub2 and you can use npub2 to deny any imposters claims. Conclusion: Not super elegant but it works without relying on 3rd parties like twitter accounts. Obviously your nsec2 needs to be kept away from all systems that use nsec1 so it doesn’t get compromised in whatever compromised nsec1.
Yes, but I would expect that to be part of onboarding: Hey user, this is your pirvate key, store it safe, and here is you recovery key, store that somewhere else. Of course clients should offer that as a function to use at any time. Also the keys could be generated from easier to record seeds with enough entropy.
Just saying in case the DM or other bug was to get out of hand. Still not sure if I unnecessarily worried about the DM private bookmarks yada yada bug. Anyways, it would suck to lose your id (🤔 perhaps could be a blessing in some other ways cuz of.... Social Dilemma 😅). Cheers 🤙
Have thought for some time that the best way to accomplish this is with a servant/master system. Servant pubkey is the main that you use regularly. Servant identifies a master pubkey, with the note that does so including a small snippet of signed text from the master. The master would ideally be a cold-storage derivation that sees nearly no use. The master would only have one primary purpose, that being account replacement. It can send a note that identifies an account as burned, and identifies the replacement. Said note should be signable as airgapped. Clients would then swap over to the replacement and otherwise maintain continuity of messages.
Sooo not sure if this input helps but I've always wondered why we can't create revocation keys or add expirations to the nsec for this exact reason. I like the notify of new key proposal but if we already have a workflow that works for gpg keys, then why not adopt it?
I wrote a note about this type of issue yesterday. My feeling is that the key we use day to day should be a secondary key that can be changed by signing an event with a primary key (preferably a hardware one). Rationale being that the key used to log in day to day is frequently e posed to apps using it so is at a higher risk and should be quick and easy to drop. For bigger social media users the 30 days could be pretty problematic as from my understanding the compromised key would still be what most clients see as the real identity.
I think we should just take good care of the nsec and use tools like nsecbunker when possible to generate disposable little nsecs. Nostr identity won't go away by simply having the nsec compromised. We literally know each other on a good level to know someone is pretending to be someone else. Not saying it won't create confusion to start with, but I don't see it as horrible as losing a wallet seed phrase or more. Improving UX could prevent the majority of such accidents without having to implement a complex solution that most won't be able to use anyway. Unless they could of course. View quoted note →
If your nsec is compromised, isn't that gg? Would you basically recover your note history to a new nsec while some other POS is masquerading as yourself? I'm very interested to see what comes of this because I'd hate to "start over" god forbid.