Mixminion: Design of a Type III Anonymous Remailer Protocol

1. Mixminion: Design of a Type III Anonymous Remailer Protocol George Danezis Roger Dingledine Nick Mathewson Presented By Michael LeMay

2. Introduction • Direct descendant of previous generations: • Type I remailer: Cypherpunk/Chaumian Mixes (previous presentation) • Type II remailer: 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 remailer: Mixminion

3. Assumptions & Requirements • Designed for high latency traffic (email, 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

4. 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

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

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

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

8. Variable Anonymity • Various anonymity levels for different messages: Anonymized Reply Forward Direct Reply Sender Onion Single-Use Reply Block Sender Onion Sender Onion Random Data Single-Use Reply Block

9. 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

10. Tagging Attacks • Allows tracking of individual messages: Msg

11. 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

12. 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.

13. Link Construction • Older remailers 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?

14. 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

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

16. 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

17. 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

18. 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?

19. Delivery Methods • Configurable: • Type II remailer • 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?

20. 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