Avatar
Neo ⚡️ 3mo ago 💬 19

Are there actually long term solutions on the horizon to fix our dependence on having only on nsec? Any ways that at some point we can drop a potential old nsec and replace it by an backup key that automatically inherits the same connections etc.

It's crucial imo, we are building our network / wot based on this investing years and at some point decades into it.

It will become incredibly valuable to navigate the upcoming free, show me recommendations, opinions etc only from my network and so on.

But all it takes once we have build or p2p network state is one compromised hyped new app build by a coordinated bad actor to destroy all the trust by compromising the nsecs.

#asknostr

Reply to this note

Please Login to reply.

Discussion

Avatar
Ryan 3mo ago

A valid concern that I see just being hand waved away usually.

"Don't be so concerned, just start a new one. Losing your identity is NBD 🤷‍♂️"

Not having any way to recover or transfer identity is a major downside of Nostr.

Avatar
Neo ⚡️ 3mo ago

Yeah, I really hope that it's possible to solve this. I really envision a feature where I can trust my WOT everywhere (filter online reviews, can i buy from this guy p2p, general recommendations, health tips, p2p research, loans etc.) It could unlock so much. But all this won't work if you can loose it all with one single compromised app. In this case a social network for us nerds is all we can get.

Avatar
Ryan 3mo ago

This is why I only use apps that let me use a signing app, no nsec pasting. At least the attack surface is lessened that way.

Avatar
Neo ⚡️ 3mo ago

Yeah definitely the way to go for now 👍

But I really hope we can do better.

Avatar
Ryan 3mo ago

I've worked a support for Internet and SAAS companies. Without any way to recover accounts it limits Nostr's use for a majority of people I think.

Key management is not obvious, and most people just don't understand or care enough.

Avatar
Neo ⚡️ 3mo ago

If we can get at least a decent tech stack for all the people that value their personal sovereignty would be a good start. Let's hope it can be done on nostr. If not we'll come up with something else ✌️

Avatar
Neo ⚡️ 3mo ago

Sometimes the fact that nostr doesn't support edits sucks 😅

Avatar
Dikaios1517 3mo ago

I'll let someone smarter than me get into the weeds on this.

As I understand it, there was a lot of thought and even a spec created for key rotation, but it ends up creating more problems than it solves. See NIP-26 and the discussion around it:

NIP-26

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

Some issues discussing key rotation:

https://github.com/nostr-protocol/nips/issues/103

https://github.com/nostr-protocol/nips/issues/116#signed-out-banner-sign-up

https://github.com/nostr-protocol/nips/issues/123#signed-out-banner-sign-up

https://github.com/nostr-protocol/nips/issues/247

https://github.com/nostr-protocol/nips/issues/654

https://github.com/nostr-protocol/nips/issues/726

https://github.com/nostr-protocol/nips/pull/1051

https://github.com/nostr-protocol/nips/issues/1810

https://github.com/nostr-protocol/nips/pull/1837

https://github.com/nostr-protocol/nips/issues/1959

It's a lot to read, but it shows that our intrepid devs have not just ignored the issue. It is one that has been discussed multiple times at length without a good solution so far.

Bottom line: Don't stick your nsec into clients directly. Use a signer app to limit the potential for your private key to be compromised.

Avatar
Neo ⚡️ 3mo ago

Thank for the links will check them out.

Avatar
david 3mo ago

One solution (not the only solution) will be web of trust.

If my WoT tells me that Alice’s nsec got compromised on such and such a date, and her new nsec is whatever, then my apps will curate content accordingly. My WoT will do a good job because she’ll tell as many of her close associates as it takes to get the word out, and my WoT will have established previously who are her close associates.

This is very doable.

Avatar
Neo ⚡️ 3mo ago

The problem is in such an attack you can't also trust the other keys anymore that claim that this is new key. Plus the fact that the new key would start at zero. People actively have to connect again etc.

Avatar
Mossy Flanagan 3mo ago

Why would you not be able to trust the other keys, particularly if they are keys that you know / follow / interact with?

Avatar
david 3mo ago

Exactly. If we presume Alice’s nsec is the only one compromised, and if she discovers the problem quickly and if she tells her close associates of the problem, and if a handful of them get the word out quickly using their uncompromised nsecs, then we have a relatively effective solution that can be implemented rapidly. Over time the new nsec would rebuild the old connections, but there’s no need for that to happen overnight.

Avatar
Neo ⚡️ 3mo ago

Because if a big client gets compromised there will be many compromised nsecs.

Avatar
david 3mo ago

The WoT solution I described will be useful (once we have a healthy WoT system in nostr) in the typical scenario where an individual nsec gets compromised. If everyone’s nsec gets compromised at once, yeah, that would be a catastrophic failure. Which is why I don’t describe WoT as the one and only solution to this problem. Scenarios like yours are why we don’t hand over our nsecs directly to apps. We use various tools and strategies to minimize our exposure.

Avatar
hodlbod 3mo ago

The problem is important, the difficulty is that because we directly link to pubkeys rather than some proxy identifier (like DIDs do), there's no way to unilaterally migrate links to your key. In other words, people follow your key, and there needs to be some kind of support for either migrating references to keys, or translating an old key to a new one.

The former approach would be marginally easier to accomplish, since it would only require a single client to implement migration. However, users would all have to periodically visit that client in order to perform migrations. Building this into a "core" client like a signer might allow users to run migrations in the background, but even then, only replaceable events could be migrated; kind 1 references would be permanently broken.

The latter approach is more complete, but would require EVERY client to implement complex logic for discovering and validating migrations, potentially creating dependencies on timestamping servers for sequencing events reliably. Right now, even if there were a standard that worked, it would be unlikely to get adoption. What we need is a migrate-keys-sdk that client developers can add to support both migration and key proxying. Someone needs to really own this because it requires an incredible amount of effort.

Avatar
frphank 3mo ago

Key rotation, a debate that comes up every now and then.