Skip to content

CONCEPT Cited by 1 source

Unlinkability

Unlinkability is the cryptographic property that a token issuance event and a token redemption event cannot be directly correlated by any party — including the issuer, the origin, or a collaboration between them. It is the defining property of anonymous credentials and the load-bearing guarantee of Privacy Pass / ARC / ACT.

What the property means

Given:

  • A client that obtained N tokens from an issuer during session S.
  • A redemption event where the client presents token T against origin O.

Unlinkability guarantees that the protocol itself does not reveal that T came from session S. The issuer cannot mark T at issuance and identify it at redemption; the origin cannot identify which session minted T; a colluding issuer-origin pair cannot correlate issuance and redemption events beyond what any correlating side-channel (IP, timing, cookies) would already allow.

Cloudflare's phrasing from the post:

"ACT preserves unlinkability between presentations at the protocol level, which is the key cryptographic property here. Even in the joint issuer-origin deployment model in Section 4.3 of RFC 9576, the protocol is designed so that token issuance and presentation are not directly linkable."

How it's achieved

The primitives underlying unlinkability are blinding schemes:

  • VOPRF-based issuance (RFC 9497): the client sends a blinded element to the issuer, receives a signed blinded element, and unblinds locally — the issuer never sees the unblinded token.
  • Blind RSA signatures: similarly blinded at issuance, unblinded at the client, verifiable by any party with the issuer's public key without ever linking back to issuance.

The cryptographic machinery ensures that the issuer's view at issuance time and the origin's view at redemption time cannot be the same bytes — they differ by the client-only blinding factor.

Protocol-level vs. end-to-end

A critical caveat the post flags: unlinkability is a protocol-level property, not an end-to-end anonymity guarantee. Higher layers of the stack can still correlate:

  • IP addresses — if the same client IP issues and redeems, the network view is correlatable regardless of token unlinkability.
  • Cookies / session state — cookies set during issuance and sent at redemption create a trivial correlation channel.
  • Account state — if the client is logged in at both endpoints, the account ID bridges the events.
  • Timing / fingerprinting — a client that issues at T and redeems at T+ε with distinctive timing or TLS fingerprint is narrow-linkable.

Unlinkability removes one attack vector. Deploying it without addressing the above is necessary but not sufficient.

Why unlinkability makes "anonymous + accountable"

feasible

The third corner of the rate-limit trilemma needs accountability that does not become a persistent identifier. Unlinkability is exactly that: the origin can verify "this client passed the issuer's check" (that's the accountable half) without learning or being able to link "this is the same client that passed the check last time" (that's the anonymous half).

Without unlinkability, token presentations degenerate into bearer tokens — every redemption reveals the issuance — and the privacy gain collapses.

The 1:1 coupling problem

Base Privacy Pass couples one token issued to one redemption: every presentation burns one token, forcing a round-trip to the issuer for every new scoped interaction. The successor ACT and ARC preserve unlinkability across multiple scoped presentations from a single issuance — this is what makes per-request rate-limit enforcement viable without constant issuer contact. The cryptographic design is harder; the property budget is the same.

Seen in

Last updated · 200 distilled / 1,178 read