OPT: Re: Cypherpunks, Feds, and Pudgyfaced Voyeurism

Wed Apr 11 21:48:25 PDT 2001

You mean like the 'igor' project I mentioned a while back?

I"m accepting suggestions that don't fall into the 'Stick it up your ass'
category. Those you can keep :)

On Wed, 11 Apr 2001, Ray Dillinger wrote:

> Perhaps it is time to consider a new and different mailing 
> list which accepts messages ONLY from remailers.  It would 
> be publicly archived and unmoderated just as cypherpunks is, 
> and monitored by the lions just as cypherpunks is, but now 
> that the thought-crime laws are setting in full force, it 
> could provide a forum where there wouldn't be such a simple 
> evidentiary chain from post to poster. 

igor (v 0.1)
4-11-01

A remailer for Plan 9
by
James Choate
ravage at ssz.com
http://einstein.ssz.com/hangar18

One of the primary values of the Internet is email. It provides a reliable
and consistent link across time and space. It is the proto-typical killer
app. However, to use email effectively there should be two additional
features. We don't promise more don't exist. The first feature is the
ability to reflect or remail a single email to many recipients. The second
is to strip identifying header information from the sender prior to the
subscriber getting it.

igor does not use 'embedded routing commands' like many other anonymous
remailer packages. We believe that tampering or altering the body of the
email is simply wrong. We offer two way to input data into igor. The first
is through Subject: line escaped commands and the second is through
additional header files. An example of each is,

Subject: Some title or other [igor: some_commands, must_come_last]

or,

X-igor: some_commands

This allows the first remailer to strip the command data out and then
process the email as if igor had never been involved. igor supports limited
routing selection, which is intended to make traffic analysis harder. igor
sends individual emails embedded in igor-specific header info to eliminate
as much interaction with the email itself. All inter-igor traffic is
encrypted with PK's managed by the Evil Geniuses.

With respect to key management, I am not a big believer in current
schemes. I don't believe the 'PGP Ring of Trust' is workable because of
scaling problems. What I intend is for each remailer to 'know' only a
small group of other remailers (limited to three for testing, but the
design will support an unlimited number technicaly). So, when igor_1 hands
off to igor_2, all igor_2 knows is that he's k in a n-length chain. He
subtracts one and randomly selects another igor other than igor_1 to send
it to. The remailer igor_2 sends it to, igor_3, will NOT know about igor_1
so it is completely possible that igor_3 may send an email right back to
igor_1 for delivery to the recipient. Provided of course that igor_1 and
igor_3 have had prior communications. The intent, at least in simple
principle, was to allow each key to be 'authorized' to the standards of
each operator. I felt this offered a reasonably strong approach and should
handle scaling well. On the flip sice, if igor_2 sends covor traffic he
won't send it to igor_1 for that mail. I felt that sending igor_1 any sort
of traffic was counter productive unless you always sent traffic back to
the initiator remailer. This seems 'evil' to me. It's a start...

My current problem is deciding what encryption scheme to use for
inter-igor relays...?

Plan 9 is an operating system developed by the fathers of *nix to 'fix'
the problem of *nix. The system has integrated and fully scalable
I/O-authorization kernels, process kernels, and file system kernels. Each
kernel is connected through a authorization mechanism that doesn't send
keys over the network. The low level network layer, Plan 9, is currently
implimented with DES. At some point this should be replaced with something
a tad more stout. It also needs a mechanism to anonymize file and process
space access. Strong crypto is clearly a pre-requisite for this. Once
those features are in place a true 'Data Haven' could be easily
implimented.

Plan 9 is open source and can be obtained from,

http://plan9.bell-labs.com

The only transvestite operating system in existence, and so what if the
bunny is ugly?

Route Commands (ie igor: * * ...):

strip			Strip the From: header
zombie			Strip the From: header and replace with
			From: Walking Dead
route#			Route the message through # other igor nodes,
			not selectable by the user, where # is from 1 to 3.
			route0 is assumed and means send to recipient
			directly
cover			Provide cover traffic for each outbound email by
			sending all know igors a single bogus email.
			This provides n-copy cover traffic.
subscribe $		Subscribe to mailing list $
who $			Who is subscribed to list $?
info $			Provide info on list $
help			Request an info-help file

igor Configuration Parameters (igor.conf):

MyPubKey		This remailers public key, non-traffic related
			encryption key. Used for encrypting traffic or
			data.

MyOwnKey		This remailers private key, non-traffic related
			de-cryption key. Used for decrypting traffic
			or data.

MyPubRing		My public key ring, this contains a mapping of each
			'authorized' igor remailer we will operate with. We
			use this key to encrypt traffic TO the listed
			remailers. There are no line length limits.

			e.g.

			igor at foo.bar#242ds032fdsasetewdvdsasdfewwere...
			igor at bar.org#2303210343203828353234898324397...			
			cypherpunks at ssz.com#23XD24398dDWSc35K2)3C2#d...
			...

MyOwnRing		My private key ring, this contains a mapping of each
			'authorized' igor remailer we will operate with. We
			use this key to decrypt traffic FROM the listed
			remailers.

GHeader: $		Place this at the beginning of all emails through
			this remailer

GFooter: $		Place this at the foot of all emails through this
			remailer

Open: *, *, *, ...	These mailing lists will provide all info to any
			reqeustor

List: *, *, *, ...      These mailing lists will provide info only to a
			current subscriber

Close: *, *, *, ...	These mailing lists will not provide any info

Verify: *, *, *, ...	These mailing lists always verify each operation
			through the Evil Geniuses.

ArchDir $		The archive files should go in the $ directory

Archive: *, *, *, ...	These mailing lists will create an archive file,
			#.arc

User Accounts:

igor - remailer contact account (mail address that executes program)

master - owner of remailer (a person who receives status and such)

undead - another trusted 'igor' remailer

Standard Accounts:

master:some_user:{list of other users}

igor:master:{list of other users}

list_name:igor:{lot of subscribers, a file}

    ____________________________________________________________________

            The ultimate authority...resides in the people alone.

                                             James Madison

       The Armadillo Group       ,::////;::-.          James Choate
       Austin, Tx               /:'///// ``::>/|/      ravage at ssz.com
       www.ssz.com            .',  ||||    `/( e\      512-451-7087
                           -====~~mm-'`-```-mm --'-
    --------------------------------------------------------------------