CDR: Re: Anonymous Remailers cpunk

[Bill Stewart]

I've reordered several sections of the discussion.

At 07:18 PM 10/13/00 -0500, Jim Choate wrote:
> On Fri, 13 Oct 2000, Trei, Peter wrote:
> > It is only exit remailers (ie, the remailer which sends
> > to the final recipient) which get hassled for sending spam.
>And it has NOTHING to do with the encryption.
>The lack of log's is what prevents back tracing.

Back tracing is only necessary if They weren't eavesdropping
in the first place.   Remember that the goal of remailers
is to prevent serious attackers from tracing traffic,
not just to prevent complainers from succeeding.
If you allow unencrypted incoming traffic, you lose.
If you allow unencrypted outgoing traffic, you also lose,
unless the destination is a public Usenet forwarder or something.
The only unencrypted email you should be delivering to
normal recipients is something like
	"Hi!  An anonymous person who you know wants
	to send you a secret message.  Get PGP at www.pgp.com
	and publish your keys"

Eric Hughes and Raph Levien did some work a few years ago
indicating that message sizes may be enough to analyze
traffic flows in a Type I remailer network anyway -
you need to go with Mixmaster or maybe even Pipenets for security.

Of course, no Bad Guy would *ever* think of eavesdropping the
PGP.com or MIT keyservers to do traffic analysis on key requests.

>> A spammer (or your spammer's proxy) is not going to 
>> individually encrypt messages to thousands or
...
>They do it now, sans encryption. The mass distribution is what makes it
>economical. If the encryption can be gateway'ed then it's useless and
>doesn't raise the cost significantly.
>A more useful mechanism would be to distribute the keys and appropriate
>client software to spammers. What's a flat $50?...

If the spammer can get a gateway to do the work of fetching keys
and encrypting messages for millions of spam targets,
the gateway is probably toast for a few weeks anyway.
Remember that the spammer has all the time they want for
pre-computation - they're only vulnerable once they start
sending out mass quantities of messages.
(On the other hand, what spammers do lack is clues and creativity.)

It used to be possible to extract keys from the PGP keyservers,
which meant that a low-tech spammer could nab 5-20000 email addresses
and a high-tech spammer could also nab that many crypto keys.
I've heard people say there are over a million keys in the 
current LDAP servers; I haven't explored whether it's easy to
bulk extract them (e.g. query on "email address includes '@'".)

If you wanted to build a custom crypto-spamware for this volume,
you've got a few advantages over vanilla PGP.
The bulk of the mail message is the same for everybody,
so there's no need to encrypt the body multiple times -
just encrypt it once and use the same symmetric key for each,
and only do the public-key part separately for each target.

If there are message parts that do change, e.g. the
encrypted part contains the "Request-Remailing-To: target37 at wherever.com"
and the remailer doesn't enforce encrypted-outgoing-only,
you can still make it work by exploiting CBC's self-synchronization.
Set up the message so the variable line is padded to a
whole number of cypher blocks (e.g. N*8 byte) ending with two of
whichever Carriage Return/Linefeed you need,
then two more blocks of disposable junk, then more real text
(again, probably starting with CR/LF), and the CBC will misdecrypt the
disposable blocks but sync up again afterwords.  Ugly, but shouldn't
be particularly destructive, if you can survive the occasional unprintables.
This lets you only do hard work for the public-key encryption
and the symmetric-key parts that surround it, without having
to do symmetric-key encryption on the whole message every time.

It's much tougher to pull this off for something
that needs to create good cyphertext as its output,
so it's much tougher to trick remailers with encrypted-outgoing-only.
You at least have to duplicate encryption for more PGP header,
but you might be able to get past it into the message body safely.
If you're doing a long spam, it may still be worthwhile,
though if all you're sending is two blinking multicolored lines of
	Get your RED-HOT SPAM HERE http://www.spam-monger.com/
you probably weren't creative enough to have done this much work :-)


>> The goal is to make remailer operators life easier by
>> preventing them from being used to spam random
>> lusers, who may initiate complaints against the
>> remailer operator.
>
>No, the goal is to stop spammers.
>In addition, there are aspects of remailer operation that make the
>complaints about spam pretty irrelevant.

There are two problems - spammers and harassers.   
The prevalent cypherpunks remailer attitudes toward spammers
seems to be keeping them from overwhelming your resources
and making sure complaints about spam go to /dev/null or the
apology autoresponder instead of your real mailbox,
but more serious harassers can get you shut down faster.
A harassment apology autoresponder helps a bit,
but encrypted-only-outgoing radically reduces the threat,
and keeps most of the spammers abusing other people.

If you're running your own Tier 1 ISP, and you host Spamford,
you can become the next Dead AGIS, but it takes a *lot* of complaint.
If you're running your own small ISP, you're relatively safe,
but enough complaints can get your Tier 1 upstreams to drop you.
But if you're just a customer, your ISP may have some tolerance level
but a determined abuser can still get you shut down.


>> It is not to prevent spam passing through a remailer
>> somewhere in mid-cloud. While such encrypted
>> spam will increase the volume of traffic, for most
>> remailers that is a Good Thing - more material to
>> confuse the traffic analysis. As long as it gets 
>> dropped before leaving the remailer network, no
>> harm is done.
>
>Nobody said anything about the interim processing until now. 
>How is this relevant to the 'free speech' aspect of requiring 
>the use of particular forms of encryption end-to-end.

Middleman remailers don't get complaints except about 
resource utilization - Peter had addressed the issue that
exit remailers need some protection from spam complaints,
but for middle remailers you just don't need to worry.
(You still need encrypted outgoing for security,
but if your output only goes to remailers that enforce
encrypted incoming you don't need to implement anything yourself,
though it doesn't hurt you.)


>I'm in Zimbabwe and the remailer is in the US, how do I manage the keys to
>enter the network in such a way that it is secure?

PGP web of trust works fine, just a bit slower from there.
				Thanks! 
					Bill
Bill Stewart, bill.stewart at pobox.com
PGP Fingerprint D454 E202 CBC8 40BF  3C85 B884 0ABE 4639