This is somewhat related to what ZKS did in their version 1 [1,2] mail system. They made a transparent local pop proxy (transparent in that it happened at firewall level, did not have to change your mail client config). In this case they would talk to your real pop server, decrypt the parts (they were reply-block like onions), remove duplicates (as with mixmaster etc you can send duplicates via separate remailers to improve reliability). So the transparent proxy would leave alone your normal mail that you received in the pop box and remove duplicates only from the reply-block delivered pseudonymous mail. Actually they implemented the reply-block from scratch, it always seemed to me it would have been less development work to use mixmaster (it was implemented before I started). The ZKS reply block did not even use chunking (ala mixmaster) so traffic analysis would have been trivial as the message size would show through. At least that's what I recall, no chunking. However I am finding the security issues paper [1] says otherwise. The 1.0 architecture document [2] is ambiguous, there is no mention of chunking. (I've sent mail to one of the original developers to check I have it right). It was also unreliable because it did not use SMTP, it used its own transport AMTP and its own retry-semantics on nodes called MAIPs. (Mail AIPs, an AIP is an "Anonymous Internet Proxy"). Then we implemented a replacement version 2 mail system that I designed. The design is much simpler. With freedom anonymous networking you had anyway a anonymous interactive TCP feature. So we just ran a standard pop box for your nym. Mail would be delivered to it directly (no reply block) for internet senders. Freedom senders would send via anonymous IP again to get sender anonymity. Used qmail as the mail system. Unfortunately they closed down the freedom network pretty soon after psuedonymous mail 2.0 [3] was implemented. There is an interesting trade-off here. The interactive communications are perhaps more vulnerable to real-time powerful adversary traffic analysis than mixmaster style mixed chunked delivery. However they are less vunerable to subpoena because they are forward-secret on a relativey short time-frame. (1/2 hr if I recall; however more recent designs such as chainsaw internal prototype, and cebolla [4] by ex-ZKSer Zach Brown change keys down to second level by using a mix of backward-security based on symmetric key hashing (and deleting previous key) and forward security using DH.) It would be nice to get both types of anonymity, but I suspect for most typical users the discovery / subpeona route is the major danger, and if that is thwarted it is unlikely that their activities would warrant the effort of real time analysis. Well we have carnivore now, so they could potentially do real-time traffic analysis more routinely if they were to distribute enough collaborating analysis carnivore plugins. Adam [1] http://www.homeport.org/~adam/zeroknowledgewhitepapers/security-issues.pdf [2] http://www.homeport.org/~adam/zeroknowledgewhitepapers/arch-notech.pdf [3] http://www.cypherspace.org/adam/pubs/freedom2-mail.pdf [4] http://www.cypherspace.org/cebolla/ On Tue, Jul 06, 2004 at 02:47:43PM -0700, "Hal Finney" wrote:
Recently there was a proposal for a nym receiving service, http://www.freehaven.net/doc/pynchon-gate/, by Bran Cohen and Len Sassaman. They have a complicated protocol for downloading email anonymously. To hide the complexity, they propose to set up a POP compatible mail server agent on the user's computer running as a daemon process (Windows service). He would configure his mailer to connect to localhost:4949 or whatever, just like any other POP server. The service would periodically go out and poll for email using the fancy protocol, but then it would make it available to the local mail agent in perfectly vanilla form. The point is that this architecture hides the complexity and makes it transparent for end users to use arbitrarily complex crypto for mail receiving. Something similar would be perfect for your idea.