Other Directory Sites: SeekWonder | Directory Owners Forum
The following archive was created by hippie-mail 7.98617-22 on Fri Aug 21 1998 - 17:15:55 ADT
antispam-tzeruch@ceddec.com
Wed, 4 Mar 1998 17:18:53 -0500
I have been working on a system that uses encrypted broadcasts to create
anonymity. I now have it working to the point it can use an anonymous
node to retrieve a URL (I can't know which node did the retrieval, and
the far node can't know I am the recipient).
If anyone is interested, I have an archive with the alpha version, i386
Linux only, and after it is a little more stable it should end up on
www.cryptography.org (since I am in the US, requests should include a
statement that the person is a US or Canadian Citizen in the US or
Canada). Also remove the antispam- prefix if you reply
The current README follows and describes generally how it works.
---------------------------------------------
ATHENS- Anonymous Town Hall Encrypted 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 Linux.
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 broadcasts the key
and a request to encrypted to an anonymous host who executes the
command, encrypts the result with the provided key and broadcasts it.
Alice won't know who processed the request, and the person who
processed the request won't know the result is for Alice.
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.
tellint and tellocal 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
The current system is set up to do simple anonymous browsing
The demo requires geturl from the edssl directory.
echo "http://www.netscape.com" >x.url # save text to a url
tellint x.url # queue a message to an unknown host
...wait for a message like:
LOCAL.12345 has arrived
This file will contain the hypertext from the URL.
===========================================================================
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.
The following archive was created by hippie-mail 7.98617-22 on Fri Aug 21 1998 - 17:15:55 ADT