[fwd] Implementing the anonymous.net domain

John Gilmore posted this on coderpunks, the response seems
underwhelming (only one response so far).  Looks interesting, and I
think a cool replacement for penet.  I'd be interested to see any
comments on practical implementations for this.

-Adam

Forwarded message:
======================================================================
To: coderpunks@toad.com
From: John Gilmore <gnu@toad.com>
Subject: Implementing the anonymous.net domain
Date: Sun, 20 Oct 1996 18:33:15 -0700

I'm looking for a project leader and a team who will take on the job
of making a working cryptographic "anonymous.net" domain.

I'm looking for software that would permit mail to be anonymized with
a return address like:

    lkjasdflkjaslkdjfhakjshdfokiuhasdouilkjasdflkjasdfkjl@anonymous.net

which would permit a reply to reach the originator by some secure
chain of remailers (I'm not interested in an implementation that
includes a Julf-like database).  This would require at least two
pieces of software:

	*  Something to anonymize mail and put in that return address
	*  Something to run on the anonymous.net server machines to
	   read the address, and remail the mail.

Additional subdomains can be allocated for other services, e.g.
web.anonymous.net, julfmail.anonymous.net, news.anonymous.net,
digicash.anonymous.net, etc.  These are particularly valuable when
multiple machines around the world can provide identical, replicated
service.

Current email and packet delivery protocols (A records and MX records)
permit us to offer a large set of potential machines to which
anonymous email would be delivered, at random, all under the same
domain name.  Each of these machines would have to be able to properly
route mail for any email address in the anonymous.net domain.  This
would avoid denial of service by shutting down any particular remailer
machine, as long as at least one advertised remailer remained up.  The
domain records themselves (for anonymous.net), which list the set of
advertised remailers, can also be replicated on numerous hosts to make
them harder to censor.

Having replicated, random entry point machines would also make it
harder to trace any specific message unless all the entry point
messages were tapped by an attacker.  The message they care about
might go through some entry point that wasn't tapped.

I'm willing to hold the domain name and defend it, but am too busy
to do any of the protocol design or technical work required.

The InterNIC has billed me for this domain; if we want it, it's time
for a team to step up and build it.  I'll pay the bill if I get a
team, else the domain will go away.  Have a discussion and let me
know.

Thanks,

	John

John Gilmore <gnu@toad.com> writes:
> I'm looking for a project leader and a team who will take on the job
> of making a working cryptographic "anonymous.net" domain.
> 
> I'm looking for software that would permit mail to be anonymized with
> a return address like:
> 
>     lkjasdflkjaslkdjfhakjshdfokiuhasdouilkjasdflkjasdfkjl@anonymous.net

I like the idea of a more secure and resilient replacement for penet.

There are significant design problems to iron out if the result is to
provide good anonymity.

The implementation is tricky to do in a fashion which is secure, fault
tolerant, and scalable.  This would seem to be one of those "pick any
2" type problems where the design criteria conflict.  Perhaps we
should also add low bandwidth requirements for the user, resilience to
DoS (Denial of Service), and resilience to abuse by spammers.

>From the long email addres, were you thinking that the address itself
would contain the encrypted reply?  Encrypted reply blocks get big
even for a few hops, with PGP & type I remailers.

Chaining as a general method for creating reply blocks (such as the
alpha nymserver), is not that secure because a) it's using type I
remailers where messages with differing sizes show through, and b)
it's open to the replay, or flood attack.

Mixmaster has some nice improvements over type I remailers: fixed size
blocks, forward secrecy (not implemented yet), anti replay code.

However the anti-replay code means you can't use it directly for reply
blocks, and if you disabled that feature, you'd be open to the
flooding attack.

Combining mixmaster with message pools seems the most secure current
option.  This does have inconvenience in terms of the bandwidth
requirements of the user -- lots of people have got to download the
whole pool, or have unlogged local access to a newspool, or have a
broadcast newsfeed.  Also it reduces scalability, everyone gets all
messages.

> Additional subdomains can be allocated for other services, e.g.
> web.anonymous.net, julfmail.anonymous.net, news.anonymous.net,
> digicash.anonymous.net, etc.  These are particularly valuable when
> multiple machines around the world can provide identical, replicated
> service.

All nice things, but lets talk about one thing at a time,
anonymous.net email addresses first!

> Current email and packet delivery protocols (A records and MX records)
> permit us to offer a large set of potential machines to which
> anonymous email would be delivered, at random, all under the same
> domain name.  

OK, so you could use multiple DNS entries to pick a machine at
random...

> Each of these machines would have to be able to properly route mail
> for any email address in the anonymous.net domain.  This would avoid
> denial of service by shutting down any particular remailer machine,
> as long as at least one advertised remailer remained up.  

This level of resilience seems to imply that there is only one
remailer key, and that each remailer could decrypt all the remailer
traffic.  This would be as trustworthy as the least trustworthy
remailer.  (That will be the one owned by the NSA front).  Very
resilient but not very secure.

Perhaps you mean instead that the anonymous.net domain replicators do
not do remailing as such, they just provide the anonymous.net address,
and route the message to the appropriate remailer.  If you mean this,
then you have lots of protection for the forwarders, and as long as
one is left your mail gets forwarded to the correct remailer.  However
you still have problems of resilience of the actual remailers, if any
remailer on your chain breaks, so does youre reply block.

You could trade off security for resilience by having multiple reply
blocks.

Another approach may be to secret share a single group remailer
private key.  Have a threshold of remailers needed to decrypt.  Each
remailer part decrypts, and passes on to another remailer, eventually
the remail instruction is decrypted, and the message is sent to the
recipient.  Unfortunately, if the NSA owned remailers ever get
sufficient in proportion the system would be broken whenever an NSA
remailer was chosen as an entry point.  (This assumes you also encrypt
communications between remailers with a remailer specific key, or a DH
negotiated key.)

There are signature schemes which allow signatures to be made with a
secret shared key without revealing the shares.  (Each share holder
adds a partial signature, up to the threshold when a full signature is
generated).  Are there algorithms which can do the same thing for
decrypting, so that we could have remailers adding partial decrypts?
Are there algorithms to generate a public/private key pair such that
no one ever needs to be trusted to do the split without keeping the
key?

Adam
--
Have _you_ exported RSA today?
print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`