December 2003 - cypherpunks-legacy

Chicago Physcial Meet?
by snow 17 Dec '03

17 Dec '03

I was exchanging email with another member of the list late last week, and they brought up the possibility of a physcial meet for the greater Chicago Area Cyhperpunks. Would there be interest in such an event? Petro, Christopher C. petro(a)suba.com <prefered for any non-list stuff> snow(a)crash.suba.com

1 0

Re: Crypto-activism
by Deranged Mutant 17 Dec '03

17 Dec '03

BTW, Sent this message to you the other day. It was bounced back... ----- Unsent message follows ----- Received: from unix.asb.com by giasdl01.vsnl.net.in; (5.65v3.2/1.1.8.2/23Apr96-0134AM) id AA09399; Sat, 13 Jul 1996 10:32:46 +0500 Received: from magneto (sls17.asb.com [165.254.128.27]) by unix.asb.com (8.6.12/8.6.9) with SMTP id BAA16194 for <amehta(a)giasdl01.vsnl.net.in>; Sat, 13 Jul 1996 01:20:32 -0400 Message-Id: <199607130520.BAA16194(a)unix.asb.com> Comments: Authenticated sender is <wlkngowl(a)unix.asb.com> From: "Deranged Mutant" <WlkngOwl(a)unix.asb.com> Organization: What organization? To: Arun Mehta <amehta(a)giasdl01.vsnl.net.in> Date: Sat, 13 Jul 1996 01:03:41 +0000 Subject: PGP Key Priority: normal X-Mailer: Pegasus Mail for Win32 (v2.32a) Arun, No offense is meant at my posts, BTW. Just that I've seen seen some crazy schemes by activists who ignored the subtlety of some issues and do more harm than good. (Old pat phrase about road to hell being paved with good intentions...). Particularly with activists from "out-of-town" who claim to know what's better for the locals. Took a look at your home page,BTW. No public key on it, checked the servers. Also saw you graduated from SUNY in '76. Which school? (I've got a BA from SUNY Stony Brook recently, though not in comp-sci...) Peace, Rob -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQENAzF7Ci0AAAEH/2FiCb1r6C7QxMuExNo695h2qhiqkuS2EHrGyQ4gh+K1/4ha fXbXkHzeC0ifQSCTHPEknG/vCZP3ihkxTlwNaHE3GsSgu3e0o4uDDrz8mFWTEcTW mwjVGcDA2y0XBEc3Veh3hpVSTaKgYA12EcpQMzEAaICD/v8iezeDIRvAY8Jah/Wj 4dn1VF3RTYOm7ypTMLWDJQU2/cMk+TralJkMrSIhCE0GPU0JRAfjH/J2bl+5vxjF cC1JMSsY+LfgB8et3rSktdZzuudq08XQkPO79BL6U1ZqYjKwXWFKRNwP5XARDc+f 2pKBaCu0MN8kBoXOSvk4vJQpU6ATBM2VLF0/LpkABRG0JHdsa25nb3dsQHVuaXgu YXNiLmNvbSAocm9vdEBtYWduZXRvKYkAlQMFEDF7I67bHFCnqx9IMQEBJ3IEAJjp jcO91LnEGpQBWSR5liEHiAtkMH1kEVTOHFQsDQYF1Hb+ZIdbioIS6h4Il4NuHRZ5 ThtfCBs/jdNi2dtzVP6Isd1AsSSuRcyejeZblp1Ope71yrhV6uR7izHUGTK0GgHm xprq/E078oZdVB/73RNLM1qZdKW//4FoRLIZMOUBiQEVAwUQMXsSEwTNlSxdPy6Z AQEmrwf9FHSkUB+sTOIJhiLHfoJTETmEhKqFAjTs+4gRCCNiNSarLRyxF6lLRZDq lii02exIEgqzsiTlAta9nJ/ivnrtzcvhGxfXoOnbluuXa55HrosCXGjPt/XhZw++ p3iHKIox26M1cfe4WxAfD0HByvEn/uvNByTAh8aAqGqDxkDppZ6BnhMBlwXyAPaS bxGXzohOnKbg4oRTgO0932DUWU0uGX05Ab4jE+ZIGPT/w3cirHIRI+8vuNNrvuzE fG2RuI4Ns3hy0X9ZgP7hF+pRCWCQP/ak/HL38qegU90OlPFN8sdzS+qIaJROcT91 oMmPkUMgxdNcwhmqMqH2cQIj8pJhEJkAjQIr7lFeAAABBAC6rQ3ND8whLABFsDGN wYlIy9T4mqykqRT23hT1QIS9p+dSP8Zg3m8F5W4WsFfPBUqI0MsPGinYFzefq83V dEruPtFbnqKcbu1bjMAtjuFF6LSdEdOUlUdHE6YWOCZpcK6OmSrZKfrzlnmjaQ88 njTyqTwUsZAFfA3bHFCnqx9IMQAFEbQnRGVyYW5nZWQgTXV0YW50IDx3bGtuZ293 bEB1bml4LmFzYi5jb20+iQCVAwUQMMpQXdscUKerH0gxAQFNvAQAme7BCMGVUQCW CrdbnttRfZwSj6ryvhkIVYMcht2wtlpbEF/y2PxAbewWIBcPUCvJeyq1pViDcsbl 6gFLqKkaNA9okk0bAW0xZ5/qGIHmkkLkSnwOysdIExsrJykpKT/9Nrd11VKbrMXX tyMBDZR2c7GpyCVaud9XMS+Auuzb8vC0K1JvYmVydCBXYWxraW5nLU93bCA8cnJv dGhlbmJAaWMuc3VueXNiLmVkdT6JARUDBRAu/eFMbr6/n5nWRf0BAe1+B/9AePkd mJJVqb2XlX6uDC1/kGrSlRJlZp6Xy5NmKMcZG4KBI48MwWbGqxkr4iYTv0ep9+PV Jcd0mDuGTke3HSBffmpVEWHi/oBc1BpPBAVJPP8EX147yQXfn2SiyWQunDVZeFRy Ss1GLxgPR0JjaysmwoNcPL1RS3hpgPY81G+f+A35/q9vwC4i8+CnF4z0Rda3CUbg u1O9RngkbOAM6sJzEDJDJIonjEuKRtjOQShayR8sZbqVn09cOqXFRJ8T+1XLetW9 gtmKQNg4nQpm6xorqal7uZiHlksaKh1BweXm/iTwpNw2s0H53SbE6mX5IJo1r8/e +lUYvX/ygC/suAx1tDFOb3RlOiA8cnJvdGhlbmJAaWMuc3VueXNiLmVkdT4gZXhw aXJlcyBBdWd1c3QgJzk2iQCVAwUQMcT5OtscUKerH0gxAQFYZgQAo6LLlDLSuBF6 TlQjSH3yVuEh5hv8BZ0Jc6EcLlnC8brZD9k+sH0y0NknPcIVTzl5j3V+WCS0M2Pz bE4uZDEi7arfK3plhsU2JtGM9thl1LyaTvUyVR1ycvskJh3AMHvG+EhhfgLyngtE JLpKdFJSOoKPDRGTYyZ3jmtpN7p2vP60JlAuTy5Cb3ggMTMyNyBTdG9ueSBCcm9v aywgTlkgMTE3OTAgVVNB =aX7r -----END PGP PUBLIC KEY BLOCK----- --- No-frills sig. Befriend my mail filter by sending a message with the subject "send help" Key-ID: 5D3F2E99 1996/04/22 wlkngowl(a)unix.asb.com (root@magneto) AB1F4831 1993/05/10 Deranged Mutant <wlkngowl(a)unix.asb.com> Send a message with the subject "send pgp-key" for a copy of my key.

