What do you mean, "no client software"? How do you propose to get secure anonymous mail without client software?

I'm arguing that with less anonymity than the current mixmaster network, but with greater ease of use, you could have superior experiences. Specifically using standard MUAs, like MS Outlook, which include SMTP-TLS and IMAP-SSL; operate as a normal user, with the normal MS-default MUA, connecting to a remotely maintained mailserver which filters attachments, keeps no logs, and is optionally implemented in tamper-resistant hardware with published code. Located in a jurisdiction and a network environment where, provided an AUP is complied with, subpoenas or denial of service are at least as unlikely as shutdown of the aggregate of most major mixmaster remailer nodes today. "Click here for an offshore anonymous mailbox" is a lot easier than reading even a simple description of mixmaster remailer theory. Sheep use it in unencrypted-message, unencrypted-mailbox, pseudonymous, linkable, communicate-via-SSL, download-on-message-receipt mode. Wolves can operate in a way which is indistinguishable to casual observation, but with encrypted message contents, and possibly with redirection via reply-blocks through remailers, or remailed to an address through the remailer network normally, or encrypted and deposited to a web server which also contains mailing list archives in SSL, or to a usenet group with wide distribution. I want something *I* would use, ultimately. I both trust myself not to violate my own privacy, and am lazy on a day to day basis.

2-way communications

Oh, certainly group-mediated communication is interesting -- and the Beale Screamer incident was one of the few highly worthwhile uses of remailers I've seen since running one. I'm concerned that if remailers have only a bad rep, it will be easier to criminalize their operation, and they will be persecuted more by network administrators (rather than operated, or at least benignly ignored) IRC servers are already prohibited on various colo/leased circuits, even though they're legal, due to technical and social issues.. Same with spam. Users won't be drawn to use technology which has a reputation of being used primarily for harrassment; if sending an anonymous message to someone is more likely to have it ignored or otherwise not taken seriously than sending a non-anonymous message. Already (from reading abuse@remailer.havenco.com) I've seen that a lot of abuse@network addresses refuse to act based on messages sent via anonymous remailers. If they were instead sent through a pseudonymous system with some accountability/linkability/cheap-way-to-do-reputation, or indistinguishable from non-remailer mail (by hosting domains and sending under that domain), or a 2-way system where the abuse desk could contact the user making a complaint and interact, they'd be taken more seriously. I'd like anonymous email to accomplish something more than just sending messages anonymously to one another as today; I'd like it to serve as an example of why cryptography, anonymization, and other techniques are things which should be widely supported. For that to happen, someone needs to be able to communicate why it should be used in a convincing way to reporters, show them how to use it, and then convince the mass-market that participating in some way is something they should be doing. "If you support freedom of speech, send anonymous email through mixmaster remailers" is less likely to work than "if you support freedom of speech, make sure your ISP supports "secure (ssl) mail" and click the "use SSL" option in your copy of MS Outlook. SSL for http has done a good thing by getting people to associate crypto and (financial) privacy and security; pushing SSL email could do the same thing for privacy. Recent hassle over 802.11b encryption, open networks, etc. is perhaps an inspiring sign -- once it became widely reported (due initially to pete shipley coming up with a cute name for something he was doing, I think), it became "the cool thing" to use encryption on your 802.11b network; the WEP break notwithstanding, people went from using no crypto to lame-but-better-than-nothing crypto in larger numbers per unit time than I've seen before. I don't really care about privacy for random stupid people as an end in itself, but I need the cover traffic. Rather than making people smarter, I'd rather make the crypto stupider, or at least easier to use poorly. (when ecash happens, this will be even more important, but luckily paying people anonymously and doing unobservable finance is a compelling end-user application, given a good ui)

[email vs. communicating anonymously]

