CDR: RE: Anonymous Remailers cpunk

[Trei, Peter]

Jim:

This is the last time I'm going to respond to you on this
topic. Everyone else understands my point, and there's
a limit to how much effort I'm going to go to correct a
single obtuse individual.

> ----------
> Jim Choate[SMTP:ravage at einstein.ssz.com] wrote
> On Fri, 13 Oct 2000, Trei, Peter wrote:
> 
> > A spammer (or your spammer's proxy) is not going to 
> > individually encrypt messages to thousands or
> > millions of end-recipients, each with their own public
> > key - the time factor makes this uneconomical, and 
> > the hassle factor of finding all the recipient public 
> > keys makes it impractical. Thus, only remailers 
> > which send out plaintext are useful to spammers
> > as exit remailers.
> 
> 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?...
> 
$50 is nothing, of course. Requiring that each message to 
be encrypted with the final recipient's public key is far
from nothing. Sending 10^5 emails without encryption is trivial. 
Encrypting 10^5 emails is far from trivial. We're raising 
the cost to the spammer far more than we're adding to the 
effort of the remailer operator. You speak of gatewaying - 
who exactly is going to set up a free gateway to encrypt 
10^5 messages, each to a different public key? All that 
does is shift the cost to the gatewayer; it does not 
eliminate it. 

> > 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.
> 
Jim: go back to the genesis of this 
thread. The discussion was along the lines of "There are
too few remailers. Why?"

Among of the reasons cited are that remailer operators 
often get shut down by their ISPs or network poviders 
because of complaints from end recipients of messages -
they get spam, threats, illegal material, etc. It does
not matter that the remailer keeps no logs; the end
recipients mail server does, and that's enough for the
recipient's ISP (or the LEAs) to take action.

This situation not only gets remailers shut down; it
discourages people from starting them in the first 
place. My proposal makes using the remailer for
spam economically prohibitive, and ensures that
the only recipients are crypto-aware types, who are
far less likely to misunderstand what's going on
than J. Random Luser.

> > 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.
> 
There you go again... Please read the thread. The goal
is not to 'stop spammers'. It's to 'Stop actions against 
remailers, some of which are caused by their 
misuse as spam conduits'. Preventing spam from exiting 
the remailers achieves that goal. 

> In addition, there are aspects of remailer operation that make the
> complaints about spam pretty irrelevant.
> 
> > 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.
> 
That's true. The use of doomed (since they'll be dropped 
before they leave the network) spam messages as cover 
traffic is something that occured to me as I wrote the 
letter. It is a nice side effect of my proposal, as
long as spammers continue to send doomed spam into the
system.

> Where's the key management mechanism to ensure the security of the traffic
> in the reamiler network?
> 
Same as it always was.

> > Steve understands this, as does every one else but
> > you. 
> > 
> > What's the problem?
> 
> It's your problem, there are aspects of this proposal that are simply
> silly, and several others that haven't been adequately explained or
> examined.
> 
> You talk about decreasing the load due to spam, and don't even recognize
> that you've replaced it with a whole other process. One that potentialy
> could be more complicated, error prone, and expensive in time and resource
> impact than the original 'problem'.
> 
No Jim, I'm not talking about decreasing the load due to 
spam. I'm talking about making life easier for remailer 
operators. In the long run, it'll reduce spam as well, 
since spammers will learn not to include remailers which send
only encrypted mail in their remailer chains. 

> The solution to bad speech is more speech, not regulation. And don't kid
> yourself that setting up such a mechanism isn't regulatory.
> 
A remailer operator can operate his remailer in any way 
he or she wants, and so long as they publish their policies
and adhere to them, there is no basis for anyone to 
criticize them (this is a thing called 'freedom').

> > Any remailer operator can decide not to pass along plaintext. So long as
> the
> > message sender is aware of this property, nothing more needs to be
> > distributed.
> > There are no increased sysadmin issues.
> 
> What algorithm are you proposing to identify plain-text? There are key
> managment issues, what is your proposal for this problem? There is the
> increased complication of admining the box (think of resources to support
> both the remailer operation as well as the encryption - consider that
> scale carefuly).
> 
> 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?
> 
Jim: I think I'm beginning to appreciate the depth of 
your lack of comprehension.

Remailers do not encrypt anything. All the encryption 
steps are done by the originator of the message - 
successively encrypting the message with public
key of the recipient (an optional step in current
remailers), and then by the public key of each remailer 
in the chain working back to the originator.

Each remailer decrypts the message with it's private key,
All it knows is to send the inner contents on to the next 
remailer in the chain, or to the final recipient. This is 
how remailer chaining works today.

The only change I propose is that, if after applying it's
own public key to decrypt a message, the remailer notices
that the decrypted material does not match one of the well
known formats for encrypted messages (ie, it is likely
plaintext), that it drop the message. I won't discuss the
recognition algorithm here, since I have already done so
and others have even published sample code. It can be done.

> > No, there is not, beyond the fact that the message originator must know
> the 
> > final recipient's public key.
> 
> You need the key to get into the remailer, otherwise how does it tell the
> message is encrypted? You seriosly propose sticking some static PGP header
> for example will stop anyone, spammers know how to use word processors too
> you know.
> 
> > Jim, do you really understand how remailer chaining works?
> 
> Yep. Apparently better than you do.
> 
> Have a nice day you pretentious butthead.
> 
ROTFLMAO

> James Choate
> 
Peter Trei