1 0

Stuffs used for detection
by Jerome Tan 17 Dec '03

17 Dec '03

In our school library, there is a depository area wherein you deposit your things and get the tag. Since the library doesn't allow those tags to be brought out from the library, everytime you brought it out and pass by the door, it will alarm. Does anyone know what stuff is that? How come it is alarmed? I brought some metals but it wouldn't alarm... Why those tag would alarm them???

1 0

Re: Execution of signed scripts received by e-mail
by Matt Carpenter 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Steffen Zahn <zahn(a)berlin.snafu.de> writes: > Matt> Get one input line at a time, and look for Reply-To: and > att> From: headers to get a reply address. As we are slurping up > Matt> lines, watch for '-----BEGIN PGP' lines. If it is for > >I suggest ignoring Reply-To: etc and requiring a return address inside >the signed region of the mail, otherwise someone could intercept the mail >(suppressing the original) and resend it from his account and the results >would get sent to the interceptor. This is a very good suggestion. I'll change emscrypt to use this. > Another idea would be to extract the return address from the PGP userid >which signed the script. I see that Mark M. has already commented on this, but I'll also add that I didn't want to limit the reply to the address attached to the key. For example, I have several accounts spread around, and I might want the replies to go to anyone of them. >Regards > Steffen Thanks for the input. - --Matt - -- mcarpent(a)mailhost.tcs.tulane.edu -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQEVAwUBMejLASjtJAMyBnp9AQEWyAf+IgmEApjh7CGo+sdCueH9BPQKLb9Dk7Qj 1HK7HoR8Dz/TnDPLicJgiaYj9z8gDfGLYWu2L4UIDIgQukb3o1JWOshTQAgyoCe9 gYxTYHvroNqMvq3ptPeeY73NVGsyTZnlcYJ/dlhWT90jReCZmIcrbpJNt+TIgGcm /s57Nw2zJzM8RrIWsCqs7gM0qogR2e71Gn4M+UFz9BfmMEw4X8qwZcD5M1//9VSi TqDjWnVucuUoWVZk+Bb6lKcxPwlAx6BxUZLaNaZrPlqvrSYJS4l451vgWkpcixSy Uuj+LU0cPd6qA3CHRHF4nllf3JcMP3uJeeWbmFjOZ+ItKkyQTSIVwQ== =JIXQ -----END PGP SIGNATURE-----

