From: Adam Back <aba@dcs.ex.ac.uk>
Date: Wed, 23 Oct 1996 12:08:16 -0700 (PDT)
To: aba@dcs.ex.ac.uk
Subject: Re: [fwd] Implementing the anonymous.net domain
In-Reply-To: <199610230044.BAA00594@server.test.net>
Message-ID: <199610230050.BAA00601@server.test.net>
MIME-Version: 1.0
Content-Type: text/plain



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`