OTHER STUFF:

WARNING: there is a debug time shortening at the top of keyhandl.c
that needs to be disabled if computers are to join after startup (It
only speeds up the simultaneous initial start of an athens group, but
will cause problems since new nodes won't have a chance to get all the
keys).

Several settings are for my alpha testing on my computer using the
dummy device or my LAN.

run.athens cleans up files and starts the program.  It will background
after it receives the first message (but will broadcast earlier).

boxstuff.sh creates several INBOX entries - look for each to
eventually form a RESULT entry.

0 contains a prototype directory duplicated by localtest.sh

localstf.sh creates several INBOX entries in the several directories
so while a localtest.sh test is running it should queue them and
return RESULT files.

ringtrim is a shell script that will reconstruct the keyrings to
remove old keys.

revoke.c is a program to create a DSA-signature of the public key.
Running "pgp5sig -s sigfile <pubkey.pkr" will indicate if the signature
is good so that keys can be revoked.

--------------------------------------------------------------
Done: (changes to be tested)
quorumchk now insures our key has been published (and is not stale).
Monitor routines unlink monitored file upon SIGTERM

----------------------
REAL TODO:

Anon Mail system

---

Propogage SIGTERM

Persistent local message keys (pseudonyms) [add to ringtrim]

randomly Forward INTERN messages

merge ringtrim into keymgmt

Better key rotation - overlap

Hash check the packets overall

Randomize packet length

GETENV, athens.cfg files
local maxring minring variables
padlife pkbcast(interval) npads
msgintvl

restartability

---

Add shutdown packet (to delete from actv.out).  Will still need
to wait for a few seconds or minutes for all the pads to flush.
Do I want to remember routes and cancel pads if a shutdown happens for
a host on the route?  DSS signed key revocation.

key revocation

one padmon using stat to find stale pads

-----------------

Problems:

If software can generate a two or three entry pad any message would
then be traceable.  But an extra layer of indirection can be added, so
although the hop can be found to a depth of 1, it may simply be a
forward, and may be indecipherable except by the forward site.  Also
there should be more traffic at the node doing this.

Digital mix or random delay the broadcasts?

How do you rotate keys to insure they aren't trackable (i.e. no key X
disappears at the "same" time key Y appears).