1 0

Re: Execution of signed scripts received by e-mail
by Matt Carpenter 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Hal <hfinney(a)shell.portal.com> writes: > > That sounds very impressive! The one problem I've run into with mail > filtering software is that each message asynchronously spawns a separate > filter process. This can cause some conflicts with accessing disk files. > I haven't used procmail so I don't know if it has this problem. But if > so you may need to be careful if there are any cases where two processes > could be accessing the same disk files. For example, what if two copies > of an identical email message arrive at almost the same time, would your > dup detection work. If I am reading the procmail docs correctly, then the following recipe should create a lockfile called 'emscrypt.lock' which will prevent more than one instance of the script from being run at a time :0:emscrypt ^ Subject.*SQUEAMISH OSSIFRAGE |/PATH/emscrypt I agree it would be better if emscrypt used its own locks on the timestamp files. However, it is my understanding (someone please correct me if I am wrong) that there is no simple way to provide file locking in Perl that is portable across the various flavours of Unix (see the descriptions of the fcntl and flock functions on p. 144-145 of the Camel book). So I haven't tried to implement locking from within emscrypt yet. Of course, if these functions are available on the majority of machines (anyone?) then I should probably use them. > The other issue is the possibility of mail arriving out of order. Looking > for increasing timestamps may cause spurious rejection of some messages. > On the other hand this is a difficult problem to handle in general so > probably the current solution is OK. Yeah, I though about that too. It can be somewhat alleviated by batching the individually signed scripts into a single mail message, if you know you are going to be submitting several scripts close together in time. Any other ideas? > > Hal > Thanks for the feedback. - --Matt - -- mcarpent(a)mailhost.tcs.tulane.edu -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQEVAwUBMejLIijtJAMyBnp9AQHnYgf6AkCfu7KLGKmJ6JNe0JscYkqWwHWGStFW 0u0dMrQekySy75iRqvyHJ789BhUj2gH5DhKBK97C0AhKj2jmv//7RALadqXOa73G 9nF31evxd+IItWaxeWbQQT9yNvEOz/bmLrz0bgH+GEwKHRFmUmwOObo4bw59M2bc EianNNT0Ig4tOcVt6kaxWm79PylQvDvtIxy6e3g0wIyg0gUI9vzGSa7S1y9PAJSB d60yJAfYKSEPGoab8fDbrTbJLMUfR1BYevdHrJxxCiuOj9uhIEfCnHua/P6k6tvP ZIa8Bz3jilq+AE/+CzBezk0IJmq7MEMQFJHyk/1AtKwY58x6xxWxuQ== =S64i -----END PGP SIGNATURE-----

3 2

Call for Papers
by weffross＠counsel.com 17 Dec '03

17 Dec '03

