CDR: RE: Re: Anonymous Remailers cpunk
---------- From: Jim Choate[SMTP:ravage@einstein.ssz.com] Reply To: Jim Choate Sent: Thursday, October 12, 2000 7:09 PM To: cypherpunks@einstein.ssz.com Subject: CDR: Re: Anonymous Remailers cpunk
On Tue, 3 Oct 2000, Steve Furlong wrote:
<<Proposal to limit spam sent through anon remailers by requiring that the traffic be encrypted>>
Perhaps we're talking at cross purposes. This subthread came along because some people have noticed that anonymous remailers are used for an awful lot of spam. Peter Trei proposed that remailers could pass along only encrypted mail. My understanding was that Alice, the message's author, would encrypt the message with Bob's public key; Bob is the end recipient: a person or a mailing list or whatever. Alice would send the message through Ramona, the anonymous remailer. Ramona is requiring that messages be encrypted as a means of filtering out spam. Ramona does not need to know Bob's public or private keys; Ramona cares only that the message is encrypted.
So? I set up a email address that I offer to the spammers to sign up to the anonymous remailers and then it proxies their email into the encrypted network. I figure this baby'll stop'em for about six months.
Jim: 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. It is only exit remailers (ie, the remailer which sends to the final recipient) which get hassled for sending spam. 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. 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. Steve understands this, as does every one else but you. What's the problem?
For it to really stop spam it would need to be well distributed. So how do you offset the increased sys admin issues this raises?
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.
Then there is the old key management problem.
James Choate
No, there is not, beyond the fact that the message originator must know the final recipient's public key. Jim, do you really understand how remailer chaining works? Peter Trei
Vizzini: HE DIDN'T FALL? INCONCEIVABLE! Inigo Montoya: You keep using that word. I do not think it means what you think it means. - The Princess Bride
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?...
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.
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.
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. Where's the key management mechanism to ensure the security of the traffic in the reamiler network?
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'. The solution to bad speech is more speech, not regulation. And don't kid yourself that setting up such a mechanism isn't regulatory.
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?
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. ____________________________________________________________________ He is able who thinks he is able. Buddha The Armadillo Group ,::////;::-. James Choate Austin, Tx /:'///// ``::>/|/ ravage@ssz.com www.ssz.com .', |||| `/( e\ 512-451-7087 -====~~mm-'`-```-mm --'- --------------------------------------------------------------------
Jim Choate wrote:
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.
it is INDIVIDUAL encryption. want to spam 100,000 people? gotta encrypt your spam 100,000 times to 100,000 different keys. if you have a fast machine that takes only a second to do so, it'll cost you just over a day...
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'.
this process is exactly as complicated as you sending me a PGP-encrypted message. remailer or not doesn't make a difference. don't you get it? all we do is couple remailers with PGP encryption, enforcing the second by a simple test in the first.
The solution to bad speech is more speech, not regulation. And don't kid yourself that setting up such a mechanism isn't regulatory.
it's my remailer, and I can do to it whatever I like. you are, of course, free to not use it.
What algorithm are you proposing to identify plain-text?
several have been discussed here over the past week or so. none are perfect, but most are good enough to distinguish between spam (which has a describeable structure) and encrypted stuff (which, too, has a describeable structure).
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).
there is no additional complication. to prove that, I'm in the process of setting up just such a remailer. this takes some time since I have no experience in remailer operation, but it'll be done. if anyone wants to help me, send me a mail
You need the key to get into the remailer, otherwise how does it tell the message is encrypted?
I can see whether or not a text is greek or russian without understanding it. likewise, I bet you that anyone on this list can identify an ASCII-armoured PGP message with a single glance. shouldn't be too tough to teach that to a machine, should it?
You seriosly propose sticking some static PGP header for example will stop anyone, spammers know how to use word processors too you know.
please take a look at the simple script I posted here recently. tell me how you want to get it to accept any of the standard spam messages. hint: adding a fake PGP header won't work.
In <Pine.LNX.3.96.1001013190729.19200P-100000@einstein.ssz.com>, Jim Choate wrote:
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).
Pipe the message into GPG and test the output on STDERR. There was some perl code posted to the list not too long ago which does this. -- septic-admin
On 17 Oct 2000, Anonymous wrote:
Pipe the message into GPG and test the output on STDERR.
There was some perl code posted to the list not too long ago which does this.
So, now everyone has to use GPG. Why? How do you propose to answer the increased attacks on the protocol now that you've made it the monopoly? I thought the point of anonymous remailers and commen crypto was to enhance liberty rather than enforce (coerce) another standard. ____________________________________________________________________ He is able who thinks he is able. Buddha The Armadillo Group ,::////;::-. James Choate Austin, Tx /:'///// ``::>/|/ ravage@ssz.com www.ssz.com .', |||| `/( e\ 512-451-7087 -====~~mm-'`-```-mm --'- --------------------------------------------------------------------
Jim Choate wrote:
On 17 Oct 2000, Anonymous wrote:
Pipe the message into GPG and test the output on STDERR.
There was some perl code posted to the list not too long ago which does this.
So, now everyone has to use GPG. Why? How do you propose to answer the increased attacks on the protocol now that you've made it the monopoly?
No one is saying you have to use GPG. The source code is freely available. Anyone can take the algorithm it uses to analyze its input, and outputs whatever it outputs on STDERR when a non-encrypted message is detected, and incorporate it into their own software. You can make it better, or different, or do whatever you feel like doing with it. If some people decide to run remailers that only propagate email that looks encrypted based on GPG's algorithm for detecting encryption, more power to them. If you don't want to use these remailers, you don't have to.
I thought the point of anonymous remailers and commen crypto was to enhance liberty rather than enforce (coerce) another standard.
Yes, enhancing liberty is one useful reason to run or use a remailer. If you don't like the ones that require incoming traffic to be encrypted, don't use them. Run your own. You'll get more spam complaints from end-recipients, but that's your problem. Or use somebody else's. There's no shortage of unrestricted remailers out there. -Bart
____________________________________________________________________
He is able who thinks he is able.
Buddha
The Armadillo Group ,::////;::-. James Choate Austin, Tx /:'///// ``::>/|/ ravage@ssz.com www.ssz.com .', |||| `/( e\ 512-451-7087 -====~~mm-'`-```-mm --'- --------------------------------------------------------------------
In <Pine.LNX.3.96.1001016230116.30086J-100000@einstein.ssz.com>, you write:
On 17 Oct 2000, Anonymous wrote:
Pipe the message into GPG and test the output on STDERR.
There was some perl code posted to the list not too long ago which does this.
So, now everyone has to use GPG. Why? How do you propose to answer the increased attacks on the protocol now that you've made it the monopoly?
Who said anything about switching to GPG? My code uses GPG to determine if a message contains OpenPGP formatted data. In my tests the code is able to determine if a message contains data which has been encrypted/signed with PGP 2.6.3 _and_ GPG. I have not tested messages encrypted/signed with PGP 5.x or PGP 6.x.
I thought the point of anonymous remailers and commen crypto was to enhance liberty rather than enforce (coerce) another standard.
You obviously have not tried the code. Please do so. -- septic-admin
Jim Choate wrote:
Pipe the message into GPG and test the output on STDERR.
There was some perl code posted to the list not too long ago which does this.
So, now everyone has to use GPG. Why? How do you propose to answer the increased attacks on the protocol now that you've made it the monopoly?
I thought the point of anonymous remailers and commen crypto was to enhance liberty rather than enforce (coerce) another standard.
get a clue, jim. GPG/PGP was chosen in my perl code because it is both easy to recognize and widely distributed. other ciphers, methods, etc. can be added. and as always: it's my remailer. if you don't like the policy, then don't use it.
On Mon, Oct 16, 2000 at 11:03:29PM -0500, Jim Choate wrote:
On 17 Oct 2000, Anonymous wrote:
Pipe the message into GPG and test the output on STDERR.
There was some perl code posted to the list not too long ago which does this.
So, now everyone has to use GPG. Why? How do you propose to answer the increased attacks on the protocol now that you've made it the monopoly?
I thought the point of anonymous remailers and commen crypto was to enhance liberty rather than enforce (coerce) another standard.
. This is nonsense. GPG would in this situation not have a monopoly any more (and in fact less) than SMTP or FTP would be. Many free market economists believe there is no such thing as a monopoly sans government intervention. Even if they're wrong, it is silly to describe protocols not owned by one entity as a monopoly. (Who has the "monopoly power," for purposes of legal analysis, for instance?) The point of anonymous remailers and commonly-used crypto varies depending on to whom you speak, but there are worse answers than protecting liberty. And those who defend it know that coercion is done by someone holding a gun to your head, not by someone suggestion a protocol on a mailing list. But of course this is Jim Choate. -Declan
"Trei, Peter" wrote:
No, there is not, beyond the fact that the message originator must know the final recipient's public key.
Jim, do you really understand how remailer chaining works?
and that wouldn't even be an excuse: I don't (completely) and I could come up with this idea. :)
participants (7)
-
An Metet -
Anonymous -
Bartley R. Troyan -
Declan McCullagh -
Jim Choate -
Tom Vogt -
Trei, Peter