Design Project 2: An electronic pseudonym service

Introduction // The assignment // Some issues // Some pointers and suggestions


Anonymity has become increasingly relevant to the Internet. With archivers and indexers such as DejaNews and Alta Vista, anything you say in a public forum (such as newsgroup or mailing list) will be with you for the rest of your life. Moreover, many current forms of anonymous communication would be better served on-line. For example, the Course 6 underground course evaluation guide asks for your feedback anonymously. Finally, anonymity can be crucial in guaranteeing freedom of speech. In the last cases in particular, people need a strong guarantee that their identity will not be compromised.

One way of achieving anonymity is to use a pseudonym. Pseudonyms have the feature that they can stand in place of an ordinary name and thereby avoid disrupting systems that depend on names. The problem with trying to use a pseudonym on e-mail is that e-mail addresses generally must be registered with some mail system administrator, and you may not want to trust that administrator with your true identity.

Your task is to design a service that provides electronic e-mail pseudonyms to protect the identity of its users. The key constraint in the design of your pseudonym service is that, when properly used, no single person should be able to find out the real identity behind a pseudonym. Even if a server providing the service itself is compromised (e.g., broken into or subpoenaed by authorities), it should be impossible to find out who the users of the service are. Your service should meet the following requirements:

  1. The pseudonym should look like a regular e-mail address to the rest of the world. The recipient of a piece of e-mail from a pseudonymous source should be able to read and reply to the message with unmodified mail readers.
  2. No single administrator should be able to discover the identity of a user.

Keep in mind that some of these requirements are negative goals, and therefore you should consider all the possible ways in which your design can be compromised. Be careful, a single unaddressed issue could be fatal to your design. In your report be sure to identify which threats your design tolerates and which not. Think things through.

There are different ways to approach this problem, each with its own merits and disadvantages. It may be difficult to achieve all properties you consider desirable at the same time. As in most system designs, trade-off and compromise is required, so you have to decide how important each desirable property is in relation to the others.


Your team's assignment

First, this is a team project, so form a team of 3 people where everyone has the same recitation instructor. Please send email to your recitation instructor before Thursday, April 17 with the names and email addresses of your team members. Then get to work! Your team's report is due in recitation on Thursday, May 1.

Your team's job is to write a report that describes the design of an pseudonymous email service that meets the two requirements listed above. Your report should be long enough to be self-contained and complete, but no longer than 10 pages.

Describe the protocols used by your system, the means of privacy and authentication, and the user interface(s) your system presents. Explain how your design addresses security issues (secrecy and integrity of email, privacy of the users, etc.). Evaluate your design from a technical standpoint. You should also discuss the social impact of your design.

Phrase the goals and design of your team's project in 6.033 terminology and use 6.033 design approaches and techniques that were discussed in lectures and recitations.

We suggest you pick one design for your anonymous email service and argue why it is a good design by evaluating your specific design choices. You can strengthen your report by contrasting to other approaches, but do not turn your report into a survey of existing services.

Feel free to study existing anonymous email services (see below for some pointers) and the references included below. But, be sure to include give credit to the work from which you are borrowing.

Your proposal will be read mostly by skeptical prospective users and their security consultants, but also by some congressional staff people worried about both privacy and law enforcement. You should assume that your readers have taken 6.033 but probably have not thought carefully about this particular problem. They know the high-level goals but, probably haven't had the time to study all the technical and social aspects of mailers, PGP, etc. It is your team's job to give them a good, coherent, self-contained, well-written proposal for a design, including an evaluation of the benefits and disadvantages.

It is crucial that you provide enough detail for skeptical prospective users and their security consultants to evaluate the real-world feasibility of your design. To this end, your report should include at least one specific example: Describe exactly how to create a pseudonym and what happens when you send mail using a pseudonymous return address and what happens when someone replies to mail that came from from a pseudonymous address. In addition, your report should describe how secure your design is; what kind of attacks can it tolerate? What kind of attacks lead to problems? Finally, your reports should also comment on social and ethical questions that a pseudonym service raises.

Do not assume you have to use existing software and do not get caught up in the details of any existing systems and support software (such as PGP). It is fine to require those with pseudonyms to make use of new or modified client software. Of course, just receiving mail from or replying to a pseudonym should not require any special software.


Some issues

The key issue to keep in mind is that no single administrator should be able to discover the identity of a user. This most likely requires the service be distributed across multiple machines under the control of different administrators.

You might want to think about the following issues while developing your design. This is by no means an exhaustive list; it will just get you started.

General issues:

Security issues:

Denial of service issues:

  1. If your service is distributed across multiple machines, and one of the machines is closed down by a court order, can you still use your pseudonym?
  2. How easy is it to mail bomb someone from a pseudonymous address?
  3. Can someone flood you with mail by creating a pseudonym that forwards messages to your e-mail address and mail bombing that pseudonym (e.g., by subscribing it to many mailing lists)?
  4. Can an attacker overload the service by creating infinite mail loops (e.g., two pseudonyms that forward received mail to each other)?
Possible techniques you might want to consider:

  1. Use well-known public keys for servers
  2. Allow symmetric encryption at servers
  3. Require that some (or all) messages be of fixed size (In which case long messages might have to be fragmented and reassembled.)
  4. Reorder and delay messages
  5. Generate encrypted but meaningless cover traffic between servers
  6. Use replay caches
  7. Use temporary public keys which are never written to stable storage
  8. Hide servers behind pseudonyms
  9. Use message pools to receive replies (e.g., alt.anonymous.messages)


Some pointers and suggestions

Designing a server that provides anonymity is not easy; many people tried and have gotten it wrong. To help you along we have included some references. You should be able to execute this project without reading any of them, but they might be helpful sources to organize your thinking.

nym.alias.net is an existing email service providing pseudonyms. Check out the help file to find out how to use it and what its features are.

You might find the following two RFC on e-mail helpful. The email RFC specifies the Internet format of text email messages. The mail transfer protocol is specified in the SMTP RFC.

Pretty-good Privacy is a software package for private electronic communication. You might find it helpful to see how it operates, and you might want to use it in your design. Mailcrypt is an emacs interface to PGP.

Some documents discussing anonymous servers (obtained from publius):


Top // 6.033 home // 6.033 Handout 26, issued 4/10/97