Nostr subkeys \ stacker news ~nostr

1384 sats \ 18 comments \ @crrdlx 12 Jul nostr

First time hearing of subkeys on nostr (njump link below by npub1melv683fw6n2mvhl5h6dhqd8mqfv3wmxnz4qph83ua4dk4006ezsrt5c24)

Nostriches need the ability to change nsec keys and have "their account" carryover in full. If my nsec is compromised, or I think it might be, I'm out of luck. Currently, nsecs are burner phones. You use it until you feel it might be compromised, then trash it and start over.

I've used Hive (formerly Steem) since 2017 as a blog. It's possible to generate new private keys and everything account-wise carries over. Also, there are actually four keys from least to most secure:

Posting - to post stuff Memo - send dm Active - move money Owner - control everything

Users can chhose which dapp gets which permission/key, or not.

Maybe subkeys could be used similarly on nostr, at least to a degree. I'd especially like to see the ability to migrate to a new nsec if needed. Nostr Wishlist

view all related items

294 sats \ 12 replies \ @justin_shocknet 12 Jul

Subkeys suck because they put all the work on the client to treat a subkey as a root key. Given how Nostr clients generally work, its a non-starter from a performance and scalability perspective. The NIP26 spec for these (by Hive) is basically dead.

Also, planning to have your keys compromised is not a plan either. The way they're used today unsustainable.

The correct method of delegation is revocable access tokens with policy enforcement to a remote signer. This also allows for teams using legacy authentication to "share" a key without the owner surrendering unilateral control, and that is a critical feature valuable brands or Enterprises would need before creating a presence on Nostr.

Should have this out of sandbox soon: https://test-auth.shock.network/learn

100 sats \ 6 replies \ @crrdlx OP 12 Jul

