Replying to 772f9545...

This sequence:

Alice and Bob use nostr clients.

Charlie runs a relay.

Both Alice and Bob set their clients to use Charlie's relay for inbox and outbox.

Both Alice and Bob configure their clients to use CRI.

Alice follows Bob.

Bob opens his client software on Day 0 and posts notes successfully. He keeps his client software running constantly.

Alice opens her client software on Day 0 and successfully reads all of Bob's notes from Day 0 (from Charlie's relay).

Alice closes her client software on Day 1, it is no longer running on her computer or phone.

Bob posts a note on Day 2, it is stored at Charlie's relay.

Bob's key rotation occurs on Day 3. Bob publishes the old secret key on Day 3.

Bob posts a note on Day 4 using the new key, it is stored at Charlie's relay.

Eve uses Bob's old secret key on Day 4 to post a note dishonestly back-dated to Day 2 and publishes it to Charlie's relay.

Alice opens her client software on Day 5 and it retrieves the Day 2 posts, Day 3 rotation event, and Day 4 post from Charlie's relay.

How can Alice's client know which post on Day 2 is legitimate? Would both be flagged as "post rotation noise" or both appear legitimate or some other outcome?
Avatar
GHOST 0mo ago

Nice one. A good edge case example.

The answer is Alice cannot know which Day 2 post is real and neither can any Nostr client. CRI does not claim otherwise. What CRI guarantees is that the forgery cannot extend past the Day 3 rotation, cannot regain authority, and cannot affect future history.

Reply to this note

Please Login to reply.

Discussion

77
772f9545... 0mo ago

Nice. So with CRI, one can also gain plausible deniability by routinely publishing old secret keys after rotation. Relays could maybe come up with a way to label suspicious events or reject them outside a certain date range bounds (I think this is NIP-22) but that still wouldn't guarantee that a note came from a given individual who routinely publishes old secret keys.