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`