Privacy Pass: Anonymously Limiting Abuse George Tankersley https://twitter.com/gtank__ 

Our scene: Cloudflare vs Tor, 2016 

Cloudflare vs Tor Cloudflare ● Massive global CDN ● 100+ PoPs, “10% of the web” ● Not just a CDN, does extra logic Tor Project ● Distributed anonymity network ● ~6000 relays, ~2M users / day, ~200Gbit/s ● Tor Browser Bundle (Firefox ESR) 

Cloudflare vs Tor Two things to know: 1. Tor hated Cloudflare 2. They were very loud about it 

It was all very reasonable 

The problem was CAPTCHAs Cloudfare use of IP reputation + Tor exits’ terrible IP rep 

The problem was CAPTCHAs Averages from 7 days’ traffic: ● 1.6 trillion web requests ● 780 million from Tor exits (0.05% of traffic) ● 16.5B CAPTCHAs served (1.04% of global requests) ● 132.6M CAPTCHAs served to Tor (0.8% of CAPTCHAs, 17% of Tor requests) Disproportionately challenging Tor users. 

They noticed 

Social Problem, Technical Problem 

Technical solutions First, nuke the office IP reputation (incentive to improve!) Then ● Adopt reCAPTCHA v2 ● Add option to whitelist Tor network as a “country” ● Alter the internal treatment of Tor traffic ● Invent some clever crypto protocol? 

Technical solutions First, nuke the office IP reputation (incentive to improve!) Then ● Adopt reCAPTCHA v2 ● Add option to whitelist Tor network as a “country” ● Alter the internal treatment of Tor traffic ● Invent some clever crypto protocol? Sounds good! 

Technical solution A new protocol needs to meet the requirements of all parties: ● Cloudflare wants to protect websites from automated abuse. ● Tor Browser wants to protect the anonymity of its users. ● Users want to solve fewer CAPTCHAs. What if we gave users an untrackable token that proves they solved a CAPTCHA? 

Privacy Pass Unlinkable, unforgeable, single-use anonymous credential Meets everyone’s needs: ● Allows Cloudflare to rate-limit with CAPTCHAs ● Prevents Cloudflare from tracking users ● Allows users to bypass redundant CAPTCHAs And they’re more efficient in batches! 

Prerequisite: blind signatures Idea: A user wants a signer to sign a message without learning its contents Functions: sign, verify, blind, unblind blindMessage := Blind(message) blindSignature := Sign(blindedMessage) clearSignature := Unblind(blindSignature) Verify(message, clearSignature) => true 

Signatures with RSA Public (N, e) and private d N = p*q and d = 1/e mod (N) Generate a signature S by S = Md mod N Verify it by checking that Se == M mod N (Md)e = M(1/e)*e = M1 = M mod N N is the modulus, product of two primes e is the public exponent, d is its inverse is magic, do not let it sense fear 

Blind Signatures with RSA Generate a blinding factor re Blind the message: M blind = (re)M mod N S blind = (M blind )d mod N r also has an inverse, 1/r To unblind a signature: S = (S blind ) * (1/r) mod N = (M blind )d * (1/r) = (reM)d * (1/r) = (M)d(re)d * (1/r) = Md * red * (1/r) = Md mod N 

Prerequisite: blind signatures Blind signatures provide unlinkability. Unlinkability means: ● Can’t tell that blinded/unblinded signatures are related ● Signer can’t associate unblinded (message, signature) with the blinded message it signed. 

The protocol, generally Issuance Phase 1. User encounters a CAPTCHA or other challenge 2. User generates [many] blinded tokens, submits them with solution 3. Server signs tokens and returns them to user with response 4. User unblinds signatures and stores (token, signature) pairs. Redemption Phase 1. User encounters a CAPTCHA or other challenge 2. User submits a (token, signature) pair instead of solving 3. Server validates token, then grants access or rejects 

Issuance, in detail 1. User generates a random token t and a blinding factor r 2. User calculates T = HashToGroup(t) and M = rT 3. User sends M to the server along with the CAPTCHA solution 4. Server validates solution with the challenger and signs Z = xM = xrT 5. Server generates ZK proof D showing that DLEQ(Z/M == Y/G) 6. Server sends (Z, D) to user 7. User checks the proof D against the sent tokens and the server’s public key commitment Y to establish that the server is using a consistent key. 8. User unblinds Z to calculate N = (1/r)Z = xT and stores (t, N) 

