cadrumo.adapters.persistence.profile.recipient_replay_guard module¶

Encrypted persistence adapter for recipient-package replay-nonce ledgers.

Every RecipientEncryptedPackage carries a fresh, unique envelope_nonce_hex minted at encryption time (see review_package_recipient_encryption). This module lets the recipient side of decrypt_review_package_for_recipient() record which nonces have already been successfully decrypted, so a captured ciphertext replayed a second time against the same recipient bucket is refused rather than silently re-accepted.

The nonce ledger is a bucket-scoped append-only consumption record, following the exact governed-repository shape of the trusted-recipient registry: one FINANCIAL-sensitivity secure-object singleton per bucket, an empty ledger when absent, and mark_consumed refuses a nonce already on file. This is the aeat-architecture-boundaries companion to that registry – the decrypt primitive itself performs no persistence; a caller (the future CLI decrypt verb) composes this ledger’s check_and_consume around the existing, unmodified decrypt_review_package_for_recipient() call. The encrypted row’s storage policy is governed by SensitivityClass.

mark_consumed composes ProfileBareModelSecurePersistence’s mutate for its read-mutate-write-with-retry mechanic, rather than hand-rolling the loop: the ledger is stored bare (ConsumedNonceLedger.model_dump_json() directly, no Envelope wrapper), matching that kernel’s wire shape exactly, and the “refuse a duplicate nonce unretried, else append and retry only on a genuine revision conflict” logic is precisely the mutate contract. load stays hand-rolled because it translates a bare OSError into RecipientReplayGuardError, a translation the kernel does not perform.

Nonce identity is clock-free (the nonce is a random 32-byte value minted once per encryption, never derived from a timestamp), so replay defence does not depend on wall-clock ordering the way the paired expiry check does – see review_package_recipient_encryption for the issued_at / valid_until expiry fields, which are a distinct concern (a package can be replayed within its validity window, and expiry alone does not detect a same-nonce replay before the deadline).