Oddbean

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 @jb55 ?

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. @fiatjaf '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).

Yeah, agreed in all those points. The alternative I proposed in the other note doesn't require the subsequent pubkeys being children of the same master pubkey, just that the next-in-line pubkey is disclosed upfront, which would make it work for existing, non-HD, pubkeys.

I think the details of key relation doesn't really matter, be it HD-derived from a master key, be it derived in a chain from each other, or just a set of predefined keys, they all have in common: - you have to create some state upfront, with secret and public part - you have to safeguard the secret part separately from your 'day-to'day' nsec These two points make pregenerated/HD schemes weaker.

I just have the feeling the pregeneration/msterkey/HD-based schemes will never catch on widely even if implemented. Though if nsecbunker-style separate key storage catches on (even only for power users), that might be a good start to 'deploy' such schemes. The social network based scheme is rather interesting, but has other challenges.

agreed. I think we can leverage all these together. to me the fact that facebook accommodates for social recovery within the paradigm of them actually owning your account, is very telling as to how acceptable it is as a flow and how robust it can be at not getting your account compromised regardless, I think the pregeneration/HD key would be tremendously valuable as an addition to the alternatives you listed (with which I agree with). If we were to roll this scheme now, allowing people to migrate pubkeys, I would imagine a vast number of existing users would leverage it (it's kinda OP_VAULT-y in that way)

Social account recovery can work more-or-less reliably, if peers contact the user in some means _other_ than Nostr, to verify that the identity of the user. I think the protocol should enforce this someohow, otherwise the sceme is easy to trick (peers will just press on the green button wanting to help, without real check). The flow I imagine: - User realizes that he lost his key, or someone else is posting shit in his name (key compromise), or potential key compromise (not yet misused) - User initializes Emergency Recovery in a supporting client. A new identity is created. - User identifies a few trusted nostr user peers who can verify his identity and have other real-life non-nostr means of contacting the user - Posts a event about the key rotation, with the list of the peers, and a min. threshold. - Tagged peers should: - contact the user through some non-nostr means, make sure it is indeed the real person - generate a unique secret code (details tbd, e.g. by signing the event ID of the rotation event) - if not in doubt about the user, send the secret code to him through non-nostr channel - The user, once collecting enough 'ack' codes, posts an event closing the key rotation. Any client can verify the integrity: that it is posted by the same account, and that each ack indeed comes from the mentioned peer (verify cryptographically), and the number is sufficient. A malicious attacker can misuse a scheme to steal an account, if he can convience a few users that he is the impersonated user. To alleviate this, the real user can launch a similar counter recovery process, which takes over provided that it is backed by _more_ peers. This way the real user can win as long as more peers attest this. This scheme is basically what fiatjaf has described in NIP37, with the enhancment to capture the proof that peers have contacted the user. What do you think @fiatjaf ?

Pensando aqui, se houvesse uma forma de manter, durante a criação de uma nova chave, os peers que seriam os certificadores desta chave, um golpista não poderia tentar burlar o processo porque teria que convencer os peers originalmente definido durante o processo de criação da própria chave. O risco seria para quem ainda não o fez (processo de transição atual) ou para quem pula esta etapa do processo. Desta forma, o usuário pode ainda criar identidades de certificação para serem utilizadas como “e-mails de recuperação”. Um invasor, para roubar uma chave, teria que roubar várias, caso o próprio usuário decidisse certificar sua chave com suas próprias contas de certificação, ou convencer amigos do usuário atacado, caso ele delegasse esse trabalho para contas reais.

Thinking about it here, if there was a way to keep, during the creation of a new key, the peers that would be the certifiers of this key, a scammer could not try to circumvent the process because it would have to convince the peers originally defined during the creation process of the key itself. The risk would be for those who have not yet done this (current transition process) or for those who skip this stage of the process. This way, the user can even create certification identities to be used like as a "recovery emails". An attacker, to steal a key, would have to steal several, if the user decided to certify his key himself with your own certification accounts, or convince friends of the attacked user, if he delegated this work to real accounts.

This way, it would be safer to have your own certifying accounts. But as a last resort, friends are defined at the beginning of the account creation process. In the first case, he must keep these certification accounts well to use in a recovery. In the case of indicating real people, the process described above takes into account the extreme case of the subject not having created certifying accounts, or losing these keys.

Logically, all these descriptions does not apply to the nostr model in this way. But it could be applied through a multisig transaction that could only be unlocked by certification keys, and this would guarantee possession of the private key to whoever has these keys