Redemption, in detail 1. User calculates request binding data R for the request they want to make 2. User chooses unspent token t to redeem and retrieves (t, N) 3. User calculates a shared key sk = Hash(t || N) 4. User sends a pass (t, HMAC(sk, R)) to the server with the HTTP request 5. Server calculates R’ from observed request data 6. Server checks the double-spend list for t 7. Server calculates T = HashToGroup(t), N = xT and sk = Hash(t || N) 8. Server checks that HMAC(sk, R’) matches the user-supplied value 9. If HMAC matches, server processes the request and stores a record of t 

Issuance and Redemption Flows 1-RTT best we can do; there is no known 0-RTT blind signing 

Even more detail (for later) Design rationale: https://privacypass.github.io/protocol Protocol spec: github.com/privacypass/challenge-bypass-extension/blob/master/PROTOCOL.md Paper: https://petsymposium.org/2018/files/papers/issue3/popets-2018-0026.pdf Brave's improved variant: https://github.com/brave-intl/challenge-bypass-ristretto 

Security & Privacy Guarantees 1. The server can’t track users through the tokens 2. The server can’t segment users with selective key use 3. The server can’t maliciously craft tokens or signatures 4. Users can’t create tokens without the server’s approval 5. Users can’t use a token more than once 6. Users can clear their state at any time 

Server can’t track users through tokens Because of the blinding, each token spend is unlinkable both from its issuance request and from other tokens in the same issued batch. But if a user tries to spend the same token twice, those two requests will be linkable to each other (still not to issuance!) Extensions: traceability would allow you to link a token to its issued batch on double spend. Complexity tradeoff. 

Server can’t segment users via keys Server could try to tag users by using unique signing keys. But it can’t go undetected w/ ZK proofs of key consistency Epochs/rotation and publishing key commitments: ● Signed software ● Transparency? Logs, auditors ● Other (e.g. Tor consensus) Tradeoff: number of simultaneously valid keys vs anon set 

Server can’t maliciously craft tokens or signatures Server might try to tag users with structured responses. Can’t structure tokens: client generates them! Can’t structure signatures: unblinding is keyed randomization! 

Users can’t create tokens without the server’s approval Token redemption involves (t, N) where N = k*H(t) A valid signature requires k, which is the server’s secret. Type of algorithm called an oblivious pseudorandom function. 

Users can’t spend a token more than once Token redemption involves (t, N) where N = k*H(t) User incentives: ● t is a unique value. If server sees it twice, can link IPs/requests. Server enforcement: ● Maintains double-spend list to deny reuse during given key epoch. 

Users can clear their state at any time Especially common for Tor Browser: “New Identity” button Protocol doesn’t assume any long-term user identity or keys Complete state clearance looks like a new user 

Operational Needs 1. Signing/Validation service (low maintenance, ~stateless) 2. Key management and rotation (tunable; security/privacy) 3. Trusted key publication endpoint or client software (TBB) 4. Double-spend accumulator (tunable; potential SPOF) 

In practice We redeem tokens for a TTL’d clearance cookie (safe because SOP). ● Token is effectively an anonymous, cross-origin precookie Probabilistic double-spend. We avoid SPOF by allowing occasional false negatives. We use an elliptic curve VOPRF for 10x better bandwidth & speed than blind RSA. ● Was necessary at one point to fit tokens in a header ● Uses NIST P-256 for compatibility. Not optimal. Use Ristretto now. Binding data is Host and Path concatenated. 

Deployment stats Released Nov 2018, ~108k downloads now (Chrome: 86,738; Firefox: 21, 161) The number of redemptions occurring peaked globally at 2000 qps and for Tor users at 200 qps during the surveyed week. Not an experiment! Privacy Pass is still running. In absolute numbers it’s more popular with VPN users than Tor. Operation Bytes Signing request 57 + 63 * N Signing response 295 + 121 * N Redemption request 396 Bandwidth Overhead* (batch of N) *Median request and response sizes for Tor users were 700–800 bytes and 5–6 KB. 

Extensions and Future Work ● Performance: faster curves, better impl, batch & vectorize ○ Brave is already doing this! ● Standard AC properties ○ Attributes (open and/or hidden) ○ Tracing ● Asymmetric version (issuer != verifier) ● Composition with macaroons (anon “OAuth” delegation?) ● Post-quantum primitives: lattice, isogeny variants 

Questions? George Tankersley https://twitter.com/gtank__