No. CRI is intentionally not a deniability system. It is a continuity and containment system.
Discussion
I suppose it wouldn't stop anyone from purposely releasing old, rotated, private keys every so often. That would make it possible for anyone to post a past event for that npub, right, and therefore deniability?
Plausible deniability does not really exist once signatures are public and timestamped.
Releasing old private keys later does not undo authorship. It only proves the key was compromised at some point, not that earlier events were not authored by you. From a verifier’s perspective, every event signed before disclosure remains valid.
Under CRI, an epoch key is valid only for its declared interval. Events outside that window are either ignored or treated as post-compromise noise.
What would stop publication of an event with an old timestamp using a later-compromised key? NIP-22 I suppose (relay policies)? It wouldn't undo old posts that already were relayed but would allow new posts pretending to be old posts to be relayed. And therefore it would be difficult further in the future to distinguish legitimate old posts from fake old posts, right?
CRI adds an explicit temporal boundary. Once an epoch is rotated, the old key is no longer authoritative after that point. Clients can trivially label late events as “post rotation noise”.
I am not certain, but isn't the timestamp in an event created by the client like any other data? In other words, what would stop a (dishonest) client from putting an old date into a new event? Don't relays need to be able to relay old events in some legitimate cases?
CRI does not try to make timestamps truthful. That is impossible without trusted time or protocol changes.
CRI gives clients authorization windows.
Once an epoch is rotated the old key is no longer authoritative after rotation. Any new seen events from that key are labeled post rotation noise. This labeling is deterministic and client side
So even if someone backdates an event it is still first seen after rotation, it still arrives late, and it still conflicts with known lineage.
Nothing becomes ambiguous retroactively.
Suppose I close my client software, two weeks passes, and near the beginning of the two weeks the key rotation occurs for someone I follow. Now there are a bunch of notes more than ten days old according to the new key. They will be labeled post rotation noise by my client, right? How can I know whether those events that come to me are legitimate?
Maybe I am misunderstanding your question. You don’t do anything on your side. Everything happens on the client side regardless if you are there or not. Only the key is rotated, not the identity. You would see seamless notes from that person from before, up to, and after rotation. The key would rotate but you wouldn’t see a difference
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?
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.
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.