December 2003 - cypherpunks-legacy

Re: Long-Lived Remailers
by E. ALLEN SMITH 17 Dec '03

17 Dec '03

From: IN%"tcmay(a)got.net" 21-MAY-1996 05:37:17.56 >At 4:56 PM 5/20/96, Rev. Mark Grant, ULC wrote: >>With regard to the problems of remailers being shut down when we want >>long-lived addresses, wouldn't seperating the input and output be one >>possibility? That is (like Hal's Alumni remailer) you'd send mail to >>'remailer(a)anon.ai' and it would be forwarded via a disposable account >>elsewhere. All messages would appear to come from 'disposable(a)foo.com' and >>if that account was shut down a new one could be opened to replace it >>while incoming mail simply backed up at the main remailer account. >This is a very good idea. Agreed. >Traffic analysis will be quite easy to do, of course, as all mail sent to >the persistent address comes out of the "disposable(a)foo.com" address. >Q.E.D. As has been pointed out since your message, one could logically have multiple remailers all using the same output account for messages. Extensions on this idea would be having them use it only for ones going to other than another remailer, to prevent the traffic from being noticed (if lots of traffic to remailers is coming out of one account, someone's going to notice...). Several people could run such output accounts, sending encrypted data on how to access the latest one(s) to (a subset of) remailer operators. (I say a subset in order to stop the NSA from running a remailer and letting, say, AOL know about each new output account on AOL. If some remailer or group of remailers wasn't told about a new output account, and the output account lasted statistically significantly longer (controlling for level of output), then that'd be cause for suspicion.) Which one was used for any given message through a particular remailer could be randomly chosen from those that remailer knew. Another aspect of this is that it would spread out the cost of operating the output account. One way to deal with this would be to have the postage going to the output account owner instead of to the remailer, or two items of postage (one to the remailer, one to the output account owner), or three items of postage (one to the first remailer in the chain, one to the last, and one to the output account). >(Hal, to use him as the example, could start using his own choice of >remailer hops to accomplish much the same result. We've talked about this >for a long time, too. If I ran a remailer, I think I'd route *all* traffic >leaving my site through at least one other remailer...kind of a "hot >potato" effect. Of course, if _everyone_ did this, an infinite loop would result. Lots of interesting twists, though, as messages could be set to "leak out" of the loops.) Oh? What's this idea? -Allen

1 0

Re: Long-Lived Remailers
by E. ALLEN SMITH 17 Dec '03

17 Dec '03

