ATHENS- Anonymous Town Hall Encrypting Network System

Chaotic but Democratic.

You will need SSLeay and the other components from ciphercopia to make
the program work, and multicast routing (like mbone) for a wide area
anonymizing network.

READ THE TODO FILE FOR MORE INFO

Using UDP multicast, it creates an anonymous broadcast system so that
messages may be passed between nodes on a network (including an mbone
type link using mrouted) without any node being able to determine the
originating node.  Public keys are distributed (after the initial
setup) using the same anonymous broadcast so the identity of the owner
of a key will not be knowable.

The program currently runs only on i386 and Alpha Linux, and under
FreeBSD using Linux Binaries.  Note that you must set up a multicast
route (e.g. "route add 224.0.0.0 netmask 240.0.0.0 dev eth0" for linux
< "2.1.78, ip route add 224.0.0.0/4 dev eth0" for 2.1.78+, and "route
add 224.0.0.0 -netmask 240.0.0.0 -interface ep0" for FreeBSD,
adjusting the device names for your ethernet or other cards as needed)

Note that it will compile and operate under FreeBSD, but there is a
much smaller limit on the size of atomic UDP packets - 9250 is over
the limit, so it will fail unless you reduce the pad and message
sizes.

uudecode the dh_params.* and copy or link to dh_params for a test, or
use the make

FOR BEGINNERS

I seal an envelope with a blank page and carbon paper such that
writing on top of the envelope will create a message.  On the outside,
I place a group of post-it notes with a list of coworker, but with my
name on the bottom (maybe with some blanks after so it won't be
obvious).  Then I take the envelope to the first person on the list.
He pulls off his name, maybe writes a message, and gives it to the
second.  Eventually it gets back, so I open the envelope.  If the page
is blank, no one wrote a message.  If it is unintelligable, multiple
people wrote on it, and I discard it.  Otherwise I post it on a
bulletin board.  I can't tell who wrote the message, except that it
was someone on the list.

Or, Imagine lots of people in a circle facing outward, each writes a
codebook.  Everyone throws the codebooks over their shoulders onto a
pile which is mixed.  Then if I need to send a message, I get a
codebook and start shouting words.  Only one person would be able to
decode my message.  They can either say the plaintext, or reencode it.

OPERATIONAL OVERVIEW:

Alice creates a random pad - it could be blackbody noise, but will
likely use a cryptographic random number generator.

Then she creates a random pathway encrypting each intermediate
destination with the public key of the next hop, e.g. "Carol" is
encrypted with Bob's key, "Dave" is encrypted with Carol's key, and
"Alice" is encrypted with Dave's key.  The message will be initially
sent to Bob.  Note that each hop is simply an encrypted string only
the destination can see, so Dave will route back to Alice, but won't
be able to tell that it is an endpoint.  Alice finally encodes a tag
encrypted with her own key so she will know when the pad comes back.

Alice encrypts the pad and whole path to Bob (using a conventional key
and a public key header Bob can decrypt).

Bob receives the packet and decrypts the pad and path.  He then looks
inside the path for a destination he can decrypt, and finds "Carol".
He encrypts the pad (just like Alice did) and sends it to Carol.

Carol repeats, sending to Dave, and Dave repeats sending to Alice.

If Bob, Carol, or Dave want to send a message, they XOR it with the
pad before encrypting it to the destination.

Alice takes the original random pad and XORs it with the message pad.
If no one had a message to send, it will be all zeros.  If more than
one message is there, it will fail a checksum test and be discarded.
If just one message was added, it will pass and be broadcast to
everyone.

Alice cannot determine who sent the message since she cannot decrypt
the intermediate encrypted packets.  Neither can anyone else determine
if a message is there or the content (if Alice's pad is really
random).

