Anti-Abuse

The anti-abuse layer combines fixed-window rate limits, an anonymous quota token, a Verifiable Delay Function, an ML-KEM post-quantum challenge, and an optional CAPTCHA token. Its purpose is to make mass account creation and mass deposits expensive without linking the work to a user account.

Rate limiting

core/security.rs::rate_limit_hit implements a keyed fixed-window counter. A bucket holds a window start, a window length, and a count. Buckets are evicted when the store exceeds 5000 entries.

Representative limits:

In addition, chat messages enforce a 400 millisecond minimum interval per session.

Anonymous quota token

Before any gated action, the client requests an anonymous quota token from GET /api/auth/challenge. The token is an HMAC-signed epoch ticket. The client computes an action-scoped nullifier and the server consumes it, preventing reuse of the same ticket for the same action. The nullifier store is RAM-only, capped at 10 000 entries, with a 3 minute TTL, and the comparison is constant time.

Verifiable Delay Function

The VDF forces a sequential squaring computation before a gated action. The client must compute y = x^(2^t) mod N and produce the Wesolowski proof pi. The server verifies the proof in logarithmic time. The default iteration count is 30 000 and the challenge expires after 3 minutes.

Post-quantum challenge

The challenge also carries an ephemeral ML-KEM-768 encapsulation key. The client encapsulates and returns the ciphertext; the server decapsulates to confirm the client performed the KEM step. The key is one-time and expires after 3 minutes.

CAPTCHA flow

The full CAPTCHA flow returns a one-time cap token that can gate a registration, login, recovery, or deposit.

client                          server
      |  GET /api/auth/cap/challenge  |
      |----------------------------->|
      |  { challengeId, scope,        |
      |    issuedAt, expiresAt,       |
      |    vdf, quotaToken, pqcKey,   |
      |    signature }                |
      |<-----------------------------|
      |  solve VDF                    |
      |  compute nullifier            |
      |  encapsulate ML-KEM           |
      |  POST /api/auth/cap/redeem    |
      |  { challenge, vdfProof,       |
      |    nullifier, pqcCiphertext } |
      |----------------------------->|
      |  { success, capToken }        |
      |<-----------------------------|

The redeem handler verifies the challenge signature, consumes the quota nullifier, verifies the VDF proof, and decapsulates the ML-KEM ciphertext. It also checks optional instrumentation: an automated browser flag and a minimum interaction time of 250 milliseconds. The cap token is HMAC-signed, expires after 5 minutes, and is consumed once.

Privacy Pass redemption

POST /api/pass/redeem is wired and implements the nonce store with a reserve, verify, commit, release cycle. The store is capped at 100 000 entries with FIFO eviction. The deposit token issuance and consumption are implemented.

Storage bounds and TTLs

The ephemeral stores are bounded to prevent unbounded growth.