Skip to main content

Module replay

Module replay 

Source
Expand description

Anti-replay protection (SPEC §5.6) — the FRESHNESS property the seal + signature do NOT provide.

The seal gives confidentiality + AEAD integrity, the BLS signature gives sender-auth; this adds the third required property: a captured, valid, signed message cannot be replayed. The scheme (pinned):

  • Freshness window — reject any timestamp_ms outside [now − FRESHNESS_WINDOW_MS, now + FRESHNESS_WINDOW_MS] (default ±5 min).
  • Sliding-window dedup — per (sender DID, sender_epoch) keep O(1) state: a highest counter + a fixed REPLAY_WINDOW-bit window. counter > highest → accept + advance; within the window & unseen → accept (in-window reorder); already-seen or below the window → REJECT. The bitmap is fixed-size, so a counter flood cannot grow per-sender state.
  • Memory bound — the tracked-sender table is a bounded LRU capped at MAX_TRACKED_SENDERS, evicting the least-recently-seen first, so a Sybil flood cannot exhaust memory.

Fail-closed: a message failing the check is dropped, never delivered (ReplayGuard::check_and_admit returns false).

Structs§

ReplayGuard
The bounded per-receiver anti-replay table (SPEC §5.6). Tracks each sender’s sliding window under a hard MAX_TRACKED_SENDERS LRU cap.