After a while, Alice generates a new key and transmits it using one of
the anonymous pads going around.  After a while, Alice drops the key
identified as hers, so she now has a pseudonymous key which every node
knows, but no one knows which node processes the messages (but would
require digital mixing of the broadcasts since if a broadcast from A
is followed by broadcast from B without any other traffic, you know
the message was from A to B.  With the multiple pads going around
there should be a lot of noise to hide in, but this needs further
analysis.

Alice can then send a message to one of the pseudonymous keys by
simply encrypting a message with it and broadcasting it.

Alice then generates a local message keypair.  She uses a pad to send
the key and a request to encrypted to an anonymous host who executes
the command, encrypts the result with the provided key and sends it
out using another pad.  So the origin and the processing site are
separated from the broadcast sites that send the data.

Alice won't know who processed the request, and the person who
processed the request won't know the result is for Alice.

*** LATE NEWS ***

There is a problem if Bob creates two keys, condider:

Alice -> Bob1 -> Carol -> Bob2 -> Alice

Bob can tell if Carol wrote a message, what it is, and force a collision.

Instead of purely random pads, Alice appends a conventional cypher key
to each hop.  She uses the conventional cypher on a series of zeroed
buffers and XORs the buffers together.  Each hop decrypts one of these
conventional keys, decrypts a zero field, and XORs the result with the
pad.  The return hop will do a final XOR and will either be blank (all
will cancel), or have the message or collision.  If Bob cannot get
Carol's XOR key, he cannot determine if a message has been added.

KEY MANAGEMENT

Before any systems are up, public keys are broadcast directly with an
identifying header, and an initial hosthame - they only need to be
different.  I assume the source of a broadcast can be determined, so
it can't be anonymous at this point.

After keys are received, a nontrivial path can be created, and the
first pad is generated, however other pads can be received (as other
nodes have heard our key broadcast and created pads using it).  These
other pads can be used to send anonymous messages.

When there are enough keys available, public keys are sent in
encrypted form (via pads to an unknown forwarding site).

After a few minutes, a second key will be generated and sent via a
message (so the node corresponding to the key will not be known, nor
the transmission time).  This key will only be sent via pads.

Both keys will be rotated after a few hours, faster if the key was
broadcast as plaintext.

A local message keypair will be generated and rotated every 30 minutes.

INTERNALS

Key management is done by the keymgmt shell script which reads piped
filenames of received public key packets and generated secret keys.
It appends them to the keyring and updates the key status files.

The program starts by setting up and opening the multicast socket.

It then spawns the public key broadcast tasks.  This looks for key
files, and if they don't exist, generates a new key.  It also attempts
to broadcast to an unknown forward address if it has received enough
keys by the time it is ready, and will initially delay to allow for
this to happen.

Next it spawns the pad generators, which simply check if the pad file
exists (or has existed for too long), and generates and sends a new
one as needed.  The generator simply waits for a quorum (minimal
number of hosts) and a secret key, generates a pad, and sends it.

Finally it listens for broadcasts, and forks a process to handle it
(actually the child process waits for the next message and the parent
handles the received message).

Most pads are destined for someone else and are discarded.
Public Keys and results are handled by writing out a file (and
signalling the key manager as needed).  Pads are decrypted and either
forwarded or are a return, which matches it with the pad to see if
there is any message.

The tell program will encrypt (and optionally broadcast) a file to a
pseudonymous key on the actv list (pseudonymous check not yet used).
If not compiled for immediate broadcast, it will be set as a message
to be sent via the anonymous pad.  Either way, the message will be
requeued by the receiver to be sent on a(nother) pad and broadcast.
This will be integrated and disappear.

athmsg are variants of tell set up to transmit commands and results.

If the returned message is encrypted to a "local" key, it is written
out as LOCAL.<pid>, and the keymanager gunzips it and prints a
message.  If the message is a command, the key and command are
separated, and the keymanager is sent the name of the files to
process.

ANONYMOUS BROWSING DEMO

The current system is set up to do simple anonymous browsing

The demo requires geturl from the edssl directory.

anonbrws.sh contains a script and takes a URL as a parameter.  Note
this is insecure since it can be pointed at a "what can we find out"
page, but that can also be used to show the system works.  Edit
keymgmt so geturl goes through www.anonymizer.com.

===========================================================================

Scatter/Gather

scatter filename will break a file into chunks, named with 8 hex
digits and a sequence number.

Gather will take stdin input and write a file with the reconstructed 8
hex digits and sequence:

cat RESULT.123 | gather

will write out ABCD1234.003 if it is the third piece of ABCD1234.

Gather can also reconstruct the original file, i.e.

cat ABCD1234.* | gather final

will write what it can to result.out and return a nonzero entry if
anything is missing - read the source for detailed return values.

"gather test" will attempt reconstruction but not write out the
result, only test if anything is missing.
