Anonymous Voting Guide for NetBSD Board Elections

Anonymous Voting Guide for NetBSD Board Elections
Jeremy Cooper, August 2002


Introduction


Gentle Developer:

Hello, I am your Vote Validator for the NetBSD Foundation's 2002 Board of
Directors election.  This guide, prepared specially for this event,
outlines methods you can use to vote anonymously in this election if you
so choose. I have a public PGP key with which I will sign all voting
results, and can also be used by you to encrypt your vote irrespective of
your choice to send it anonymously.  My key can be found in three places:

1) In my home directory on cvs.NetBSD.org:~jeremy/pgp-key

2) At keyserver.net: http://www.keyserver.net/en/  (jeremy@baymoo.org)

3) My personal website: http://simon.baymoo.org/~jeremy/pgp-key.asc

This guide assumes that you have already received your Voting Key and the
message that accompanies it, which describes how to format your vote and
where to send it for this election.


Why Vote Anonymously?


As a voting member of the NetBSD foundation you are entitled, but not
required, to vote for the NetBSD board in a manner which makes your vote
anonymous.  As an anonymous voter your vote is counted equally as any
other vote; there is no penalty for voting anonymously.  Additionally, the
choice to vote anonymously is a personal one; there are no technical
reasons which require it.

This guide outlines two methods for sending your vote anonymously if you
so choose: remailer-based anonymous e-mail, and web-based anonymous
e-mail.




1. Remailer-based Anonymous E-mail
==================================




Remailer-based anonymous e-mail is sent by sending e-mail messages through
a chain of independently operated "remailers" hosted by volunteers on the
Internet.  When used correctly, remailer-based anonymous e-mail can assure
your anonymity quite well even if one or more of the remailers in the
chain are intent on revealing your identity.

There are two popular remailer protocols in use.  The first and oldest is
the Cypherpunk remailer protocol, which is the easiest protocol to adopt
by hand.  The second and newer protocol is Mixmaster, which requires
specialized client software due to its binary format.  The (relative) ease
of using Cypherpunk is pitted against the added security of Mixmaster.
(Mixmaster is more resistant to traffic analysis.)

Since the Cypherpunk protocol does not require a specialized client to use
and the privacy needed for this election arguably does not hinge on life
or death, we will only describe the Cypherpunk protocol in this document.
Do not let the absence of instructions dissuade you from using Mixmaster
if you so wish.


The Cypherpunk Remailer Protocol


The Cypherpunk remailer protocol is an entirely ASCII-based protocol
composed of easy-to-read RFC822 e-mail messages.  To send an anonymous
e-mail message using the Cypherpunk protocol you choose a remailer chain,
compose and encrypt your message, and send it to the first mailer in your
chosen chain.


1.1 Choosing a Remailer Chain
-----------------------------

The anonymity that your receive when using the Cypherpunk remailer
protocol is based on your careful creation of a list of remailers that you
select to deliver your message.  We will call this list of remailers the
"remailer chain" because that is what is resembles.

1.1.1 Constructing the Chain

To construct the chain, create a list of remailers by selecting them from
a public remailer list (found below).  There is a balance you must achieve
when constructing your list: delivery assurance vs. security.  If you
choose too many remailers you run the risk that one of them is not be
operating, and hence, your message will not be delivered at all.  If you
choose too few, you run the risk that your message may not remain
anonymous.

1.1.2 How many Remailers is Practical?

What's a practical number of remailers to use for NetBSD board election
votes? Since your life is probably not in danger if your identity is
revealed during the voting process, and the value of revealing your
identity is intrinsically low, a list of two or three remailers is probably
more than sufficient.

(Security Side-bar)

        The security of the Cypherpunks remailer protocol derives from the
        trustworthiness of the mailers in your remailer chain.  Theoretically,
        your message will remain anonymous so long as at least one remailer
        in your chain is trustworthy (that is, it does not divulge your
        identity nor keep records that would allow it to divulge your identity
        in the future).

1.1.3 Choosing Remailers

A good list of public remailers supporting the Cypherpunk protocol can be
found at:

http://anon.efga.org/Remailers/TypeIList

The list found on that page may appear strangely formatted at first.
There are two keys to deciphering it.  First, each remailer has chosen an
informal nickname for itself (such as 'freaky', or 'cthulu').  Second,
each remailer may support several remailing protocols and features.
Choose remailers that:

1) Support the 'cpunk' (Cypherpunk Protocol) option.
2) Have a good response time.  (Found at the bottom of the page).


1.2 Obtaining Remailer PGP Keys
-------------------------------

