Len Sassaman

Imagine a private-mail service whose setup few people can understand. Its technical design may be clever, yet it may help very few people in practice. Len Sassaman connected privacy with usability: on his research website, he explained that an overly difficult system might fail to attract the users it needs. Anonymous communication also depends on the other traffic among which a message can blend in. His question was therefore not just whether the mathematics worked, but whether people could use the system correctly. He studied both how to defend such systems and how to break their protections. [1]

One approach was Mixmaster, an email-forwarding system intended to make senders harder to link to recipients. Mixmaster Protocol Version 2, dated 29 December 2004, lists four coauthors: U. Moeller, L. Cottrell, P. Palfrader and L. Sassaman. There is no need to turn Sassaman’s contribution into a lone-inventor story. The document is an archived Internet-Draft, a working proposal submitted within the IETF, an organization concerned with internet standards. It is not an approved IETF standard merely because it appears in that archive. Its value here is as a concrete record of what its authors proposed. [2]

Encrypted content resembles a letter in an opaque envelope: the words are hidden, but delivery remains observable. In digital communication, these surrounding details are called metadata. They include message size, timing and frequency. The 2004 Mixmaster draft combines layers of encryption, fixed-size data packets and a shared pool from which messages are gradually forwarded. This aims to make a particular incoming message harder to match to an outgoing one. Mixing also means waiting. These mechanisms explain how the protection is constructed; they do not promise anonymity regardless of how the system is used. [2]

Sending a letter discreetly is only part of the story. If someone recognizes you collecting it from a mailbox, the connection can be exposed at the other end. Len Sassaman, Bram Cohen and Nick Mathewson addressed this problem in their 2005 paper The Pynchon Gate. The design uses an existing anonymous channel for outgoing mail. For incoming mail, it uses private information retrieval, or PIR: retrieving data while hiding from the serving systems which item you want. Sending and retrieval are therefore not two names for the same operation. They protect different parts of the journey, and both matter. [3]

PIR in the 2005 design sends different queries to selected distributors, servers that provide the stored data. The paper calls their number k. The client combines their answers to recover the requested block without an individual query simply announcing which block it wants. This protection assumes the attacker does not control all these servers. Who operates them therefore matters. Several addresses controlled by the same person are not equivalent to independent operators. The server count alone does not establish operator independence; this assumption must match the actual deployment. [3]

Imagine downloading noticeably more data only when you receive a lot of mail. An observer may learn something without reading the contents. The 2005 design therefore uses fixed-size blocks and additional queries up to a set maximum. A client cannot always stop immediately after fetching its real messages if it is to follow this protection scheme. The cost is straightforward: it transfers data that would not be needed just to read the mail. Privacy here comes not only from encryption, but also from the program’s behavior and the willingness to carry extra traffic. [3]

In the 2005 paper, Pynchon Gate uses hashes, short digital fingerprints for checking data, and a common root hash for the organized collection. Recomputing a fingerprint helps verify a match with expected data. But if an attacker supplies both altered data and a substituted root, matching the attacker’s own value is insufficient. The authors therefore require widely published verification information and checks that the distributors being used agree on the root. The question is not only whether the fingerprint matches, but how we know which fingerprint should match. Verification needs a trustworthy starting point. [3]

Alongside the Pynchon Gate paper, it is useful to read the README, the software project’s introductory description. Its author, Nick Mathewson, calls the implementation a work in progress and lists distributor and collator code, not a complete system. The collator prepares and organizes messages for distribution; the user-facing software is separate work. This historical record does not establish that the service is ready for safe use today. That does not diminish Sassaman’s contribution. He helped identify real problems and develop solutions whose value becomes clearer when their assumptions and limits are understood too. [4]