NIP-37: general methods for dealing with lost keys

[fiatjaf]

https://github.com/nostr-protocol/nips/blob/key-invalidation-and-migration/37.md

[mikedilger]

What is the 3 month requirement doing?

[fiatjaf]

What is the 3 month requirement doing?

An arbitrary time to prevent the attacker from publishing a new set of trusted peers and then use them to migrate to a new key under his control immediately.

[DanConwayDev]

Overall I think social recovery is an important feature as nostr grows.

I can imagine a future where this is largely handled by social clients with following users not having to take any active steps. This could be similar from a UX point of view, to how signal's 'safety number' changes. Perhaps a warning could be flagged up on their posts for a few weeks to indicate their pubkey has recently been updated and to lookout for unusual activity.

Perhaps the following user's own follows could be used to build trust in the new pubkey recommendation. If their follows who also follow the pubkey have recently updated it to the recommendation then this also builds confidence in the update.

Relays could potentially play a role in building confidence in the new pubkey. They may compare data they have collected related to the old pubkey and compare it to the new key. They could also do timing analysis or sentiment / theme / keyword analysis to assess authenticity.

I'm bullish on the potential of for a smooth UX for recovery from key loss.

[DanConwayDev]

The UX of having to periodically visit a dedicated client to identify and update which of my contacts pubkeys have been compromised is not workable. Users will want to publicise quickly that their pubkey has been compromised to prevent scams and protect their audience / reputation. They will not want to rely on their followers periodically visiting a dedicated client.

[DanConwayDev]

Is there a privacy concern about having this list public? The implementation could be adjusted so that only the kind 1521 event would reveal that the friend's pubkey is included in this event. It could also enable mock entries to mask the number of friends listed. The trade-off would be added complexity for client verification of kind 1521 events.

[DanConwayDev]

Why not add a flag against the pubkey in the kind 3 instead of a new event?

[DanConwayDev]

Clients that don't support the NIP wouldn't inadvertently replace the kind 3 with this information removed.
The list would have a much lower frequency of updates, and the client must ensure it has been OTS'd.

[DanConwayDev]

Are OTS in wide enough use by relays to make this NIP practical?

[fiatjaf]

Zero usage today, but I don't see why they couldn't start being used if this NIP is to be adopted.

[DanConwayDev]

How would changes to the 10520 be managed? Wouldn't relays replace the OTS'd event with the new one and the user would have no recovery for the duration of the activation delay?

[DanConwayDev]

How widely is OTS verification implemented by social clients? Is it realistic to expect them to do this?

[fiatjaf]

OTS can be done by clients or third parties, doesn't have to be the client directly.

[DanConwayDev]

What would prevent an attacker who compromised a key from creating a new kind 10520, getting a OTS and waiting 3 months before publishing it?

[fiatjaf]

Nothing.

[DanConwayDev]

What should a client do if there competing succeeding pubkeys were proposed with an equal number of votes both above the threshold?

[fiatjaf]

I don't know, I think this is up for clients to decide.

[DanConwayDev]

Is there a recommended UX implementation. Update the pubkey automatically and notify the user. Notify the user and prompt them to do so manually?

[fiatjaf]

I think clients can each decide on their own UX.

[alexgleason]

If the attacker has the private key, they would simply post a kind 10520 event pointing to other compromised pubkeys, making it pointless.

[fiatjaf]

That's why I added the OpenTimestamps requirement. Timestamping can be done for free by some altruistic entity for everybody.

[DanConwayDev]

Here is an alternative suggestion that removes reliance on events published by a potentially compromised pubkey:

{
  "kind": 1521,
  "pubkey": "<pubkey>",
  "tags": [
    ["p", "<compromised-pubkey-of-contact>"],
    ["e", "<other-trusted-kind-1521-event-referring-to-the-same-pubkey>"],
    ["new-key", "<suggested-new-key>"]
  ],
  "content": "out-of-band communication" | "report from trusted contact",
  // ...
}