Oh, I certainly agree on this -- I'd love to see a great p2p system which protected privacy while moving *large* files (upper bound, say 1GB DivX movies). Trading pr0n warez DivX is a compelling end-user app. Yet, for these, latency *is not* as serious a concern as human interaction. If I were designing the ultimate p2p system, I'd do: [note: this is a 6 paragraph digression from the topic at hand] * Small fast 2-way anonymous interactive network for sending control information...maybe the lower bound is being able to do 100bps constant-rate to the cloud of actual information, constantly send dummy traffic. * Searches which operate remotely, so you don't need to download index info from every server, just results * High-bandwidth, async, high-latency transport for sending files. Maybe multicast, using a multicast transport. I can do VSAT in US/EU for something like USD 3k/month to broadcast 34Mbps...you could broadcast a stream of random encrypted data and then distribute keys separately after the file is distributed widely. (it's called "Usenet", and there are a bunch of VSAT-based usenet delivery services, a friend of mine used to run one). Just auto-couriering stuff onto rooted servers and publishing the URL over the 2-way anonymous network is probably fine, if the end-user's anonymity is not required. * The ability to do something like say "I want all kiddie porn featuring anal penetration of older than 3 but younger than 6, wearing red t-shirts" and have these files appear over the next 6 months -- "subscribe" to a search, vs. doing a search repeatedly. (Ideally you'd request files in a way where you offer ecash for them...if I want a CD, I might be willing to pay enough to make it worthwhile for someone to purchase, encode, and upload it, then recursive auctions and all that...) (all of these concepts have been discussed or used in various p2p systems...I only mention them as a way to avoid the necessity for a low-latency, high-bandwidth, high-anonymity channel for every single user of a file sharing system) [end digression] I think "email", which I take to mean "15 second to 5 day latency, under 40KB, armored text unidirectional messaging with rfc822 headers prepended, no return receipts or delivery confirmation, best effort, store and forward, delivery-time-uncertain" is a pretty general technology. Unless you're concerned about reliable delivery and receipts, or substantially deviating from anonymous-mix-email's latency/bandwidth regime, I don't see much point in doing anything but email. MTAs don't suck that much these days -- postfix is a lot better at what it does, specifically, than any "cypherpunk" I've ever seen. Building a tolerable p2p system which used *just* mixmaster and rooted cablemodem-hosted boxes would be entirely possible, but pretty boring. Pipenet is very interesting; I'd certainly run few 10Mbps nodes for experimental value. But it would be hard to do cost-recovery on a pipenet except for small (control?) data, or multicast. Until the risks of being identified as an end-user in the warez game are increased to criminal, and the profusion of easily-routed throwaway servers dries up (hah), there won't be a way to charge enough to make it worthwhile for unicast media object transport. Realtime chat, though, would be a killer app for pipenet -- fairly multicast, low bitrate, 512Kbps DSL users could be first-class nodes, "legally compelling" (it's user to user human speech, so courts are less likely to be able to categorically hate on it enough to shut down nodes), lots of users (I'm sure you could get 100k users for the new cool kids IRC replacement, with end to end security, on the fly group creation, less key management/channel management issues than irc, group chat, good clients, ease of installation, etc. with no trouble, and maybe a few million users over time. Add some bots, which can migrate, and it starts to be really interesting.) I'd always assumed all nodes on a pipenet were first-class; if you're talking about a pipenet with leaves, then yeah, you'd want a constant-bitrate channel in. Raph was disliking gale's lack of anonymity; anonymous realtime human-human and group messaging is probably more reasonable than I thought at the time. The unimplemented but academically-interesting alternate mixes proposed would maybe be just as good as a pipenet; ideally you'd be deploying all of these in a framework which allowed different transports, but provided common keying, addressing, and external API. Maybe I've contradicted my earlier argument against interesting new p2p software -- I think for "bread and butter" secure *email* you might as well use a decent SSL mail server with optional ubobservable I/O instead of mixmaster, but for something closer to chat, the new stuff might be interesting. Mixmaster is in the middle ground between the two; it should go to one side of the road or the other.

[ecash needing something other than mail as transport]

If you're doing an ecash system which has >8KB/message and more than, say, 5 exchanges per transaction, you're doing something wrong. And the aforementioned latency/anonymity slider is just as easy to shift on an SMTP based system as on any other protocol as transport. You need protocol-specific cryptographic receipts as part of the protocol anyway (which various values serve as), so really you could just use [encrypted-payload] UDP [multicast], but whatever. I think ecash will ultimately have many transports, but one of them should almost certainly be PGP-encrypted email which looks exactly like any other PGP-encrypted message, back and forth with an ecash server attached directly to a remailer, where every message fits within the remailer standard mail sizing. The pipenet/chatnet solution would probably be suitable for ecash protocol communications as well. -- Ryan Lackey [RL7618 RL5931-RIPE] ryan@havenco.com CTO and Co-founder, HavenCo Ltd. +44 7970 633 277 the free world just milliseconds away http://www.havenco.com/ OpenPGP 4096: B8B8 3D95 F940 9760 C64B DE90 07AD BE07 D2E0 301F