Once you have chosen your desired remailer chain you are ready to obtain
the PGP keys of each remailer.  Do so by sending an empty bodied message
to each remailer with a subject line of 'remailer-key'.

To: <remailer-address>
Subject: remailer-key

In a short while, you will receive the remailer's public PGP key.  Save
this PGP key and add it to your public key-ring.


1.3 Composing and Sending the Message
-------------------------------------

Once you have chosen your remailer chain and obtained the public PGP keys
for each remailer, you are ready to compose your message.  To compose your
message you will follow an iterative process of encryption and header
adjustment. In the end, you will have a PGP message constructed of several
layers of remailing commands and further PGP messages.

Since this most important step of the mailing process can be cumbersome to
execute and easy to screw up, I will illustrate its execution in two ways
-- first, as step by step instructions written from the perspective of an
e-mail sender, and second from the perspective of a Cypherpunks remailer
itself. It may be helpful to read both perspectives to gain a clear
understanding of the process.  In doing so you will be less likely to
botch your request by encrypting it with the wrong key in the wrong step,
or misplacing a crucial remailer header, for example.

                          SENDER'S PERSPECTIVE


1.3.1 Compose the Message (your NetBSD vote)

First, create an ASCII file with your anonymous message.  (In this case,
your vote electing or declining the board slate).  Don't include any
e-mail headers in this message; just treat it as though it were a message
body.  Example:

  =========================================
  Voting Key: a017c7934cd55f3772964af995c7aee8
  Confirmation Code: c12b179e0174681539f53695f315863a
  Vote: approve
  =========================================

1.3.2 Encrypt the Message With the Validator's Key

Next, PGP encrypt the message with the vote validator's public PGP key.
(GnuPG example:)

  % gpg -ear valitator@address vote.txt
  (file vote.txt.asc created)

Now you are ready to begin the iteration process.  In the steps below, the
variable 'next-recipient' is initially set to the vote validator's e-mail
address.

1.3.3 Add Remailer Headers, Encrypt, Repeat

Now you are ready for the most tedious part of the remailer process:
iteratively encrypting and adding commands to your message so that it will
be sent through the remailer chain.  In this step we assume that you have
already obtained the PGP keys for each remailer in your chain and that you
have created the message you wish to send in a file named 'vote.txt.asc'.

You will work this process BACKWARDS through the list of remailers in your
remailer chain.  In the steps below, the variable 'current-remailer'
refers initially to the LAST remailer in your chain (since you are working
backwards). As you progress through the steps, 'current-remailer' will
take on progressively earlier remailers in the chain.

1) Add a resend request header.

   Take the PGP encrypted message assembled from the previous step and add
   a resend request header, and a PGP decrypt command.  The resend request
   header directs the remailer to anonymously pass the remainder of the
   message to the recipient listed, and the PGP decrypt command directs
   the recipient to decrypt the message when it arrives.  An example of
   these headers and commands follows.

   (Remailer request to next-recipient)
   =========================================
   Request-Remailing-To: <next-recipient>

   ::
   Encrypted: PGP

   ---BEGIN ENCRYPTED MESSAGE---
   .......................
   ---END ENCRYPTED MESSAGE---
   =========================================

   (Note: if the 'next-recipient' is the vote validator you needn't include
    the '::' and 'Encrypted: PGP' commands.  The validator, being at least
    not a remailer, understands that the contents of the message
    implicitly need decrypting).

2) Encrypt the resulting request with current-remailer's public PGP key.
   (GnuPG example:)

     % gpg -ear remailer@address vote.txt.asc
     (file vote.txt.asc.asc created)

   (Request, encrypted with current-remailer's public PGP key)
   =========================================
   ---BEGIN ENCRYPTED MESSAGE---
   .......................
   ---END ENCRYPTED MESSAGE---
   =========================================

3) Advance remailers.  Make 'next-recipient' be the current-remailer's
   e-mail address.  Then make 'current-remailer' be the next remailer in
   your chain (working backwards).

   Have you exhausted the remailer list at this point?  (That is, is
   there no 'current-remailer' left?)  If you HAVE NOT exhausted your
   remailer list, take the encrypted text from the last step and go to
   [step 1].

   If you HAVE exhausted your remailer list, tack on a decrypt command
   to the message and send it to the e-mail address of the first remailer
   in your chain.  You are done!

   (Final step.  Message to first remailer)
   =========================================
   ::
   Encrypted: PGP

   ---BEGIN ENCRYPTED MESSAGE---
   .......................
   ---END ENCRYPTED MESSAGE---
   =========================================


                          REMAILER'S PERSPECTIVE