Clients MAY listen for kind 1521 events referencing the user's contacts.
Clients MAY use the user's social graph to identify the trustworthiness of each 1521 event and the aggregate trustworthiness of reports for a pubkey.
Clients SHOULD update the user's contact lists and publish a kind 1521 when they are assured of trustworthiness. Reports must flow through webs of trusts in order for this mechanism to be effective.

[Freakoverse]

Saw this post and thought I'd throw in what I wrote previously about this topic in a habla article.

There'd be two new fields in a Nostr account's metadata:

Backup key:
Compromised: yes/no. Once you've set your backup key, it can never be changed, and once you know you've been compromised and switch that "Compromised" toggle to yes, it can never be toggled back to a no.

What should happen when you toggle "Compromised" to a yes? Your updated account's metadata would be pushed to relays and clients and said clients would then present the account as being compromised to followers and viewers while showing the new backup account.

[alexgleason]

This was your best idea IMO. I thought you already wrote it out somewhere. But we should absolutely do it. It fits perfectly with NIP-46 and would make loss of keys much less painless, as long as they were generated by an app that supports it (and most apps will).

[fiatjaf]

#158

I'm glad that you liked it. I still like it, but it's too complicated, so I left it for a future in which people will be smarter.

[ariard]

I think NIP-109 could be modify to concern any pubkey without the restriction to the subset of kind 5 (internet identifier) as ideally you would like Nostr key management standards to work in perfect autonomy from the social layer, e.g doing key operation on hardware where there is no internet access to probe the validity of the internet identifier.

[ariard]

I think this is can be implicit in the value of the “kind” itself and rather make it mandatory for the client to ask a “challenge” to sign a kind 10529 with the compromised pubkey. E.g a “challenge” can be the example given after of requiring a user to type a message. Other “challenge” could be a pre-registered password in the client hard state or really any existent password protocol (e.g a time-based one-time based password).

See also PGP revocation format, it’s just a dummy 0x20 signature type to announce revocation: https://www.rfc-editor.org/rfc/rfc4880#section-5.2.1

[fiatjaf]

I am just worried because I use this https://github.com/fiatjaf/nak CLI tool to generate events and it's harmless 99.9% of the times, but if me or someone else typo or type at random the deletion kind they are gone from the Earth.

[alexgleason]

Yeah but it's easier to accidentally copy and paste your private key into a public chatroom. Then it's also gone forever with even less effort.

[fiatjaf]

So you're saying we should have this NIP specify that you should type your private key in a public chatroom?

[ariard]

I am just worried because I use this https://github.com/fiatjaf/nak CLI tool to generate events and it's harmless 99.9% of the times,

Yeah I would expect with time that type of tools to request a challenge like totp: https://www.rfc-editor.org/rfc/rfc6238 (google authenticator based on that). For sure key compromise event generation gonna stay a worrying operation for user.

[ariard]

I think it should be mandatory to have a opentimestamp tag, or a chain height / unix time. That way the user can commit to the temporal point relative to the Bitcoin blockchain from which the key is considered as compromise.

This might matter for the relay requirement introduced after “Relays MAY also decide to also delete all events from this key” where the deletion is done in reference to the chain height. E.g past reputation is okay, future reputation not okay.

[ariard]

One more tag could be the list of pubkeys actually revoked where the signing pubkey is an authoritative key where the subkeys have previously signed the authoritative key to give a compromise revocation mandate to the authoritative one. Though I think this more method C suggested at the end.

[ariard]

Contrary to my understanding of the introduction, I don’t think method A and method B are exclusive though rather complementary.

From my thinking:

• method A: introduce a key compromise alert system for all relays / clients to do the required local state modification
• method B: introduce a key-based reputation migration system based on pre-committed policy

I think method B can be clearer to specify a “reputation migration certificate”. This certificate should be signed by the requesting key, timestamped in the chain with ots and commit to one or more migration threshold policies (e.g 2-of-2 or 3-of-5).

As long as one relay or client over Nostr has a stored event of the certificate it can be re-announced to the whole network to have the reputation changes happening. Without necessary implying a compromise, it can be good key management practice to rotate keys on “hot” computing hosts or even enable merchant reputation selling.