The American University Law Review encourages submissions for possible publication in its upcoming Symposium Issue on The Electronic Future of Cash. American University's Washington College of Law is now planning a full-day conference to accompany the publication of this issue in the Spring of 1997. Topics of interest include, but are not limited to: -- Consumer Protection. The relative advantages and disadvantages to consumers of debit cards, smart cards, on-line cash accounts, electronic checks, digital scrip, and other forms of electronic payment for "cash" transactions ("Electronic Cash"), especially as contrasted with payment by cash, paper checks, and credit cards. The current or potential application of consumer protection statutes and regulations to forms of Electronic Cash. -- Uniform Commercial Code. The extent to which the UCC and associated regulations already cover, or should be extended or modified to cover, Electronic Cash. -- "E-Bank" Regulation. The regulation of issuers of Electronic Cash. -- Criminality. The applicability and creation of laws concerning crimes (counterfeiting, money-laundering, electronic ransom payments, etc.) involving Electronic Cash. -- Privacy, Encryption, and Anonymity. The extent to which the privacy of merchants and consumers engaging in transactions with Electronic Cash can and should be legally protected. -- Security Concerns. Legal issues involving the protection of Electronic Cash systems from hackers, fraudulent participants, and other security threats. -- Microtransactions. Legal issues concerning the implementation and regulation of on-line systems that involve payments of small amounts of Electronic Cash by consumers to service or content providers. -- Interstate and International Aspects. (e.g., Jurisdiction, Choice of Law, Taxation). -- Role of the Federal Government. Should the Government be setting the ground rules for competition among systems and varieties of Electronic Cash? Selecting one or more systems for national implementation? Or just allowing the market to decide? Submissions should be approximately 100 double-spaced pages in length, written in traditional law review format with sufficient footnotes and documentation. Citations should conform to The Bluebook: A Uniform System of Citation (15th ed.1991). Papers should be received by The Law Review by October 1, 1996, and will be selected within two weeks of this deadline. Authors of papers accepted for publication will be expected to confirm within seven days after acceptance their agreement to contribute these papers to the Symposium Issue. Submissions should be made in hard copy to: The American University Law Review/Electronic Cash Symposium, Heather J. Russell/Senior Articles Editor, Washington College of Law, 4801 Massachusetts Avenue, N.W., Suite 617, Washington, DC 20016. Questions can be addressed to Professor Walter A. Effross, [voice] (202) 274-4210, [fax] (202) 274-4130, [e-mail] weffross(a)counsel.com.

1 0

[LONG,FUNNY,NOISE] Cypherpunk wannabe threatens a lawsuit :-)
by dlv＠bwalk.dm.com 17 Dec '03

17 Dec '03

