Oddbean

Nostr needs key rotation like Bluesky, where you can rotate your compromised client key using your compromised master key to a new key, all by just clicking buttons that will instruct a compromised cloud server to perform signatures that no one will ever see and that no other user will ever check. Without that it will remain an absolute joke.

Nah, key rotation without a centralized trusted third party doesnt scale anyway, doesnt change much the thungs IMO. Still we need this to make our nerdy bitcoiners CEOs sign their shitposting from the iphone keeping the master key airgapped.

I hate iphones cause they are the most walled-garden mobile experiences, but they are better then other solutions in terms of privacy and security (the only better alternative is grapheneos). I'm ok with shitposting.

This at least starts to adress the problem. One immutable nsec is a world of trouble waiting for us. #nostr #sec nostr:nevent1qqs8z2rlr2epvsceh2n0c3fjhw2afwfq368uwq3hwpgvavudum6n4lgpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsygpm7rrrljungc6q0tuh5hj7ue863q73qlheu4vywtzwhx42a7j9n5psgqqqqqqss0mz6z

Post-hoc rationalization by those too dopey to deal with basic cryptographic primitives. nostr:nevent1qqs8z2rlr2epvsceh2n0c3fjhw2afwfq368uwq3hwpgvavudum6n4lgpzamhxue69uhhyetvv9ujumn0wd68ytnzv9hxgtczyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqqqqqg40s54g

I wasn't previously familiar with the BlueSky model, but this does raise an interesting solution. I've always wondered how compromised my current nsec is, considering how many clients I directly plugged it into during my early months here. Whether we follow this route or another in the future, something must be developed. nostr:nevent1qqs8z2rlr2epvsceh2n0c3fjhw2afwfq368uwq3hwpgvavudum6n4lgppemhxue69uhkummn9ekx7mp0qgsrhuxx8l9ex335q7he0f09aej04zpazpl0ne2cgukyawd24mayt8grqsqqqqqpe4dhdu

A new key everyday keeps the hackers away! Maybe the clients can add the option to clone a whole "account" into a new key at a push of a button. 🤔 Then relays probably have to figure out some way to blacklist all of the old keys so it doesn't add a lot of mess. 🙃

Lol. I think a second more secure canary npub displayed on your primary profile (for which you haven’t put the nsec into any clients) + NIP05 where you control the domain is plenty (… I should set up my canary npub)

Implementing key rotation like Bluesky on Nostr would undermine its decentralized integrity by introducing reliance on potentially compromised centralized servers, defeating the core principle of trustless security. 🫡

Derive a key/seed from your favorite hardware wallet (BIP85), then derive a series of NOSTR key pairs from that. Implement an xpub-like intermediary and selected clients could all scan for superseding keys (and validate revocation messages) automatically.

web of trust solution would be interesting in combination of a master key rotation. Say, I have fiatjaf as one of my homies.. if I ever did a key rotation, I could presign early the method of which a valid key rotation could happen by requiring some signature threshold of trustees and other keys I may own to make this go from an absolute joke, into a relative joke. Bonus points for using a family relative. The trustees wouldn't have access to initiate a key rotation, only verify the legitimacy of it. If the account in question and the threshold get compromised then it becomes a run away joke.. if account gets compromised you can still use compromised keys to successfully speak off band with trustees to rotate the key in public. I'll take NIP 69420 unless this idea already exist.

the idea I pitched is using a threshold of signatures from whitelist group (including potentially some of your own backup keys), and then the new key is flexible and defined when needed. this idea from @PABLOF7z and ( you and @NVK are authors?) this idea of y'all's doesn't require a web of trust or multsig threshold idea, you just lock in ahead of time a new key pair using ots timestamps as a source of truth to migrate away from a compromised account and used in case of migration attackers with earliest timestamp winning. I think instead of relying on timestamps, it would be interesting to use real connections + backups as part of the recovery protocol where you have said "these threshold of keys can vouch for me" and then there is no time delay for the migration itself. it seems nip47 has a migration delay in case an attacker gets access to your account, you'd still need to wait or the time where people think your account is really you. instead you can have better uX by punting the time delay of the change and using ots on the whitelist of the new threshold script. then if an attacker wants to change your script you can just migrate instantly to your new keypair of your choice and you don't need to lock in ahead of time. let me know your thoughts. maybe I'll draft a nip or something if you think it's a good idea.

You’d still need to OTS it though since an attacker could do exactly the same with establishing the threshold. I don’t think you can get around requiring ordering if the source of truth is the key in question. That said, we have a pretty secure source of time ordering and OTSing is quite simple, cheap, and you only need to verify it under a very rare circumstance 🤷‍♂️

I'm not sure if you understand what I'm saying, it's just moving the ots proof and creating an additional layer of abstraction so that uX would be better imo. right now I believe your proposal means if someone gets compromised they have a minimum of x amount of time before you could migrate. The suggestion I'm saying is to bake that in ahead of time and make migration fast if compromised. also in the case your new key were to get compromised before migraine, this would help with that, since you aren't pegged to a specific new keypair

Assign your identity to key matching the first UTXO of a transaction. Rotating key will become as simple as moving said UTXO into a new transaction. All past and future keys easy to look at in the Bitcoin Blockchain!