- cypherpunks-legacy - lists.cpunks.org

Remailer Abuse (fwd)
by Homer Wilson Smith 17 Dec '03

17 Dec '03

Here is the message I sent to both the complainant and the complainee. Homer Dear ..... , I have been contacted by someone complaining about a posting you made through my remailer. They want me to tell them who you are, which ain't going to happen, but at the same time I don't like getting complaints, you understand? Of course I can not tell you who complained any more than I can tell them who you are. But you know where you have been posting using my remailer, right? Now I have no idea if what you posted was really abusive or not, I did not see the posting or postings, and I know a lot of people complain about 'abuse' when really its just their closed minds being opened up. I was able to 'trace' you because you sent something through my remailer without using chaining. If you had chained I would never know who the posting came from. I was told who it went too and the time, and its right there in my system's syslogs coming from you. If you chain and use PGP, then I could not have traced you. So read the instructions on chaining and make sure you USE it. You will be a lot safer in the future from complaint attempts than if you don't use chaining. If you have questions on how to chain, ask on alt.privacy.anon-server or read the various helps at many of the remailers. I have reposted this letter to alt.privacy.anon-server without your name and sent a copy to the complainant. I expect not to hear anything more about you, ok? Homer Wilson Smith System Adminstrator of Remailer at homer(a)rahul.net

1 0

Re: Abuse Complaint out of homer@rahul.net
by wcs＠anchor.ho.att.com 17 Dec '03

17 Dec '03

Michael wrote, to Homer and the lists > I am going to have to agree with you on this. > A Sysadmin would have to see the messages or data that is > supposed to be harassing the complainant. What I say is harassment > may be different from what you say it is. There's different levels of harassment. For the kind that says 1) "Don't send me any of this junk mail any more", if the recipient wants to define junk mail to the remailer-operator, there's no ethical problem if the operator wants to block remailed mail to the recipient, though it's good form in non-remailer-chain environments for the operator to issue a bouncegram if possible. If the recipient has to pay per byte/message to receive mail, or the amount transmitted is really excessive, then this is certainly something an operator ought to do to avoid problems. (It's potentially bad form for a for-profit operator to cash digicash postage for delivering the messages if he doesn't, at least without a warning in his pricing policy advertisment.) If the operator doesn't want to block remail to an unwilling recipient, the ethical and legal questions become more interesting. The question of whether the "don't bug me" list gets published is also interesting. For the kind of harassment complaint that says 2) "Block all remail to me from this destination", there are implementation issues - can the remailer perform checks like this before doing the header-munging? Is there more security risk? Of course, with chaining, it's a lot less useful. For the kind of complaint that says 3) "Block all remail to this group of people", there's the question of whether the requester is authorized to request that for the entire group - newsgroups are an especially interesting problem. Julf's remailer blocks posting to some newsgroups, because the readers have done the usual net.poll and decided they'd like him to block it, since lots of the remail was spam. But especially with newsgroups, it's easy for the recipient to trash incoming articles from the remailers. Bill

1 0

Re: Abuse and Remailer Ethics
by John Young 17 Dec '03

17 Dec '03

On Tue, 17 Jan 1995 anonymous-remailer(a)xs4all.nl (Name withheld on request) said: >This comment is grossly unfair. Obviously Homer is going to a lot of effort to >operate his remailer in the best way possible. > >It's easy for others to be critical. "head on a plate" is a strong term to >use, given Homer made it clear he would not reveal the identity of an anonymous >user without a court order. Also, one wonders to what end remailers are being >put by people who are worried about being "sold out". > >It's always been a good policy to use a foreign mailer in a chain where >anonymity is critically important. That doesn't mean it's OK to make Homer the >whipping boy. I agree that it's a bit much to expect the remailer operator to heroically perform beyond what any of us would do in the same lonely spot under duress. Tim has written recently on another list that the USG grabs enemies in other domains when the national interests are at stake -- the 800-pounder can define any of its actions legal, or to hell with legal niceties as the Beast opts, the picky lawyers can sort it out later, or never. Does not Duncan and others have wisdom on this: Don't roll over out of ignorance and faint-heartedness, but do carefully protect your keister, with feet-on-ground planning, mercury-technology and out-wits. Watch for signs of sneak attack through the guy being squeezed next door, or by a cahoots-machine zipping psy-war toot-alarms to foster fearful quiescence. Some warning examples may be in the offing in the rising heat of dreaded horse-threats to civil society. If so, some will be arranged by provocateurs like past G-guy tricks. So it goes. So what. Nesta said, it's fun to lance swollen infected over-controlling heads.