Cypherpunks, I offer these two Usenet articles for your amusement. In article 1, I follow up on Bruce Bough's article, and, among many other things, defend his right to vote (questioned by the orthodox Jewish homophobe Dan Hartung). (It's very long and technical, so you can skip it.) In article 2, Bruce Bough follows up on my article and threatens to prosecute me under the Americans with Disability Act for misspelling his name. This is almost as funny as his litanies about his dementia and memory loss. Have fun. Article 1: =============================================================================== From: dlv(a)bwalk.dm.com (Dr. Dimitri Vulis) Newsgroups: news.admin.net-abuse.misc,news.admin.censorship,news.admin.policy,alt.config,news.groups,alt.journalism,atl.general,alt.culture.usenet,alt.internet.media-coverage,alt.wired,alt.cyberspace,talk.politics.misc,news.admin.net-abuse.misc,ga.general,misc.news.internet.discuss,soc.culture.russian,alt.flame.jan-isley,talk.forgery,alt.usenet.kooks,alt.grelb Subject: Re: Towards A Usenet Social Contract References: <4rpvfi$smg(a)doc.jmu.edu> <4rv6m7$3ns_002(a)mycroft.kenosis.com> Message-ID: <i6a1qD209w165w(a)bwalk.dm.com> Date: Sat, 13 Jul 96 09:25:41 EDT In article <4rv6m7$3ns_002(a)mycroft.kenosis.com>, bruce(a)kenosis.com (Bruce Baugh) wrote: >In article <4rpvfi$smg(a)doc.jmu.edu>, bumgarls(a)falcon.jmu.edu (Lee S. Bumgarner) wrote: > >>Is a little premeditation too much to ask for a smoothly working system? > >Yes. The _only_ info the voting process needs to know is whether the >voter is a unique individual. This is in practical terms not an >achievable task. But processes like serialized authenticated ballots at >least move in that direction. Voter registration that gathers _any_ info >beyond establishing the legitimacy of the address is a step in the wrong >direction. Information not in hand can't be abused, and I see great >potential for abuse of any sort of repository of information about voter >interests, preferences, etc. > >Further, any step toward increasing centralization seems to me counter >to the fundamental paradigm of Usenet, which owes its survival to its >decentralized nature. No system with anything like a real center could >have survived the growth of recent years. One of the last things we need >(in addition to info that can be put to abusive purposes being >collected) is any additional bottleneck. > >>in my opinion, prevents this system from being viable. If we have a >>registration system, then the cabal would be small, say 20 or so people. >>They would not be system admins, simply interested readers. > >I give you...news.groups. All that's necessary of this concept exists. >Further, by functioning in an ungoverned environment, it ensures that >what status people have is _earned_ by virtue of their views and >arguments. The current system is completely open to addition of new >figures to the pantheon. Again, centralization creates the potential for >bottlenecks. > >I don't trust _anyone_ with the power to establish a "cabal" of this >sort. I start with myself. Anyone who holds strong views of matters of >controversy faces the problem of bias, and anyone not informed enough >to hold views on them has no business selecting authority figures. I remember how someone recently argued on news.groups that Bruce Bough's votes should be invalidated because he's dying from AIDS. I strongly disagree with Dan's (?) reasoning, which was, I recall, that someone with only a couple of months left to live shouldn't be telling others how to run Usenet after his death. I think we should consider Bruce's opinions as being representative. After all, a Usenet vote is an interest poll, and the voters are just a sample of a larger population. Not everyone who thinks like Bruce Bough is going to die together with him from AIDS within a few months (sigh). Let him vote. The use of numbered ballots (as proposed by Dr. Grubor and implemented by me), will stop the following kinds of net-abuse: * Cabal supporters such as Russ Allberry (spit) e-mailing pre-filled ballots to their mailing lists, sometimes gathering tens of thousands of votes from people who haven't read the CFV; * Cabal supporters forging cancels to censor Usenet articles they claim contain "unauthorized voting instructions". This pretext has been used to stifle campaigning against the proposals the Cabal wanted to pass, as well as to suppress protests against UVV misconduct by Jan Isley (spit) and his cohorts. The use of a simple randomized question about the CFV - find the line that says this and fill in the missing word on the ballot (as proposed by Dr. Grubor and implemented by me), will stop the following kinds of net-abuses: * Cabal supporters such as Stephanie da Silva (spit) vote YES on every moderated newsgroup without reading the CFV; * Cabal supporters such as Chris Stein (spit) vote NO on every unmoderated newsgroup without reading the CFV. There can be no pre-filled ballots under Dr. Grubor's proposal. But Dr. Grubor's proposals don't address the issue of votetaker fraud. For example, we've exposed Jan Isley (spit) as a liar and a forger, who frivolously "invalidated" or "lost" votes from people he didn't like (including myself), and forged cancels for their protests on news.groups. Emory University called Isley's (spit) forgeries "reprehensible" and pulled his plug for net-abuse. The UVV's refusal to use numbered ballots and to ask (simple) questions about the CFV on the ballot is just a lame excuse. They really want to be able to forge cancels for protests posted to news.groups about votetaker misconduct. For example, of the following dozen votes I've cast, I've only received an ack for my NO vote on soc.culture.israel.moderated (fuck you, Jonathan Kamens). Where are the acks for the following ballots: 1. I e-mailed voting(a)hut.fi and wrote: I vote NO on soc.culture.israel.moderated I received an ack (thank you, Jani). 2. I e-mailed voting(a)hut.fi and wrote (ballot mark skipped): >Voter name: Dr. Dimitri Vulis > >| Insert YES, NO, ABSTAIN, or CANCEL inside the brackets for each >| newsgroup listed below (do not delete the newsgroup name): > > Your Vote Newsgroup > --------- ----------------------------------------------------------- >[ NO ] rec.arts.comics.marketplace.forsale >[ NO ] rec.arts.comics.marketplace.wanted So far, I received no ack. 3. I e-mailed voting(a)hut.fi and wrote: >I vote YES on rec.games.bridge.okbridge So far, I received no ack. 4. I e-mailed voting(a)hut.fi and wrote: >I vote YES on soc.adoption.parenting So far, I received no ack. 5. I e-mailed mtac(a)infobahn.net and wrote: >I vote NO on misc.transport.air-industry.cargo So far, I received no ack. 6. I e-mailed ccmp(a)infobahn.net and wrote: >I vote YES on comp.cad.microstation.programmer So far, I received no ack. 7. I e-mailed ceg(a)infobahn.net and wrote: >I vote YES on comp.emulators.game-consoles So far, I received no ack. 8. I e-mailed smo(a)infobahn.net and wrote: >I vote NO on sci.med.obgyn So far, I received no ack. 9. I e-mailed saf(a)infobahn.net and wrote: >I vote YES on sci.agriculture.net So far, I received no ack. 10. I e-mailed david.bostwick(a)chemistry.gatech.edu and wrote: >Give your real name here: Dr. Dimitri Vulis >If you do not give your real name, your vote may be rejected. > >[Your Vote] Group (Place your vote below in the brackets next to the group) >------------------------------------------------------------------------- >[YES ] comp.lang.dfl So far, I received no ack. 11. I e-mailed david.bostwick(a)chemistry.gatech.edu and wrote: >Give your real name here: Dr. Dimitri Vulis >If you do not give your real name, your vote may be rejected. > >[Your Vote] Group (Place your vote below in the brackets next to the group) >------------------------------------------------------------------------- >[ YES ] misc.invest.misc (renames misc.invest) >[ YES ] misc.invest.mutual-funds (renames misc.invest.funds) >[ YES ] misc.invest.options >[ YES ] misc.invest.marketplace So far, I received no ack. 12. I e-mailed dhartung(a)mcs.com and wrote: >Give your real name here: Dr. Dimitri Vulis >If you do not give a real name on the above line your vote may be rejected. > >[Your Vote] Group >----------------------------------------------------------------------- >[NO ] soc.religion.paganism So far, I received no ack. What's going on? Why are 11 of my ballots not being acknowledged? =============================================================================== Article 2: =============================================================================== Path: ...!newsfeed.internetmci.com!usenet.eel.ufl.edu!psgrain!rainrgnews0!news.aracnet.com!mycroft From: bruce(a)kenosis.com (Bruce Baugh) Newsgroups: news.admin.net-abuse.misc,news.groups,alt.usenet.kooks Subject: Re: Towards A Usenet Social Contract Date: Sun, 14 Jul 96 00:17:16 GMT Organization: Kenosis Design Lines: 29 Message-ID: <4s9eac$1ag_006(a)mycroft.kenosis.com> References: <4rpvfi$smg(a)doc.jmu.edu> <4rv6m7$3ns_002(a)mycroft.kenosis.com> <i6a1qD209w165w(a)bwalk.dm.com> NNTP-Posting-Host: ppp-u11.aracnet.com Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Newsreader: News Xpress 2.0 Beta #2 In article <i6a1qD209w165w(a)bwalk.dm.com>, dlv(a)bwalk.dm.com (Dr. Dimitri Vulis) wrote: >of a larger population. Not everyone who thinks like Bruce Bough is going to >die together with him from AIDS within a few months (sigh). Let him vote. Dimitri, I invite you to pick a date, not more than twelve months in the future, beyond which you're certain I will die. I will then post the next day. Not, of course, that I expect you to have the honor to admit now that you're deliberately misreading and misunderstanding my posts, nor to admit in the future that you made a claim demonstrably wrong. Nor, I see, can you spell my name correctly, even though you quote it routinely in reply lines and sig files. People who can't read what's in front of them on screen lose credibility when it comes to proposing sweeping changes and radical innovations in software. Further, you might want to read up on the Americans With Disabilities Act. Slanderous and defamatory statements about the handicapped - and my government agrees that I do have a real problem, though it's not AIDS - open you up to interesting liability. Bruce Baugh <*> bruce(a)aracnet.com <*> http://www.aracnet.com/~bruce See my Web pages for New science fiction by Steve Stirling and George Alec Effing er Christlib, the mailing list for Christian and libertarian concerns Daedalus Games, makers of Shadowfist and Feng Shui Unsolicited commercial e-mail will be proofread at $50/hour, min $100. ===============================================================================

