Mixminion: Design of a Type III Anonymous R er Protocol George Danezis Roger Dingledine Nick Mathewson Presented By Michael LeMay

Introduction Direct descendant of previous generations: –Type I r er: Cypherpunk/Chaumian Mixes (previous presentation) –Type II r er: Mixmaster Doesn’t support anonymous replies Sender can select route Integrated message pool support Constant message size Replay attack prevention Smarter reordering Cover traffic (in theory) –Type III r er: Mixminion

Assumptions & Requirements Designed for high latency traffic ( , not web browsing) Prevent acquisition of any information not believed a priori by adversary Adversary capabilities: –Observe all traffic –Generate, modify, delay, or delete traffic –Operate mixes and compromise other mixes Adversary wishes: –Identify sender or recipient of particular message –Trace a sender forward (or recipient backward) to its messages

Further Objectives Hide number of hops [1-32] from intermediaries Hide position in network from intermediaries Be simple to deploy Only require forward senders to install extra software –Provide gateways to reply to anonymous senders Provide good anonymity for intermittently connected users (dial-up, etc.) Provide no backward compatibility except encapsulation of Type II traffic

Single-Use Reply Blocks Nym-linkage attack possible in simple scheme: Hi, I’m Bob. Hi, I’m Charlie. Good to hear from you, Charlie. Likewise. – Charlie Bob = Charlie

Single-Use Reply Blocks (cont.) Unique seed prevents nym-linkage: Hi, I’m Bob. Hi, I’m Charlie. Good to hear from you, Charlie. She’s onto me

Crossover Routing Route broken into two “legs,” with a header for each Second header encrypted HdrA HdrB

Variable Anonymity Various anonymity levels for different messages: Sender Onion Sender Onion Random Data Single-Use Reply Block Single-Use Reply Block Sender Onion ForwardDirect Reply Anonymized Reply SndAnonymousNon-anon.Anonymous RcvNon-anon.Anonymous

Path Selection Conventional wisdom says senders should choose many different paths through mixes to enhance anonymity If any entire path compromised, anonymity compromised as well If single path is used, passive adversary sees flood of traffic Best approach: use small number of paths and spread out transmissions

Tagging Attacks Allows tracking of individual messages: Msg

Tagging Prevention Routing potentially separated into two phases After first header is processed, second header is decrypted and substituted for first Decryption key derived from hash of payload If payload tagged, decryption fails and message rendered non-routable

Multiple-message Tagging Adversary can operate crossover point to track streams of messages, some of which are tagged Adversary confirms that tagged messages are dropped, and then re-tags other messages and observes their routes. Can be prevented by choosing multiple crossover points, to decrease probability that adversary owns them all.

Link Construction Older r ers used SMTP transports Uses TLS tunnels with ephemeral keys Provides forward anonymity for messages Heartbeat signal could be used to prevent malicious delays Traffic analysis still possible This violates fundamental principle, infrastructure reuse, is it worth it?

Key Rotation Mixes rotate public keys to prevent replay attacks –Chaum suggested timestamps, but this allows message tracking via delays –Mixmaster caches recent message IDs, but must expire them after awhile Cache message IDs for current key Around key transition, adversary can partition senders by their knowledge of new key

Trickle Attack Directories provide information about available mixes: M N P A B Old Directory Includes M New Directory Excludes M Only Alice would still be using M…

Timed Dynamic-pool Batching Messages batched and delayed for fixed period, or until enough messages arrive Only delivers constant proportion of batch each time, randomly composed Difficult to fill buffer and deterministically flush out particular message

Dummy Traffic Dummy traffic core component of other anonymity protocols, but is actually not well understood Dummy traffic only used between mixes, to make it more difficult to track flushed messages

Exit Policies & Abuse Unsolved problem –Opt-in and opt-out requests can both be forged, causing harassment or DoS, resp. –Number of exit nodes and potential for abuse directly related –Number of exit nodes and maximum degree of anonymity directly related Compromise –Each message includes secret allowing opt-out Should recipients opt-in to receive anonymous messages?

Delivery Methods Configurable: –Type II r er –SMTP –Local mailbox Capabilities indicated in directory Individual sender preference for particular method may allow adversary to defeat anonymity (partitioning attack) Active attackers can advertise rare and valuable delivery option on compromised node Should exit nodes provide single option instead?

Nym Management Fresh single-use reply block required for each message sent to nym Two main management strategies: –Nym owner supplies plenty of SURBs a priori, and nymserver forwards messages immediately –Nym owner connects to nymserver periodically and supplies batches of SURBs until all queued messages have been forwarded Mail may be encrypted using nym-owner’s public key, to reduce impact of server compromise