1 0

Re: Another problem w/Data Havens...
by Johnathan Corgan 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- >Data havens that can split data to two or more locations in seperate >jurisdictions can effectively ignore attention from authorities not >related to the site management or site preformance. Encryption mandated >sites can also take this stance, while encryption is legal in any event. It just occurred to me when reading this another method for ensuring the "I can't tell what's in it" condition with a data haven operator. Why not use a secret sharing system where the contraband data is split into a number of pieces and sent to different havens? It could be argued that the individual pieces are not the same as the whole, and there is absolutely no way the operator could recover the original from a given piece (thus providing plausible deniability.) Using M by N secret sharing, with M < N, you build in some redundancy in case one of the havens gets shutdown. Ok, Eric, go ahead and blast your holes in this argument :) == Johnathan Corgan "Violence is the last refuge of the incompetent." jcorgan(a)scruznet.com -Isaac Asimov -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBLxspxk1Diok8GKihAQG4FAQAjCaFOGC+N5zjQ3zVQstv75wxBp/d0js1 2a3ecWdD/S3Sv70l9Y2N4e4vja8Pps4eR1a7Gtzq/nWcHmZXRGRgCzaaHGCNibF5 RaIJUlGGpaKe/UaQ3XfZH2guRBSUCIi4To7QWf3CzpZoWkR4gmZhhB1AcZrd6Z34 WYqZUBwuISI= =68Mc -----END PGP SIGNATURE-----

4 3

pgp.el, as shown at the last PhysMeet
by Jack Repenning 17 Dec '03

17 Dec '03

At this weekend's Physical Meeting, I demonstrated pgp.el, an interface to PGP for use from GNU Emacs. As I mentioned, this package is available from the standard Emacs lisp archives and other places. However, the version I showed is advanced beyond those sites, most notably in the use of color to highlight various PGP messages, and in the "transparent decryption" feature that I talked about the most. If you'd like to look over this latest version, you can snarf it from: ftp.sgi.com:private/pgp-el.tar.gz This version is still under test and development (notably, I want to get the transparency working for rmail as well as mh-e, and for sending as well as receiving). Because it's not finished yet, I've put it in the private/ directory, which is protected against browsing. When that's all finished, I'll be publishing it again in the usual places.

1 0

Re: Another problem w/Data Havens...
by Ben.Goren＠asu.edu 17 Dec '03

17 Dec '03

At 4:43 PM 1/17/95, Paul J. Ste. Marie wrote: >At 03:29 AM 1/17/95 EST, bill.stewart(a)pleasantonca.ncr.com +1-510-484-6204 >wrote: >> ... That way, Dave's system really only has knowledge of the headers, >>plus one line at a time of incriminating data on the fly. ... > >I don't see exactly what that is buying Dave. The entire contents were >still transmitted to him, so the ability to see the entire file was still >present, which means he could have, had he chosen to do so, prevented the >file from residing on his system, and could have screened it. It's >essentially only the word of the haven op that shows he didn't examine the >entire file. That's the main reason why I like my idea of having a trusted encryptor. Nobody's suggested that the current timestamp operators would be in Deep Doo-Doo if they timestampped some piece of thoughtcrime; why should somebody who encrypts be any different? The service could even be advertised as a different form of timestamping (or notarizing). Not only do you get the file back signed, but you get it back encrypted and signed. > --Paul J. Ste. Marie > pstemari(a)well.sf.ca.us, pstemari(a)erinet.com b& -- Ben.Goren(a)asu.edu, Arizona State University School of Music Finger ben(a)tux.music.asu.edu for PGP public key ID 0x875B059.

2 1

Re: Another problem w/Data Havens...
by Ben.Goren＠asu.edu 17 Dec '03

17 Dec '03