From: IN%"dsmith(a)prairienet.org" 22-MAY-1996 01:33:37.30 >Actually, there's an Idea. Set up a single address; use added >headers in the style of: >:: >Remailers-To-Chain: 7 >Remailers-To-Avoid: remailer(a)nsa.gov >Final-Destination: tcmay(a)got.net >Each remailer could construct a message that decrements the >remailers counter, preserving the other headers. The >usual caveat on encrypting at each step would apply; but since >remailers' pubkeys are available, that's a trivial concern. Well, if you use this for the entirety of the chain, you'll be giving away the cleartext at each step. Not too good of an idea. You won't want the mails to an output location to themselves go through remailers; you'd want multiple remailers going to the same output location (or group of output locations, which is probably preferable) via a more direct means such as POP. Otherwise, you've simply got the same old - but good nonetheless - of adding on new full remailers to the end of a chain, which doesn't avoid problems for the full remailer at the end. (Re: TCMay's post in response to yours.) -Allen

1 0

Re: Long-Lived Remailers
by loki＠infonex.com 17 Dec '03

17 Dec '03

At 5:39 PM 5/21/96, snow wrote: <SNIP> > > Randomize the output remailer? Sometimes Alice exits Bob, >Sometimes Charlie, sometimes Tom etc. > > >Petro, Christopher C. >petro(a)suba.com <prefered for any non-list stuff> >snow(a)crash.suba.com A list of reliable back end remailers (output) could be kept, and automatically used by the front end remailers. This would allow the back end remailers to be highly transient, but keep the remailers used in chains stable. A remailer would randomly choose one of the 99% reliable back end remailers for each outgoing message. This could be done even more disposably using alpha type nyms. Speaking of which, it looks like my nym server is working: alias(a)alias.cyberpass.net Send to help(a)alias.cyberpass.net for instructions and the key. -Lance ---------------------------------------------------------- Lance Cottrell loki(a)obscura.com PGP 2.6 key available by finger or server. Mixmaster, the next generation remailer, is now available! http://www.obscura.com/~loki/Welcome.html or FTP to obscura.com "Love is a snowmobile racing across the tundra. Suddenly it flips over, pinning you underneath. At night the ice weasels come." --Nietzsche ----------------------------------------------------------

1 0

Re: An alternative to remailer shutdowns
by loki＠infonex.com 17 Dec '03

17 Dec '03

Might Rot13 be enough? It would prevent accidental viewing. -Lance At 12:39 PM 5/21/96, Ben Holiday wrote: >After pondering a bit it seems to me that the "knock knock" remailer >approach (only send anon-mail if the recipient agrees to receive it) could >be made feasable pretty easily. > >Rather than hold the mail while waiting for a consent to release, you >could simply encrypt the peice of mail with a symetric algorythm on its >final hop, and send the encrypted mail to the recipient. > >At this point there are 2 options, which I havnt examined closely: The >first is that you require them to send a request for their "consent-code" >which can be used to decrypt the mail. Under this arrangment you could >possibly provide for a user to specify a specific consent code, so that 2 >party's who had previously agreed to communicate could avoid "knocking". >If you strip the subject, then it would be all but impossible for a person >to include the consent code in the actual peice of mail. > >The second is to simply include the >consent-code along with the encrypted peice of mail and a legal notice >stating that decryption of the mail constitutes your consent to receive >the mail, as well as your agreement to hold the remailer-operator harmless >should the mail be found to be in some way offensive. Further, the >recipient would agree to be solely liable for the contents of the mail, >etc etc.. I leave the actual agreement to the net.lawyers to figure out. > >As far as I can tell an agreement of this form would be at least as valid >as the software licenses ("NOTICE: Opening this envelope constitutes your >agreement to the terms.. blah blah blah") that are commonly used today. >Also would seem to be a similar concept to "Opening the case of this >device void's your warranty" stickers on appliances. > >Under this approach persons would receive mail whether they'd consented or >not (unless they requested to be blocked). But it would be difficult for >anyone to raise any serious legal issues about something they havnt read, >and impossible for them to make noise about what they read, after the >implied consent they gave when decrypting. > >Under both approaches it would be wise to have a list of addresses who've >already consented, which would contain all of the known remailers.. >whether or not an operator chose to have names besides remailers in the >list would be at his/her discretion. > >Ben.. ---------------------------------------------------------- Lance Cottrell loki(a)obscura.com PGP 2.6 key available by finger or server. Mixmaster, the next generation remailer, is now available! http://www.obscura.com/~loki/Welcome.html or FTP to obscura.com "Love is a snowmobile racing across the tundra. Suddenly it flips over, pinning you underneath. At night the ice weasels come." --Nietzsche ----------------------------------------------------------

1 0

Re: MixMaster fair use
by loki＠infonex.com 17 Dec '03

17 Dec '03

At 9:14 PM 5/21/96, E. ALLEN SMITH wrote: >From: IN%"loki(a)infonex.com" 21-MAY-1996 17:19:02.59 > >>The problem is RSAREF. I can't chose license terms for that. > > Oof... I see the problem. No, it's not you, it's them. I've forgotten >exactly what claims RSA has; patent (when does it expire?), copyright (can >it be rewritten), or trade secret (wasn't it broken?)? Without some form of >getting around this (or licensing from them), usage for pay will be kind of >difficult. > -Allen It is patent on RSA, which expires in 2000 as I remember. It can be licensed, but it is not cheap. I don't know how they would handle a free program which people pay to use. -Lance ---------------------------------------------------------- Lance Cottrell loki(a)obscura.com PGP 2.6 key available by finger or server. Mixmaster, the next generation remailer, is now available! http://www.obscura.com/~loki/Welcome.html or FTP to obscura.com "Love is a snowmobile racing across the tundra. Suddenly it flips over, pinning you underneath. At night the ice weasels come." --Nietzsche ----------------------------------------------------------

1 0

Clipper III analysis
by John Gilmore 17 Dec '03

17 Dec '03

I just read over the Clipper-III paper. Here's the main scoop. The Government is trying to force key escrow on the world by incorporating it into key certification systems. They are playing on public ignorance of key certification, and are trying in some cases to deliberately mislead people into thinking that key certification and key escrow are the same thing. Key certification is a way for a third party to declare that a particular public key "belongs to" a particular identity. E.g. that key 85197FB5 really belongs to John Gilmore. In PGP, people who know you can "sign" your key to make this declaration. Then, anyone who trusts those people will know that your key is really yours. When they encrypt mail with public key 85197FB5, they can believe that only John Gilmore can read it. Key certification NEVER involves giving anyone a copy of your *private* key. Your private key is, and always should be, private to yourself and nobody else. Key escrow is a way for governments to get access to your private key and read your private communications whenever they don't like what you are doing or saying. Or for any other reason. So far, the only government that is really pushing for this is the US government. Their published policies for when they will access your key are disturbingly non-specific. I believe this is to cover for access by the spy agencies such as NSA, which the public would not sanction if it knew their current policies. Even if the published policy for accessing your escrowed keys required that a judge issue a warrant based on probable cause to believe a crime has been committed -- which it doesn't -- that provides no protection from a government that feels free to make any harmless act into a crime. As in the Soviet Union, lofty principles can be written into the legal documents, but somehow citizens end up without enforceable rights anyway. I don't want to see my country go this route, though it's obviously 80% of the way there already. Because large-scale key certification systems will to some degree involve centralization, they provide pressure points where the government can try to force people to do bad things. (One thing that has kept the Internet free is that there was no central place to sue, arrest, threaten, or otherwise terrorize into submission.) In this case, the bad thing they'll try to force is that the central certification authorities will refuse to certify your key as yours, even though they know it's yours, unless you first give the government a copy of your private key. Foreign relations are important to this policy, since if a significant number of countries don't adopt this model then it won't work. (Those countries will build good crypto and export it, and it will leak out around the world because of the worldwide demand for real privacy.) The US is working hard in the OECD, the European Community, and in one-on-one discussions with other governments, to convince them all to impose key escrow on their citizens. That's the scenario laid out by the Clipper-III paper. It's a pretty good strategy on their part. Our job is to make it come out some other way. John Gilmore PS: The whole paper is at http://www.eff.org/pub/Privacy/Key_escrow/ Clipper_III/960520_nist_clipper3_paper.draft.

1 0

Re: SEVERE undercapacity, we need more remailer servers FAST (fwd)
by hendersn＠zeta.org.au 17 Dec '03

17 Dec '03

>Had he posted it through a remailer, I think it would have been well >justified. He was obviously blowing the whistle on what he saw as illegal >activities. The only reason that Keith could post NOTS 34 at all was because it had previously been posted to a.r.s anonymously. Prior to that, no-one outside of the Church had a copy of any NOTS materials(or so the Church says). > That's a much different matter than posting the entire NOTs >series, though. The wholesale copying is what most people seem to object >to, though my observations tell me that the "Church" objects to any >copying, even for fair use... Grady Ward got sued by the Church just because he _asked_ for a NOTS pack to be sent to him. The Church will do everything within its not inconsiderable power to prevent NOTS material being disseminated on the Internet - up to and including destroying the anonymous remailer network. Zed(hendersn(a)zeta.org.au) "Don't hate the media, become the media" - Jello Biafra PGP key on request

1 0

DC area physical meeting, this saturday
by Pat Farrell 17 Dec '03

17 Dec '03

Appologies to the 1000+ folks who are too far away to care about this... The next Washington DC area cypherpunks physical meeting will be this saturday, May 25 at 3:00 PM, at Digex.net. Details, directions, etc. at http://www.isse.gmu.edu/~pfarrell/dccp Pat Pat Farrell Grad Student http://www.isse.gmu.edu/~pfarrell Info. Systems & Software Engineering, George Mason University, Fairfax, VA PGP key available on homepage #include <standard.disclaimer>

1 0

Re: The Twilight of the Remailers?
by middle-man-admin＠alpha.c2.org 17 Dec '03

17 Dec '03

On Tue, 21 May 1996, Timothy C. May wrote: > At 7:59 PM 5/21/96, Alex Strasheim wrote: > >I'm closing my mixmaster, nsa(a)omaha.com, on the 4th of June. > Between Hacktic going down, Hal's comments that he may shut down his two > sites, and this, plus others who are more quietly making plans to shut > down, I think the thread title "The Remailer Crisis" is more apt than ever. I tend to agree. I realize that the middle-man remailer requires that there be bastion remailers on the end of the chain. Without them, the "middle-man" concept won't work. I thank the remailer sites the allow the middle-man to work. Anyway, with all the remailers that have either vocalized their retirement and those that are silently considering retirement, I would like to announce that the middle-man remailer should be available for download as early as this weekend. Utopia.hacktic.nl (basement) and c2.org have agreed to carry the middle-man remailer on their FTP sites. As soon as I can get the documentation finished, I'll post it. middle-man-admin

1 0

Re: Remailers, Copyright, and Scientology
by jim bell 17 Dec '03

17 Dec '03

At 07:36 PM 5/21/96 -0500, Allen Ethridge wrote: >Yes, the cult does have a legitimate interest in protecting their >copyrights. I'm wondering whether they properly handled the copyright status of some of those (silly) texts. While it is somewhat nice of you (in regards to them) to say what you did, it is possible that they lost their copyrights decades ago by printing them (even internally) without the (then) appropriate "circle-C" copyright notice. Chances are good that none of this material could survive a genuine copyright test case today. Jim Bell jimbell(a)pacifier.com

2 1