what if we just start with kind:1521 with opentimestampped events; this seems like such a trivial get and doesn't open the door of crypto/HD bikeshedding.
Regardless, if we do HD keys we'd still need to do kind:1521 stuff as described in https://github.com/nostr-protocol/nips/blob/key-invalidation-and-migration/37.md
what do you think nostr:npub1xtscya34g58tk0z605fvr788k263gsu6cy9x0mhnm87echrgufzsevkk5s ?
How would kind:1521 in itself be helpful?
Social key recovering is very interesting idea, but tricky.
Some fresh ideas are always welcome for key rotation!
Any scheme has to handle well these cases:
1. A malicious attacker quickly rotating to a new key, which the original victim cannot rotate
2. No key theft occurs, but a user just maliciously rotates away the key of an unrelated, victim user.
For Simple key deletion, 1. is ok as it makes no sense for an attacker to use. To protect against 2., the event has to be signed by the corresponding private key (if this is not enforced, anyone can delete any key; the consequence is that it is not possible to use this in case of lost key).
The Social Key Migration sounds interesting. Though an attacker could be successful in convincing enough contacts to rotate to a new key controlled by them, some contacts would benevolently and unsuspectingly help.
what if the next-in-line key is pre-established?
At time of key generation the pubkey creates a timestamped event establishing which will be its next pubkey (which would be child2 of an HD key).
Upon compromise of pk1, pk2 signs a deletion of pubkey1 and signals to followers that contact lists should update to pubkey2
This is simple but addresses both points; attacker's speed is no longer relevant and only a pre-established pubkey can rotate away the pubkey.
Pregenrated/Masterkey/HD schemes are not good for several reasons:
- Cannot be used for keys already in use
- Can be used for newly created profiles, but only if created with a supporting client
- If two-level key protection is not done by the user/clients (ie. master key is in client), there is a chance for the master key being compromised, for which case the scheme is ineffective
- Basically works only if the user considers the key compromise risk explicitly upfront, which is not the case for most users.
nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 's proposed NIP41 scheme is a clever scheme to ease proving the relationship between subsequent keys, but still has the above issues (pr #158, since abandoned).
