---------- From: dmolnar[SMTP:dmolnar@hcs.harvard.edu] On Tue, 3 Oct 2000, Steve Furlong wrote:
cost might be a little extra electricity. No funding is necessary unless the usage is so high that my ISP bitches at me. Personal time involved in maintaining the system will, I hope, be low; if it's more than negligible I won't be able to do it. I can see the sense of running the plan past a lawyer, but why would there be a continuing expense in this area?
People will use your remailer to send spam and death threats. There may even be people who will use your remailer to send spam and death threats to themselves, simply because they hate remailers. The recipients will contact you and your ISP. Repeatedly.
My impression from reading alt.privacy.anon-server is that for many ISPs, it doesn't take too much of this before the ISP asks the remailer to leave. It's not a question of legal liability so much as the spam and the hassle. (An example of how life is lived mainly outside the law, though maybe in view of it.)
You can implement spam-blocking filters on your remailer...but that's another can of worms.
-David
[Warning in advance: I don't run a remailer, and never have, so what follows could be labled uninformed speculation]. I would like to suggest that a remailer could eliminate nearly all it's problems by only sending out encrypted mails - that is, if after removing the encryption that was applied using it's own private key, it finds that the result is plaintext, it simply drops the message. This has some neat and useful properties. * It eliminates spam. Spammers would have to encrypt each individual message with the key of the recipient, which is too much hassle. * It eliminates any possibility of the remailer knowing the content, which alleiviates him/her of responsibility for that content. * The remailer still operates fine as a mid-chain remailer. * All recipients need to have keypairs. They are thus at least somewhat crypto-savvy people, and unlikely to place unreasonable requests on the remailer or his/her ISP. The only bad point: * All recipients need to have key pairs. Thus, a crypto-only remailer can't be a terminal remailer to mailing lists, newsgroups, or individuals without keypairs. Peter Trei
On Tue, 3 Oct 2000, Trei, Peter wrote:
I would like to suggest that a remailer could eliminate nearly all it's problems by only sending out encrypted mails - that is, if after removing the encryption that was applied using it's own private key, it finds that the result is plaintext, it simply drops the message.
And just exactly what algorithm is that you're using to determine crypt-v-plaintext? Ain't no such beast and won't be until somebody comes up with nearly infallible translation technology. We're closer to quantum computers and making the whole thing moot than we are to having near-flawless translation technology. If a bullfrog had wings, it wouldn't bump its butt when it jumped. And let's not forget the key managment problem if remailers impliment such a policy. Without a secure key management scheme then the 'encrypted body' approach won't work because Mallet has the keys. Key management and a billing model are what is required to make anonymous remailers work. ____________________________________________________________________ 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 Tue, 3 Oct 2000, Trei, Peter wrote:
I would like to suggest that a remailer could eliminate nearly all it's problems by only sending out encrypted mails - that is, if after removing the encryption that was applied using it's own private key, it finds that the result is plaintext, it simply drops the message.
And just exactly what algorithm is that you're using to determine crypt-v-plaintext?
Why not just read the first 20 bytes of the body? If 90% or more aren't printable ASCII assume the message is encrypted. SRF -- Steve Furlong, Computer Condottiere Have GNU, will travel 518-374-4720 sfurlong@acmenet.net
On Tue, 3 Oct 2000, Steve Furlong wrote:
Why not just read the first 20 bytes of the body? If 90% or more aren't printable ASCII assume the message is encrypted.
So, how come all of a sudden we're injecting algorithms that the users must know to even access the network? What sort of regulatory mechanism is required to mediate changes to the process? So, we can't send uuencoded text to guard against ASCII-pure (i.e. 7-bit) machines? Why not? I actualy prefer that sort of stuff because as a last resort I can check it visualy for errors. Why not offer a set of services and 'default' or 'best practice' suggestions, leaving the actual decisions up to the user where it belongs? A remailer should do NO content checking, ever. It's ONLY job is to route and destroy traffic analysis. ____________________________________________________________________ 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 --'- --------------------------------------------------------------------
<<Proposal to limit spam sent through anon remailers by requiring that the traffic be encrypted>> Jim Choate wrote:
<<Jim wrote that there was no good way to tell if the message was encrypted>>
On Tue, 3 Oct 2000, Steve Furlong wrote:
Why not just read the first 20 bytes of the body? If 90% or more aren't printable ASCII assume the message is encrypted.
So, how come all of a sudden we're injecting algorithms that the users must know to even access the network? What sort of regulatory mechanism is required to mediate changes to the process?
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. I'm assuming there's a way to tell with minimal difficulty if a message is encrypted, without relying on an easily-spoofed X header line. Perhaps someone who knows more about all of the many message protocols can weigh in here.
So, we can't send uuencoded text to guard against ASCII-pure (i.e. 7-bit) machines? Why not? I actualy prefer that sort of stuff because as a last resort I can check it visualy for errors.
You could uuencode your original message before encrypting it. You're right, there could be a problem if one of the boxes in the chain handled only 7 bits. Is that a realistic problem anymore? (That was a serious question, not a dig.)
A remailer should do NO content checking, ever. It's ONLY job is to route and destroy traffic analysis.
This would be an additional service for the recipients, filtering out probable spam. It might be a minor inconvenience for Alice. On a message-by-message basis it could be a minor inconvenience for Bob, but if Bob had been receiving a lot of spam through the remailer it'd be a neg gain. It'd be a huge inconvenience for Sue, the spammer, as intended. -- Steve Furlong, Computer Condottiere Have GNU, will travel 518-374-4720 sfurlong@acmenet.net
Checking the first 20 bytes just means the spammer will just add 20 bytes of junk to the start of their message. Spammers unfortunately, can be pretty smart, look at all the work they will do to cull addresses from newsgroups and mail lists, even looking for "mailto:fred@NOSPAM.fff.com (Remove NOSPAM to send me a message)" type addresses. Better to have it run the message through the encryption program (PGP or Mix) somehow to see if it is a well formed (contains valid packets). Of course that means restricting users to PGP or other standard encryption systems (I can see it now, all SPAM will arrive starting with "------ BEGIN PGP ENCRYPTED MESSAGE ----") :) I always liked the proposal of using crypto to force users pay money to have the message sent, then be refunded if the recipient feels the message was worthwhile. Neil M. Johnson njohnson@interl.net http://www.interl.net/~njohnson PGP Key Finger Print: 93C0 793F B66E A0C7 CEEA 3E92 6B99 2DCC ----- Original Message ----- From: "Steve Furlong" <sfurlong@acmenet.net> To: "Multiple recipients of list" <cypherpunks@openpgp.net> Sent: Tuesday, October 03, 2000 5:22 PM Subject: CDR: Re: Anonymous Remailers cpunk
<<Proposal to limit spam sent through anon remailers by requiring that the traffic be encrypted>>
Jim Choate wrote:
<<Jim wrote that there was no good way to tell if the message was
encrypted>>
On Tue, 3 Oct 2000, Steve Furlong wrote:
Why not just read the first 20 bytes of the body? If 90% or more aren't printable ASCII assume the message is encrypted.
So, how come all of a sudden we're injecting algorithms that the users must know to even access the network? What sort of regulatory mechanism is required to mediate changes to the process?
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.
I'm assuming there's a way to tell with minimal difficulty if a message is encrypted, without relying on an easily-spoofed X header line. Perhaps someone who knows more about all of the many message protocols can weigh in here.
So, we can't send uuencoded text to guard against ASCII-pure (i.e. 7-bit) machines? Why not? I actualy prefer that sort of stuff because as a last resort I can check it visualy for errors.
You could uuencode your original message before encrypting it. You're right, there could be a problem if one of the boxes in the chain handled only 7 bits. Is that a realistic problem anymore? (That was a serious question, not a dig.)
A remailer should do NO content checking, ever. It's ONLY job is to route and destroy traffic analysis.
This would be an additional service for the recipients, filtering out probable spam. It might be a minor inconvenience for Alice. On a message-by-message basis it could be a minor inconvenience for Bob, but if Bob had been receiving a lot of spam through the remailer it'd be a neg gain. It'd be a huge inconvenience for Sue, the spammer, as intended.
-- Steve Furlong, Computer Condottiere Have GNU, will travel 518-374-4720 sfurlong@acmenet.net
Remember that we're talking about detecting spam on *outgoing* messages - any incoming messages have to be encrypted also, which is too much work for almost all most spammers, and requires them to do computation on each message (especially if you only output one outgoing message per incoming.) At 09:33 PM 10/3/00 -0400, Neil Johnson wrote:
Checking the first 20 bytes just means the spammer will just add 20 bytes of junk to the start of their message.
Spammers unfortunately, can be pretty smart, look at all the work they will do to cull addresses from newsgroups and mail lists, even looking for "mailto:fred@NOSPAM.fff.com (Remove NOSPAM to send me a message)" type addresses.
Better to have it run the message through the encryption program (PGP or Mix) somehow to see if it is a well formed (contains valid packets).
Of course that means restricting users to PGP or other standard encryption systems
(I can see it now, all SPAM will arrive starting with "------ BEGIN PGP ENCRYPTED MESSAGE ----")
Thanks! Bill Bill Stewart, bill.stewart@pobox.com PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639
Here's an interesting idea for a service... since most folks are agreed that spammers won't do encryption, does it not make sense to have spam-free email accounts on some server somewhere? You can do this pretty simply -- all non-encrypted messages are forwarded to dev/null. If the user wants to, she could use a procmail script that sends a bounce message -- or a procmail script that doesn't. If you're worried about spammers using the service to send mail, you can just adopt the same policy for outgoing messages. So you could have an address where it was enforced that nobody could contact you there without encrypting the message, and then you wouldn't have to worry about carnivores sniffing something sensitive, or about server logs giving snoops your mail, or etc. And as a side benefit, you'd get zero spam -- at least until the spammers ran out of people they could spam more easily. I think I like this idea, because it would elevate encrypted email from an abberation to be tracked to the universal condition, at least for that system -- and introduce a reason for people out there to *learn* to use crypto software, if they wanted to talk to people on the system. Ray
Ray Dillinger wrote:
I think I like this idea, because it would elevate encrypted email from an abberation to be tracked to the universal condition, at least for that system -- and introduce a reason for people out there to *learn* to use crypto software, if they wanted to talk to people on the system.
same problem here: how do you find out whether or not a message is encrypted?
On Wed, 4 Oct 2000, Tom Vogt wrote:
same problem here: how do you find out whether or not a message is encrypted?
Plaintext looks like plaintext. This isn't even a "real" problem, once you look at the text produced by, eg, PGP, GPG, and whatever else you allow on the system. You don't even have to have a human look at it; a simple program to count character distributions, character contacts, and line lengths can identify something as being the legitimate output of PGP, or whatever encryption program, with a margin of error so flat it's only theoretical. It would need to make a "profile" for PGP, another one for GPG, etc -- then look at incoming messages to see if they match the profile. I mean, yeah, people could theoretically get stuff past it, or it could theoretically bounce encrypted messages -- but people can also theoretically guess a 128-bit encryption key on the first try, and I wouldn't expect that to happen. Ray
On Wed, 4 Oct 2000, Ray Dillinger wrote:
On Wed, 4 Oct 2000, Tom Vogt wrote:
same problem here: how do you find out whether or not a message is encrypted?
Plaintext looks like plaintext.
Yeah, if the only thing you right is simple English. Most of the planet doesn't speak English and their plaintext doesn't necessarily look like plaintext. This is a xenophobic view.
This isn't even a "real" problem, once you look at the text produced by, eg, PGP, GPG, and whatever else you allow on the system.
Ah, here's the rub. Here we are trying to stop the government and other organizations from dictating 'standards' and yet here you are wanting to impose another one. The function of an anonymous remailer should NOT be context/content sensitive. ____________________________________________________________________ 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 --'- --------------------------------------------------------------------
On Wed, 4 Oct 2000, Jim Choate wrote:
On Wed, 4 Oct 2000, Ray Dillinger wrote:
Plaintext looks like plaintext.
Yeah, if the only thing you right is simple English. Most of the planet doesn't speak English and their plaintext doesn't necessarily look like plaintext.
This is a xenophobic view.
No, it's not. Every natural language has a detectable frequency distribution and contacts. *ALMOST* every cipher does not. Someone could be writing martian using the cyrillic alphabet, and you could still look at it and say "this character occurs seven times as often as average and is never followed by that character. This other character is preceded by the same character fully half the time it appears. And over here we have a set of characters one of which *always* follows any appearance of any member of this other set of characters (which is a constant in almost all languages with plosive consonants -- the only thing that normally follows a plosive consonant is a vowel...) You don't have to know what it says or what language it is. Plaintext looks like plaintext, and by the time you have more than 50 characters the probability curve of mistaking it for anything else is flat as a goddamn strap.
This isn't even a "real" problem, once you look at the text produced by, eg, PGP, GPG, and whatever else you allow on the system.
Ah, here's the rub. Here we are trying to stop the government and other organizations from dictating 'standards' and yet here you are wanting to impose another one.
Did I say someone else couldn't set up a crypto-only mailer using DES and AES? You always get to dictate 'standards' for systems you own. I always get to dictate standards for systems I own. And the government rightfully gets to dictate standards for systems it owns. Sometimes it tries to do more than is rightful, but that is another question.
The function of an anonymous remailer should NOT be context/content sensitive.
Uh, now who's trying to impose a standard? You want a system that _someone_else_ runs to conform to _your_ ideas of what it ought to do. You get to dictate standards on systems _YOU_ own -- not on anyone else's. Bear
At 06:07 PM 10/4/00 -0500, Jim Choate wrote:
On Wed, 4 Oct 2000, Ray Dillinger wrote:
On Wed, 4 Oct 2000, Tom Vogt wrote:
how do you find out whether or not a message is encrypted?
Plaintext looks like plaintext.
Yeah, if the only thing you right is simple English. Most of the planet doesn't speak English and their plaintext doesn't necessarily look like plaintext. This is a xenophobic view.
8-bit-alphabet plaintext looks like plaintext. It's easier to recognize popular languages - short bunches of letters separated by spaces. Less popular languages that use 8-bit alphabets still have easily detected statistics that are much different from uniformly-distributed cyphertext. Languages with N-byte characters are much harder - you have to decide whether to look at Unicode, (2-byte's bad enough; variable-byte is worse), otherwise you'll get totally hosed on your chi-squares. Things that start with popular magic numbers like gif89 also look like plaintext (though they may in fact be stego.) Thanks! Bill Bill Stewart, bill.stewart@pobox.com PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639
On Tue, 3 Oct 2000, Bill Stewart wrote:
Remember that we're talking about detecting spam on *outgoing* messages -
No, we're not. We ARE talking bout checking incoming messages to ensure the body of the message is encrypted. No unencrypted traffic. End to end crypto, all the way baby... My question is still, What algorithm is proposed that can reliably determine the difference between plaintext and cyphertext, note that we don't know what algorithm is used, with only 20 bytes/char's? Another question I have is, does this mean that anonymous stego isn't possible now with this approach. Though it does pose another facet to the algorithm issue, What algorithm will reliably find stego data? That's a doozie. ____________________________________________________________________ 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 --'- --------------------------------------------------------------------
At 10:26 PM 10/3/00 -0500, Jim Choate wrote:
On Tue, 3 Oct 2000, Bill Stewart wrote:
Remember that we're talking about detecting spam on *outgoing* messages -
No, we're not. We ARE talking bout checking incoming messages to ensure the body of the message is encrypted. No unencrypted traffic. End to end crypto, all the way baby...
Sure are - it's a followon to Peter Trei's message dated Tue, 3 Oct 2000 10:48:07 -0400 which said = I would like to suggest that a remailer could eliminate nearly all it's = problems by only sending out encrypted mails - that is, if after = removing the encryption that was applied using it's own private = key, it finds that the result is plaintext, it simply drops the message. That's a remailer checking outgoing mail to be sure it's encrypted, as well as checking incoming mail.
What algorithm is proposed that can reliably determine the difference between plaintext and cyphertext, note that we don't know what algorithm is used, with only 20 bytes/char's?
On incoming messages, it's easy to tell if it's encrypted to *you* - decrypt it with your private keys, job's done. If you don't recognize the algorithm, the message wasn't for you.
Another question I have is, does this mean that anonymous stego isn't possible now with this approach.
Hmmm. That's a more interesting problem - this does seem to have the tradeoff that if you want to get messages sent to you using stego, you shouldn't use a remailer that has a PGP-out-only policy. On the other hand, mail from a known Cypherpunks Anonymous Secret Message Remailer adds a certain amount of suspiciousness anyway. You want to get your stego messages from "Fred's GIF-of-the-Day" or "Pirate-Muzick-R-Us" or something that's a better cover story - so make sure those sites accept incoming PGP mail.
What algorithm will reliably find stego data?
If you can reliably find it, it's not very good stego :-) Open source stego that's not key-based has inherent weaknesses - the eavesdroppers can easily extract the message from the cover text, so the message needs to be binary random-looking noise which somewhat plausibly belongs in the message (e.g. low bits of sound samples.) Thanks! Bill Bill Stewart, bill.stewart@pobox.com PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639
At 05:22 PM 10/3/2000, Steve Furlong wrote: ...
I'm assuming there's a way to tell with minimal difficulty if a message is encrypted, without relying on an easily-spoofed X header line. Perhaps someone who knows more about all of the many message protocols can weigh in here. ...
Excuse me for butting in here, as my knowledge of crypto can be expressed on one page, double spaced, but. I believe Robert Morris, father of the (in)famous RTM, wrote a "spellchecker" for UNIX back in the 70's that was based on character probability. He's also, from my understanding, responsible for the one way hash that keeps UNIX passwords secure, and he later signed on with the NSA. Couldn't something that A. Watched for a limited list of known words, (including the header information for UUENCODED, and MIME encoded, GIF's, JPG's, BMP's, MP3's etc, along with a dictionary of very common 6+ letter words. and B. Back that up with some simple analysis, of the sort that can break single alphabet cyphers, (finding the e's, etc). Correct me if I'm wrong, and I may very well be, but, wouldn't an ecrypted message using modern techniques have a near flat distribution of all characters used? Good luck, Sean Roach
At 02:05 AM 10/4/00 -0400, Sean Roach wrote:
At 05:22 PM 10/3/2000, Steve Furlong wrote: ...
I'm assuming there's a way to tell with minimal difficulty if a message is encrypted, without relying on an easily-spoofed X header line. Perhaps someone who knows more about all of the many message protocols can weigh in here. ... .... Couldn't something that A. Watched for a limited list of known words, (including the header information for UUENCODED, and MIME encoded, GIF's, JPG's, BMP's, MP3's etc, along with a dictionary of very common 6+ letter words. and B. Back that up with some simple analysis, of the sort that can break single alphabet cyphers, (finding the e's, etc).
Interesting idea, but far more trouble and CPU than it's worth, especially if you handle all the cases of MIME-encoded and UUencoded stuff. Also, it'll probably decide GIFs, JPEGs, MP3s, and WAVs are encrypted data. It's not going to stop all the harassers either, just force them to be more clever, while slightly decreasing the reliability of your remailer. It's probably better to use simple detection of encryption (look for the headers) and put in your own Subject: and header lines advising the recipient that it's an anonymous message and how to block it, which will take care of most of the anklebiters and let you be really apologetic to the recipient about how the abuser is trying real hard to work around your protections. Subject: Anonymous Message - Info at http://foobar.remailer.cc/policy.html At some point, you might decide that Type I remailers aren't really secure enough, and just run Mixmaster anyway. Then most of this goes away. The place I found that remailers really get into trouble is Usenet. It's not the messages directly to the harasser, it's things like forged flamebait sent to gay newsgroups or rec.pets.cats. Limiting yourself to encrypted output makes it hard to post. If you're going to post directly to Usenet, it's safe to append and prepend a bunch of disclaimers to the message body (since nobody reads headers) about how this was an anonymous message, it's untraceable, there aren't any records, it's probably forged anyway, and the web page for complaints and instructions is http://foobar.remailer.cc/policy.html Thanks! Bill Bill Stewart, bill.stewart@pobox.com PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639
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. 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? Then there is the old key management problem. ____________________________________________________________________ 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 --'- --------------------------------------------------------------------
At 05:00 PM 10/3/00 -0500, Jim Choate wrote:
A remailer should do NO content checking, ever. It's ONLY job is to route and destroy traffic analysis.
No, its ONLY job is to do whatever the operator says it will do. You can choose to use it or not based on that. However, if you allow non-encrypted email in or out, you are enabling traffic analysis, so by your assertion, failing to require encrypted outgoing mail is wrong.
So, how come all of a sudden we're injecting algorithms that the users must know to even access the network? What sort of regulatory mechanism is required to mediate changes to the process?
Algorithms the users must know, and don't, lead to random failures, low reliability, complaints to the admins, and people not using the remailer. That regulatory mechanism is called the market :-) (even in a gift economy.) There are several remailer-pinging services out there, and unless they fall into the category of things the remailer supports, the reliability numbers they report on the remailer will be quite low. Thanks! Bill Bill Stewart, bill.stewart@pobox.com PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639
On Tue, 3 Oct 2000, Bill Stewart wrote:
At 05:00 PM 10/3/00 -0500, Jim Choate wrote:
A remailer should do NO content checking, ever. It's ONLY job is to route and destroy traffic analysis.
No, its ONLY job is to do whatever the operator says it will do.
Not really, the thing may not do what the operator says or necessarily in the way they may say. ____________________________________________________________________ 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 --'- --------------------------------------------------------------------
At 05:46 PM 10/3/00 -0400, Steve Furlong wrote:
Jim Choate wrote:
On Tue, 3 Oct 2000, Trei, Peter wrote:
I would like to suggest that a remailer could eliminate nearly all it's problems by only sending out encrypted mails - that is, if after removing the encryption that was applied using it's own private key, it finds that the result is plaintext, it simply drops the message.
And just exactly what algorithm is that you're using to determine crypt-v-plaintext?
Why not just read the first 20 bytes of the body? If 90% or more aren't printable ASCII assume the message is encrypted.
Doesn't work - many mail packages will encode non-printable characters in ASCII, either with MIME or UUENCODE or hex or whatever, and many encryption packages, like PGP, do that already. If you require PGP Encryption, you can look for the -----BEGIN PGP ENCRYPTED STUFF------ line. That still gets you into trouble with MIME if you're not careful, so either be careful or don't :-) The only way you can really tell if something is encrypted is for a human to look at it. Otherwise people will figure out that they can send messages saying -----BEGIN PGP ENCRYPTED STUFF------ HaHaWeFooledTheRemailer. You suck! -----END PGP ENCRYPTED STUFF----- But still, you can keep out all but really determined abusers, and all but incredibly determined spammers. (Even basic encryption will keep out almost all spammers.) (You could check that the whole message follows PGP syntax, but without knowing at least one decryption key you can't tell if it's valid or if they wrote the abuse on top of an otherwise syntactically correct encrypted message.) If you want to get fancier, you can also limit destinations to known remailers or to people who've replied to a "You have anonymous mail - return this cookie if you want to receive it. <blurbage about remailers>" request. Thanks! Bill Bill Stewart, bill.stewart@pobox.com PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639
Steve Furlong wrote:
Why not just read the first 20 bytes of the body? If 90% or more aren't printable ASCII assume the message is encrypted.
Or compressed, or a bitmap, or executable code, or coming from an EBCDIC machine, or using a weird variant of Unicode that you weren't previously aware of, or audio, or video... Without a header at the front saying "This is PGP version such-and-such" (or whatever other algorithm is used) there is no way to tell well-encrypted text from some sorts of compressed files. That is part of the point - if the encrypted text was obviously different from random data the difference could contain clues. Ken
Steve Furlong wrote:
I would like to suggest that a remailer could eliminate nearly all it's problems by only sending out encrypted mails - that is, if after removing the encryption that was applied using it's own private key, it finds that the result is plaintext, it simply drops the message.
And just exactly what algorithm is that you're using to determine crypt-v-plaintext?
Why not just read the first 20 bytes of the body? If 90% or more aren't printable ASCII assume the message is encrypted.
excuse me? -----BEGIN PGP MESSAGE----- Version: GnuPG v1.0.0 (GNU/Linux) Comment: For info see http://www.gnupg.org hQEOA8lrC6Jn0qUQEAQAmEavAJY3wI6rMnVp3b3JXAnYchKrSla33rrULJlqi/la dHMlYCl9jxG0Bjga290HFM6KnmEkOop4UZ2rWWq80IKLeS56JH7GnseEzV7Dni7F BGiSRxQ22sRr2+6jbBLjUnKLYX8AEdJf+T9BEg57FQkczV9554IcG9s5peoPuOoE AMUNMFkdN0Ah0hB8Q813gJIqXB9DB+GzYIaW3lbwb7bCfilEc0Rp/4Ins+tqJe1/ ShwDDWz8W8mw4gVxhaf8KXWWCXxXUUbiVHcSC88CrhKIOSxbt8GubUctj+EKiOSP tHSh5mVwV2T7K7Y/CLCV4wYxnxuNT0DBOFftq5f1g+i9yTRx295zGFVb7wc9jCR4 0eI8xyI1B+KprpjpAU7QXSOtVqC0e5RZvQZWjECvIfyU4aJ3+itC =QQH+ -----END PGP MESSAGE-----
Jim Choate wrote:
And just exactly what algorithm is that you're using to determine crypt-v-plaintext?
that's a problem. if no such algorithm exists, I suggest that - for this specific purpose - a few heuristics would do. suggestion (version 0.1): - dictionary of 100 most common words from english plus a couple other languages. if more than 1% of the text fits, it's either plaintext or a really weird cipher. - look for PGP-style "encrypted message starts here" tags - look for "multipart/encrypted" headers it's not perfect, but it should do if the mailer policy clearly explains it.
And let's not forget the key managment problem if remailers impliment such a policy. Without a secure key management scheme then the 'encrypted body' approach won't work because Mallet has the keys.
that's not the issue, is it? the purpose here is: a) make the remailer spam-proof. the requirement to encrypt every mail (i.e. encrypt 1000 times if you send to 1000 people) drives the costs for spam up to where it no longer pays the bills. b) make the remailer censor-proof. if I can show that I have no idea of what's going through my server, you can't force me to filter out specific content (same idea works on freenet)
Three:
[Warning in advance: I don't run a remailer, and never have, so what follows could be labled uninformed speculation].
I would like to suggest that a remailer could eliminate nearly all it's problems by only sending out encrypted mails - that is, if after removing the encryption that was applied using it's own private key, it finds that the result is plaintext, it simply drops the message. <...> The only bad point:
* All recipients need to have key pairs. Thus, a crypto-only remailer can't be a terminal remailer to mailing lists, newsgroups, or individuals without keypairs.
Simple fix is to add a "Decrypt using this key" header (or prepend to the body, which is "wrong" in that a MTA shouldn't screw much with the body). It should stop spammers since their targets usually won't be expecting encrypted messages etc. and would be much less likely to bother decrypting them. It could still be used as a terminal to a mailing list or newsgroup, just with a bit of extra hassle. Additionally, remailers could advertise selective use of this--i.e. they have certain addresses (mail to news gateways, mailing lists that don't mind anonymous traffic etc.) that they don't encrypt to. -- A quote from Petro's Archives: ********************************************** Sometimes it is said that man can not be trusted with the government of himself. Can he, then, be trusted with the government of others? Or have we found angels in the forms of kings to govern him? Let history answer this question. -- Thomas Jefferson, 1st Inaugural
"Trei, Peter" wrote:
I would like to suggest that a remailer could eliminate nearly all it's problems by only sending out encrypted mails - that is, if after removing the encryption that was applied using it's own private key, it finds that the result is plaintext, it simply drops the message.
I like that idea. so much that I might start a remailer with these properties, in order to test it out. single question left: what is a reliable way to see whether or not a text is plain or cipher?
participants (10)
-
Bill Stewart -
Jim Choate -
Ken Brown -
Neil Johnson -
petro -
Ray Dillinger -
Sean Roach -
Steve Furlong -
Tom Vogt -
Trei, Peter