1 0

setting up disposable remailers
by Adam Back 17 Dec '03

17 Dec '03

Some thoughts on solutions to the remailer operator liability problem. It occurs to me that the risk for the remailer owner could be reduced by separating concerns. That is, introducing separate roles for setting up the remailer so that the identity of as many parties as possible is not determinable to the litigator. Model 1 ------- Separable roles: - person owning the remailer - person installing remailer software - person handling complaints to the remailer In this model a new remailer owner would anonymously email a member of the cypherpunks list asking if they would be interested in installing a remailer in the owners provided account. The remailer owner would anonymously open an account with an ISP offering anonymous shell accounts, and accepting digicash, or cash, and anonymously email the account details to the installer. Optionally, a third party (the maintainer) could be persuaded to accept complaints for the remailer, and (anonymously) send signed instructions to the remailer to bar certain receiving addresses. The only determinable target for a typical litigator would be the ISP. If a more powerful adversary were the litigator, such as a TLA anxious to demonstrate an excuse for it's continued existance, it is possible they may retrieve the identity of the installer (if they do indeed have taps and large IP traffic recording facilities for instance). They may try to hold the installer responsible if unable to find the owner. Model 2 goes some way to reducing risk for the installer. Model 2 ------- In this model the additional separable role of setting up a shell command mail processor on the account is introduced. What I mean by this is as has been discussed on the list recently, that a mail handler which executes signed shell commands emailed, and anonymously emails back the command output. That is to say the remailer owner now passes the account information to the installer of the mail processor. The shell installer sets up the command processor, and leaves. Now the owner gives the PGP secret key of the command processor to the remailer installer (or if the owner feels competent, does this part themselves). Provided that the anonymous remailers used for all of the steps are type2 mixmaster remailers, the system should be much more secure. Adam -- #!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj $/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1 lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)