At 6:03 PM 1/17/95, Robert Rothenberg wrote: >> Doo-Doo if they timestampped some piece of thoughtcrime; why should >> somebody who encrypts be any different? >> >> The service could even be advertised as a different form of timestamping >> (or notarizing). Not only do you get the file back signed, but you get it >> back encrypted and signed. > >Hmmm.... Of course in some cases one may not want the file to be returned >with a signature and timestamp (might be incriminating evidence, depending >on what one wants stored and the overall political situation where one is, >etc....). Of course that does sound useful. Just as a notary public does not certify that a given document is truth, but rather that it is what it is and the signature belongs to the person who it appears to belong to, a public timestamp/notary/encryption service on the 'net would certify the existence of that document in that form at that time. No more, no less. If I recall correctly, a notary can certify a sealed envelope without knowing its contents, by putting a tamper-proof seal on it. Sound familiar? I'll try to find a notary to see if that's the case. If so, we're got as good a precedent as we'll ever find for just about anything. >Rob <rrothenb(a)ic.sunysb.edu> Finger for public key b& -- Ben.Goren(a)asu.edu, Arizona State University School of Music Finger ben(a)tux.music.asu.edu for PGP public key ID 0x875B059.

1 0

Re: remailer security
by shamrock＠netcom.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- At 8:50 PM 1/17/95, Mats Bergstrom wrote: >There are ways of >multiple chaining for the lazy, though: C2 lets you pick the chained >sites by clicking on a web-page (but does it encrypt??). No it doesn't. Which dramatically reduces its usefullnes. There should be some way to add encryption envelopes to the CGI script. Premail? - --Lucky <who is about to find out if the new MacPGP and scripts that he picked up finally solved his clearsig problems> -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Not-the-Real MacPGPv262 iQCVAwUBLxzBawSQkem38rwFAQE8qAP8DODqlKop7fo7zwWYDCYEbygxr8PT9yv7 w9CNqyPC57zufrjZJurg3twx91Uqf9fJ3mEGHGrDKfwqXu3A4RPo0E+BAJCyUS61 8Tqj80oM8TE7Nmr04pEBZhI5CgTq5lAjdTT5m7ndlP25IkJPl+W/eEdGnyKrqcXr I8PL8jV2rU8= =wEur -----END PGP SIGNATURE----- -- Lucky Green <shamrock(a)netcom.com> PGP encrypted mail preferred.

1 0

Re: 40bit Encryption : Adequate or sadly lacking ?
by kipp＠warp.mcom.com 17 Dec '03

17 Dec '03

In article <3fh5m0$7tg(a)hdxu03.telecom.ptt.nl>, you write: > In article <marca-1201952123120001(a)boulanger.mcom.com>, marca(a)mcom.com > says... > > > >There's no question that 40-bit is less than one would prefer. > >This is why we are/will be supporting 128-bit RC4, for example, > >in US-only products, honoring United States government export > >restrictions. > > Marc, isn't it possible (legally) to deliver products with a replaceble > encryption library (dll). Delivery with a 40-bit key DLL. The user has > the option to install a dll with a different keysize. Somewhat like > winsock... > > Yes, I've seen the article suggesting a foreign office. I think an open > interface would do gooed for the whole field. I.e. ftp, telnet, etc. as > well. Actually, it's probably worse than you think: There are govt's out there that won't let you import code that is "encryption ready". You must prove that your software is tamper proof before it can be imported, and tamper proofing means that you can't bolt on security. Also, I believe the export laws disallow "plug in" security in the US... The crypto legal world sucks.

4 3

Re: EE Times on PRZ
by jalicqui＠prairienet.org 17 Dec '03

17 Dec '03

Hal wrote: >This, from a sidebar, is really surprising: "In contrast, public keys >allow the overt publication of an encryption key, because decryption keys >can only be derived through a mathematically difficult process, such as >large prime-number factoring. Contrary to popular belief, the NSA can >decrypt public keys of most practical key sizes." I wonder what this >means? If it is a claim that the NSA can factor 1024 bit moduli that >would certainly come as a big surprise. If they are saying that they can >do 512 bits that would be more believable although of interest. It is >strange that the author would include a statement like this without >attribution or evidence. Another quote from the article posted elsewhere said that, "PGP, which is based on the Diffie-Hellman public-key technology developed in the 1970s..." This is technically true, since all public-key work (including RSA) is based to some extent on DH. It could be, however, that the author is confusing public-key technology with Diffie-Hellman public-key in particular, which (as I understand it) is not particularly secure.

2 1