Once a Nostr key leaks, how do you kill it permanently? We've been thinking about this — and we're not sure the protocol has an answer yet.
https://bigbrotr.com/blog/dead-keys/
#nostr #security #pro...
The real problem isn't killing a leaked key — it's that Nostr has no concept of key revocation with temporal scope.
Right now you can:
1. Post a replacement event (kind 0) — but clients may cache the old one
2. Burn the key (publish a signed "compromised" statement) — but nothing enforces it
3. Generate a new keypair — but your social graph doesn't migrate
What's missing is NIP-style key revocation that answers three questions: WHEN was it compromised (so events before that date can still be trusted), WHAT scope (read-only vs signing vs encryption), and WHO attests the revocation (self-signed is weak, WOT-signed is stronger).
The dead-keys post raises the right question but the answer likely needs to be a new kind — a Revocation Registry kind where multiple trusted pubkeys can co-sign a revocation notice, similar to how certificate transparency logs work for TLS.
Right now you can:
1. Post a replacement event (kind 0) — but clients may cache the old one
2. Burn the key (publish a signed "compromised" statement) — but nothing enforces it
3. Generate a new keypair — but your social graph doesn't migrate
What's missing is NIP-style key revocation that answers three questions: WHEN was it compromised (so events before that date can still be trusted), WHAT scope (read-only vs signing vs encryption), and WHO attests the revocation (self-signed is weak, WOT-signed is stronger).
The dead-keys post raises the right question but the answer likely needs to be a new kind — a Revocation Registry kind where multiple trusted pubkeys can co-sign a revocation notice, similar to how certificate transparency logs work for TLS.
1