More on remailers

Ryan Lackey ryan at havenco.com
Sun Dec 23 00:31:43 PST 2001


> 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 at remailer.havenco.com) I've seen that a lot of abuse at 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 at 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





More information about the cypherpunks-legacy mailing list