Hadn't heard of NIP-26 before, interesting. Even if it wasn't dead, a weakness is that it would be an opt-in or not thing by clients...they can implement it or not (isn't that the case for all NIPS?). That's great and all, but if your nsec got compromised, you're out of luck regardless of any NIP-26 or not.

Wouldn't this same weakness exist for "revocable access tokens"? If I understand, I grant access to dapp X with this token. I might revoke it in the future, but for now, dapp X can sign events on my behalf. This is great. But...Bad Actor Jim got my nsec and thus has control of "my nostr account". I don't see how a token access system resolves this.

Changing to entirely new keys is the only way (I think). With the Hive example, if someone gets my private keys, we both can do anything...post, move funds, etc. Effectively, it becomes a race to see who changes to new keys first. Whoever switches first then has exclusive control and the other person is totally locked out and cannot do anything.

Also hadn't heard of the "Sanctum" project you link (I'm guessing you're building or working on this?). Awesome. I'll be keeping an eye out for sure.

Overall, I guess my concern is for newer nostroids and people who sometimes make dumb login decisions or have in the past (ahem, me, allegedly 😊). It's so simple for someone to create a fake "dapp" that looks nice and include a "logic with nsec" here button that does nothing but gathers private keys. People who have been around and understand keys a bit should know to login with signing extensions or bunker, but it's a learning curve to get there and not always doable in every case and every browser, os, etc.

We need a "change my nostr private keys to new keys" nostr dapp.

100 sats \ 5 replies \ @justin_shocknet 12 Jul

weakness is that it would be an opt-in

Fiatjaf makes a good point in that its effectively not opt-in, its the nostr analogue to a hard fork because all the lift is on the clients

if your nsec got compromised

There's no way to handle this gracefully in public key systems where your public key is your identity, you can abstract all you like but you're still building a new identity when its all said and done rolling keys... there are proposals for pre-defining a rollover key, but its pretty stupid imo as a compromised key could still just attest to a fake rollover key

This is a tale as old as time, whether its a yubikey ssh pgp btc or whatever... if you're keys are compromised your fallback is some out of band redundancy and repointing

Bad Actor Jim got my nsec

The point of revocable access tokens is to not let bad actors get your keys in the first place by keeping them in a secure remote signer, not pasting them into countless apps and hacky browser extensions.

If an app is misusing its access you revoke that access and that's the end of it, there's no need to roll a new key... the app only ever had a token to the signer not the key itself.

dumb login decisions

Pretty much everyone that has used nostr has made a dumb login decision because that's all that's been readily available. My nsec has been pasted into a couple apps and extensions just to play with them, and so I personally plan on starting from scratch with a Sanctum originated key once I consider Nostr usable enough for social to care

It would be a bad look to run an enterprise-class auth service and then have my key exploited later because I had pasted it into some apps before building a secure signer.

We should consider Nostr completely custodial at this stage because of how insecurely keys have been used. (Browser extensions are just as bad as pasting into a web app).

Only once secure remote signers (Sanctum and Bunker work similarly) are standard can it begin to secure valuable identities.

We need a "change my nostr private keys to new keys" nostr dapp.

Such an app won't be able to do anything more than make a post that says you're burning the current key, follow me at the new key... there's no way around the fact its going to be a new identity that requires repointing.

17 sats \ 4 replies \ @crrdlx OP 12 Jul

Appreciate the thoughtful reply.

and so I personally plan on starting from scratch with a Sanctum originated key once I consider Nostr usable enough for social to care

I've considered this as well, and might do it at some point.

Such an app won't be able to do anything more than make a post that says you're burning the current key, follow me at the new key... there's no way around the fact its going to be a new identity that requires repointing.

You know way more about this stuff and me so I yield to your expertise. The thing I don't understand is how it is done over at Hive. I changed my private keys there after the fork from Steem (the Hive private keys were the same as with Steem and Tron, yikes! talk about scary). Though I changed to new keys, I'd saved the old ones. I just tried those old ones, and as expected they no longer work. I don't know, maybe Nostr a different animal altogether.

0 sats \ 3 replies \ @justin_shocknet 12 Jul

Hive is a unique client using Nostr but not necessarily compatible with other Nostr clients, that's where the hard fork analogy comes in re: NIP26, which is how they do it

It's possible they end up doing really well with it and other apps start to use NIP26 to benefit from shared network effect, but as of now there's a lot of reasoning outlined above for other Nostr apps try other things

0 sats \ 2 replies \ @crrdlx OP 12 Jul

Wait what? I was referring to the hive.io chain. There's a Hive "unique client using Nostr" with that name?

10 sats \ 1 reply \ @justin_shocknet 12 Jul

Conflation on my end, I mean Minds... somehow transposed those names in my head

17 sats \ 0 replies \ @crrdlx OP 12 Jul

✅

reply on another page

0 sats \ 4 replies \ @jp305 12 Jul

NIP-26?

0 sats \ 3 replies \ @justin_shocknet 12 Jul

https://github.com/nostr-protocol/nips/blob/master/26.md

0 sats \ 2 replies \ @jp305 12 Jul

What makes it dead?

21 sats \ 1 reply \ @justin_shocknet 12 Jul

It's dead by default because it's Nostr, nothing of note uses it

Not looking likely to change at this point either:

https://fiatjaf.com/4c79fd7b.html

Meanwhile builders are mostly working with NIP07 remote-signing in some form

17 sats \ 0 replies \ @jp305 12 Jul

Makes sense.

234 sats \ 4 replies \ @supertestnet 12 Jul

Nostr has two specs for key delegation/invalidation, namely, nip26 and nip41, so the future I want is easy to create: have a "hot key" that you use most of the time and a "master key" that you authenticate it with. If your hot key gets compromised, use your master key to invalidate it (either via nip26 or nip41 or both).

Clients who implement those standards will automatically migrate to your new key. Everyone else can rely on this time-tested alternative: notice that user-whoever has a new key (because they said so somewhere), manually unfollow/refollow them, complain they had to do this manually, someone in the comments will tell them "actually they use nip-blah so clients can automatically migrate to their new key if they just implement the spec," and then they can complain to their favorite dev to implement that spec so that their client automates this too.

No one can stop you from using key delegation/invalidation on nostr! It's just that those who choose not to use it will have a little manual work to do if your hot key gets compromised. But I think that's fine because that's already how it works (so it preserves the status quo for everyone who chooses not to use it) and it will just result in complaints to devs until they automate the migration process using one of the existing nips or perhaps a better one.

Here's an interesting and relevant comment from fiatjaf:

One nice thing about some of these proposals, like NIP-41, or the social-recovery method, or the external-source-of-truth-method, is that they don’t have to be implemented in any client, they can live in standalone single-purpose microapps that users open or visit only every now and then, and these can then automatically update their follow lists with the latest news from keys that have changed according to multiple methods. source

0 sats \ 3 replies \ @crrdlx OP 12 Jul

have a "hot key" that you use most of the time and a "master key" that you authenticate it with. If your hot key gets compromised, use your master key to invalidate it

Now this is sounding like what I'm hoping for!

"Dear Santa, I haven't been naughty this year, so..."

100 sats \ 2 replies \ @supertestnet 12 Jul

Now this is sounding like what I'm hoping for!

My overall point is, you can do this right now. Nothing is stopping you. Create a master key, back it up, create a hot key, and sign a message with your master key saying "this is my hot key: <insert_hot_key_here>"

Now start using your hot key for everything, and if you ever lose it, sign a new message with your master key saying "this is my new hot key: <insert_new_hot_key_here> this hot key is no longer valid: <insert_old_hot_key_here>"

Nip 26 and nip41 formalize a way to do this but even if you can't find software that supports those nips, you can just do it manually for now and then nag devs to automate it for you via those nips or better ones

I recommend not waiting for "Santa" (devs) to do stuff for you. Start doing it and devs may follow.

0 sats \ 1 reply \ @crrdlx OP 12 Jul

Two points well taken. (1) Do stuff yourself. (2) "My new hot key..." profile announcement on master.

This "profile announcement" technique has occurred to me and I may well do it one day.

The only downside is the bad actor still can pretend to be you in the "no longer valid" hot wallet. Bad stuff coming from my username and my avatar going out to my followers is a bad look. Gonna guess very few would ever do the legwork on corroborating things by checking my "master key" profile with its "this key is no longer valid" announcement. Frankly, who'd even know to look for such a thing?

The takeaway I'm gathering here is that it's simply not possible to "burn" a private key/nsec (to neuter its ability to do anything) and transpose the "account" (followers, notes, etc) to a new one. 😞

21 sats \ 0 replies \ @supertestnet 13 Jul

The only downside is the bad actor still can pretend to be you in the "no longer valid" hot wallet

Sure but probably not for very long, word gets round

As soon as he does something bad people will stop following him and say "yeah I don't like so-and-so anymore because of X bad thing" and then someone else will tell them, "Oh, that's not him anymore, his key got compromised, this is his new key: <whatever> -- and btw if your client supported nip-whatever it would have automatically migrated you as a follower to his new key. Use client-whatever or ask your dev to add support"