1.3.4  Cypherpunk Message Format

If the steps in the previous section seemed confusing, it may help you to
read this section.  In it we present the view the remailing process from
the perspective of a single Cypherpunk remailer as it processes an
anonymous message.  The first step in relating to this perspective is to
understand the Cypherpunks format.

1.3.4.1 Reception and First Stage Processing

Example received message:
=========================================
Received: from host1.domain1.tld (host1.domain1.tld [300.300.300.300])
        by host2.domain2.tld (8.12.3/8.12.3) with ESMTP id g7JHtIkf092872
        for <remailer@host2>; Mon, 19 Aug 2002 10:55:19 -0700 (PDT)
        (envelope-from remailer@host1)
Date: Mon, 19 Aug 2002 10:55:02 -0700 (PDT)
From: Anonymous entity <remailer@host1>
To: Anonymous remailer <remailer@host2>
Message-Id: <20020819105448.F97306-100000@host1>

::
Encrypted: PGP

---BEGIN ENCRYPTED MESSAGE---
.............................
---END ENCRYPTED MESSAGE---
=========================================

Upon receipt of an e-mail message, a Cypherpunks remailer first takes the
RFC822 headers of the message and THROWS THEM AWAY.  This leaves the
remaining message body (if present at all).

After first stage processing:
=========================================
::
Encrypted: PGP

---BEGIN ENCRYPTED MESSAGE---
.............................
---END ENCRYPTED MESSAGE---
=========================================

1.3.4.2 Command Scan

This remaining message body is then scanned for one of two items. First,
it is checked for further RFC822-style headers (such as
'Request-Remailing-To'.)  If no RFC822-style headers are found, the
remailer then scans for a double colon ('::') line, which signifies the
beginning of remailer commands.

There are several remailer commands, but the two most important are the
'Anon-To:' and the 'Encrypted: PGP' commands.  The Anon-To command directs
the remailer to forward the remainder of the message on to the specified
address.  The Encrypted command, on the other hand, directs the remailer
to decrypt the remainder of the message with its own public PGP key.  The
resulting plaintext message is then recursively processed as above. (Note:
The 'Request-Remailing-To' HEADER and the 'Anon-To' COMMAND accomplish the
same task.  Only one or the other is needed).

1.3.4.3 PGP Decryption

Let us continue the example message above by pretending that the encrypted
message contained in the request above was decoded and revealed the
following plaintext:

Plaintext of encrypted message:
=========================================
Request-Remailing-To: <remailer@host3>

::
Encrypted: PGP

---BEGIN ENCRYPTED MESSAGE2---
..............................
---END ENCRYPTED MESSAGE2---
=========================================

The remailer processes this message using the same criteria in steps
1.3.4.2 and 1.3.4.3.  Specifically, this message contains an RFC822-style
header 'Request-Remailing-To' and that header appears before any blank
lines in the message.  Therefore, it is obeyed.  All command scanning
stops and the remainder of the message is mailed anonymously to
<remailer@host3>.

Let's also illustrate another possible plaintext.  This plaintext
accomplishes the same task, but instead of using the
'Request-Remailing-To' HEADER, it uses the 'Anon-To' COMMAND.

Another valid plaintext of encrypted message:
=========================================

::
Anon-To: <remailer@host3>

::
Encrypted: PGP

---BEGIN ENCRYPTED MESSAGE2---
..............................
---END ENCRYPTED MESSAGE2---
=========================================

When processed, this example message has a BLANK LINE as the first line
in the message.  This indicates to the remailer that there are no RFC822-style
headers in the message.  Therefore, the remailer continues scanning the message
until it reaches the first double colon mark ('::') on the second line.
The remailer then interprets the 'Anon-To' command and mails the remainder
of the message anonymously to <remailer@host3>.

In both of these examples ENCRYPTED MESSAGE 2 presumably contains further
encrypted instructions and messages to be consumed by the next remailer
in the chain.



2. Web-based Anonymous E-mail
=============================



If you dislike the hassle of preparing a properly formatted Cypherpunk
chained-remailer message and are willing to settle for less assurance of
anonymity, you might choose to use a web-based anonymous remailer.  Two
are listed below.

https://riot.EU.org/anon/remailer.html
http://www.no-id.com/remail.cgi

The decreased assurance of anonymity in using such remailers is that they
cannot be chained.



3. Conclusion
=============



Whichever method you choose to make your vote anonymous (even if you choose
none at all!), please exercise your right to vote!

Thank you,
The 2002 NetBSD Board Election Vote Validator