1 0

Encrypted file systems
by Adam Back 17 Dec '03

17 Dec '03

Some more thoughts on encrypted file system design criteria. A wish list: - Choice of secret key encryption algorithms (IDEA, 3DES, MDC, Blowfish) - Multiple architectures (MSDOS, Win31, Win95, WinNT, Unix, Mac) - High performance (hand optimised assembler for each architecture) - Compression - Ability to chain algorithms (IDEA and then 3DES for example) - Possible to have encrypted file systems on separate partitions, or - Encrypted file system located in a file in another file system (much like DOS stacker drives) this is an ease of use criteria -- I suspect re-partitioning drives would put off many potential users. - Ease of use. Graphical user interface for setup and administration functions, with a very simple set of configurations options displayed by default, with more advanced configuration options available in "expert" mode. - All directory and FAT information should be encrypted, so that it is not possible to discover even number of files, or percentage of disk used without the key - Facility for duress key, with the real data hidden in the unused space of the first encrypted drive. To increase the plausible deniability all unused blocks within a file system should be filled with garbage, so that it is not possible to tell if there is more data there. - File system steganographically hidden in files on another file system (encrypted or not). Support for a wide selection of file formats (Aiff, Wave, Midi, JPEG, GIF, RGB, MPEG). - Ability to use stegoed file system in files on an unencrypted file system, and boot from a floppy to access stegoed file system, with no other traces left on hard disk. Thought for the day: the main barrier for a Chinese dissident to using such software is that being caught with a boot floppy with the software for a stegoed drive would be dangerous. What would solve this would be if Microsoft, Apple, UNIX vendors, Slackware linux included this functionality (or this software itself as useful freeware included with the CD distribution) in their respective O/Ses as non-optional modules -- that is you get the software installed whether you want it or not. If everyone has the software, mere possesion of the software no longer is a problem. Throw in a few useful utilities, like a steganographic interface to anonymous remailers, the address of a few ftp/www by email services, and you have a system with interesting possibilities. To improve the national security of the US, the NSA should be dropping CDs with such software (much like war-time propoganda leaflets air dropped) on undemocratic countries with poor human rights records. Instead they expend their efforts on ITAR... Adam -- #!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj $/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1 lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)

3 2

Markoff on Clipper III
by Duncan Frissell 17 Dec '03

17 Dec '03

On the Friday "Clipper III" rehash by the Admin: Balancing Privacy and Official Eavesdropping By JOHN MARKOFF "The president and vice president took an oath to protect our national security," Simon said. "They feel they have to err on the side of protecting national security." The government also said that it did not see an immediate technical solution to the problems that would result from the global proliferation of "strong cryptography." ************** Last time I looked, the oath they took was to protect the Constitution -- not the nation or national security. I don't see an "immediate technical solution" to strong crypto either. Or, indeed, a long-term solution. DCF

1 0