- cypherpunks-legacy - lists.cpunks.org

<>
by Anonymous 17 Dec '03

17 Dec '03

1 0

Re: Navy hacked by Air Force?
by RobL 17 Dec '03

17 Dec '03

At 04:58 PM 12/22/95 -0500, Vin McLellan wrote: > Drescher/Cohen/Drescher/Drescher/Cohen/Cohen.... > > I'm new to C'punks, so I don't yet have a grip on the context in >which you consider privacy, property, and other ultimate values. I do >wonder, though: Do you spend a lot of time pissin' on each other's shoes >like this? Laughing my ass off here.. not yet I have seen someone so precisely hit the nail on the head.. Seems this is happening a lot lately.. must be the tension of the holiday season.. <g> Guess I need to start adding plastic shoe-guards to the C-punk kit.. ;) ------------------|----------------------------------------------------------- Rob Lowry | PO Box 288 | Rockford Wa 99030 | ral(a)otc.mhs.compuserve.com robl(a)on-ramp.ior.com

1 0

(fwd) Java implementation of secure login protocol
by Adam Shostack 17 Dec '03

17 Dec '03

Look, Ma! Java code! Real cyph3rpunks, of course, flame each other anonymously. (Incidentally, I got tired of Alice making it to my noise box, and the following seems to work well. Deleting the leading ^ characters would cause all responses to go into the junk box; perhaps a good idea. This is, for those of you who don't recognize it, procmail code. My mail filter of choice for hacking in.) :0B: * ^Alice de 'nonymous * ^P.S. This post is in the public domain. | formail -a "Status: O" >> cjunk > From: greg(a)qualcomm.com (Greg Noel) > Newsgroups: comp.lang.java,sci.crypt > Subject: Java implementation of secure login protocol > Date: 19 Dec 1995 23:12:52 -0800 > Organization: QUALCOMM, Incorporated; San Diego, CA, USA > Lines: 64 > Message-ID: <4b8d1k$6o9(a)qualcomm.com> > NNTP-Posting-Host: guru.qualcomm.com > > Please note that this article is cross-posted both to comp.lang.java and > sci.crypt. If you follow up, please trim the newsgroups appropriately. > > Since a number of people expressed interest, I'm releasing an initial > implementation of a secure login protocol in Java. This is still very > much a work in progress (it's not really even of alpha quality), but > the protocol itself is functional. > > It's intended that the classes in crypto.* and qualcomm.qbs.login.* > live on the client; any other classes needed would be downloaded over > the encrypted link. Hopefully, the client-resident classes will be > few in number and change rarely; they are just intended to bootstrap > up the connection. In the long run, the classes in crypto.* could be > provided by the vendor of the Java VM. > > The distribution consists of two files: > ftp://ftp.qualcomm.com/pub/gnoel/java.login.tar.gz > ftp://ftp.qualcomm.com/pub/gnoel/java.no-export.tar.gz > The first file contains the logic to execute the protocol and launch > the splash screen (see below); it also contains the base classes from > crypto.* but no cryptographic functions. The second file contains the > base classes and the actual implementations of a few cryptographic > functions to demonstrate how the base classes can be used. > > For sci.crypt, I've tried to capture the essence of what cryptographic > functions can do in the base classes, without being specific to any > particular protocol. I'm not completely happy with it, and would welcome > any comments people might have on what might be missing. It's as minimal > as I could make it and still provide a basis for whatever protocols need > to be implemented. > > My motivation here is that Sun and Netscape are talking about defining > a standard way of incorporating cryptographic functions in Java; it would > be nice if the specification were usable for a lot more than the security > protocols that come with Netscape. (I wouldn't object to having access > to SSL from Java---in fact, I'd really like it---but I'd also like access > to MD5 and the like.) > > This implementation of the secure login protocol uses short text strings > to identify the packets being exchanged; that's for convenience while > debugging---in a production implementation, it would be done differently. > Other than that, I'd appreciate any suggestions as to how to improve the > implementation. (A MAC digest prefixed to the packets is something I'm > considering, for example.) > > For comp.lang.java, the splash screen is loaded over the secure connection > but attempts to instantiate a member of the class cause a NoSuchMethodError > to be thrown. The class itself seems to be defined correctly, and it should > be no different from how an applet would be loaded and instantiated, but it > still fails. If anyone can tell me what is going wrong and what I can to > to fix it, the pizza and beer will be on me. (This has been a showstopper > for four days now and I'm getting very frustrated by it.) > > The class design tries to minimize the number of classes that must be > present in the bootstrap set; this led to a somewhat, ah, baroque set of > functionality. If anyone has suggestions on how this could be done better, > I'd be pleased to hear about it. > > If anyone has any questions about this, don't hesitate to drop me a line > or post something in one of the newsgroups. I'm going home for some sleep > now, but I'll be banging my head against it again in the morning. > > -- > -- Greg Noel, UNIX Guru greg(a)qualcomm.com or greg(a)noel.cts.com

1 0

Re:
by stevenw＠best.com 17 Dec '03

17 Dec '03

>On Fri, 22 Dec 1995 andr0id(a)midwest.net (Jason Rentz) wrote: >> >>The problem with the Interceptor is that I think it can only receive one >>freqency at a time, and it is adjustable by a thumb wheel, not digitally. >>This would tend to make changing frequencies at high rates VERY hard. :) >>Also it has no frequancy readout, so this means that if you know what freq. >>you should be at it is hard to tune in that freq. without searching a >>little. >> Dr0id > >The demo of the Interceptor I saw seemed to show it jumping from 150 MHz >to 450 >MHz without any external adjustments, it locked on the strongest signal. >Granted, it can only receive one frequency at a time, but there shouldn't >be any >significant delays when the phone hops a frequency. The Interceptor's >frequency readout is a bargraph style LED. The Scout, from what I can >see in Optoelectronics' ad doesn't have any frequency controls on it, it does >have a digital frequency readout. As far as timing is concerned, the Scout >might be less useful because I think it feeds the frequency into the >scanner for >reception. Most scanners take a significant amount of time to change >frequencies. I used to work for a company that made frequency-hopping military radios. It's a catch-me-if-you-can game, a bit like the amusement arcade toy where stuffed rats pop up through holes and you try to whack them with rubber hammers. You can sure *see* where the next one is, but you can't get there fast enough to make contact. If you knew the pseudo-random pattern, you could anticipate and be there every time. Thus in a frequency-hopping radio you can push the retuning (read RF phase-locked loop) technology to its limit and build transmitters and receivers around them. These typically hop in the order of 100 times a second. The adversary has to find the uncorrelated signal very quickly indeed *and* have PLL technology at least as good as yours to recover anything from it. Finding the signal generally means listening to all frequencies at once, requiring huge amounts of hardware parallelism and/or realtime computing power. Once you throw ten or so radios onto the same band, it's no longer any use looking for the strongest signal, making that approach useless. The primary reason for FH is not to hide information, however. Encryption can be used for that. It's to prevent the enemy from hiding the information from the intended recipient through jamming. Radio jammers work by simply drowning out all other traffic so that the receivers either clip and distort everything or have to attentuate the input signal so far that the interesting stuff is undetectable. Like trying to have an intellectual conversation at a bad rock concert. By employing FH you require the enemy to have enormous and impractical jamming capacity. There are FH radars too. ------------------------------------------------------------------------- Steven Weller | "The Internet, of course, is more | than just a place to find pictures | of people having sex with dogs." stevenw(a)best.com | -- Time Magazine, 3 July 1995

3 2

Re: ex encrypted script
by jim bell 17 Dec '03

17 Dec '03

At 08:57 PM 12/21/95 -0800, you wrote: > >There is encrypt and then there is render useless to the reader. > >A tale I hear is that when HP had to deliver operating system source to >the french government they stripped all comments and changed all variable >and subroutine names to 32 byte strings of I 1 0 (zero) and O (uppercase O). >It still compiled but was 100% useless to human readers. >John Pettitt >email: jpettitt(a)well.sf.ca.us (home) > jpp(a)software.net (work) This is EXACTLY the kind of creative uncooperativeness that I was thinking of, on a different subject, when I proposed that Netscape do anything it could think of (legally) to sabotage, undermine, subvert, escape, and otherwise stifle any attempt by the US government to restrict crypto in general, or its export in particular. The fact is, we are all CREATIVE people, and presumably given any particular set of rules (laws) , it should be possible for us to "comply" with "the law" in such a way as to be as obstructively obnoxious as possible.

3 2

(fwd) Benchmarks - revs 1.3.50 & 51
by Julian Assange 17 Dec '03

17 Dec '03

Path: news.apana.org.au!goliath.apana.org.au!sysx.apana.org.au!sleeper.apana.org.au!greathan.apana.org.au!news-mail-gateway From: fluido(a)marktest.pt (Carlo Emilio Prelz) Newsgroups: apana.lists.os.linux.kernel Subject: Benchmarks - revs 1.3.50 & 51 Date: Thu, 28 Dec 1995 08:05:17 +0100 (MET) Organization: Mail-to-News Gateway Lines: 158 Sender: daemon(a)greathan.apana.org.au Approved: usenet(a)greathan.apana.org.au Distribution: apana Message-ID: <Pine.LNX.3.91.951228075225.11217A-100000(a)pimpinel.fluido.org> NNTP-Posting-Host: greathan.apana.org.au Hi. Here follow the benchmark comparisons w.r.t. revisions 50 & 51. I decided to wait before posting rev 50 before because the file read & write results again bounced up with it, and I spent some (very little) time trying to see if I could have done anything to cause that. With no results, as usual. Now I also have results for the "greased weasel", and I decided to send out my numbers for what they're worth. Not much has changed with the latest release... I repeat my query: if anybody has suggestions about these huge jumps in disk performance, please let me know. I am ALWAYS running the benchmark test after a reboot. I login as root, start the process in background and log out, and then generally go to sleep. The machine is NOT online, and is not doing anything important at night. I have not changed anything in the kernel config in the latest 3 revisions. I have a plain old ISA disk controller, and two generally fullish disks, but again, the situation did not change notably between 1.3.49 and 1.3.50. And, I now have to admit that I find it faster, for example, to load a huge C file into emacs, and have it do the syntax coloring. I noticed it this morning. No problems in patching & compiling. --8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<-- From: * Linux pimpinel.fluido.org 1.3.49 #77 Fri Dec 22 21:05:57 MET 1995 i486 * Fri Dec 22 21:41:03 MET 1995 To: * Linux pimpinel.fluido.org 1.3.50 #78 Mon Dec 25 11:18:00 MET 1995 i486 * Mon Dec 25 12:11:11 MET 1995 ******* Results ******* File Write (30 seconds) || 1000.0 -> 9460.0 +846.00% File Write (10 seconds) || 1200.0 -> 8070.0 +572.50% File Copy (30 seconds) || 968.0 -> 2636.0 +172.31% File Copy (10 seconds) || 1024.0 -> 2645.0 +158.30% Execl Throughput Test || 67.9 -> 85.3 +25.63% C Compiler Test || 48.7 -> 51.9 +6.57% Pipe-based Context Switching Test || 9863.0 -> 10493.0 +6.39% Process Creation Test || 347.7 -> 368.9 +6.10% Shell scripts (1 concurrent) || 96.4 -> 101.9 +5.71% Shell scripts (4 concurrent) || 25.5 -> 26.5 +3.92% Shell scripts (2 concurrent) || 50.8 -> 52.6 +3.54% System Call Overhead Test || 29945.4 -> 30523.5 +1.93% Dhrystone 2 using register variables || 49658.9 -> 49910.8 +0.51% Arithmetic Test (type = int) || 8365.0 -> 8377.5 +0.15% Arithmetic Test (type = double) || 5063.6 -> 5071.1 +0.15% Recursion Test--Tower of Hanoi || 726.1 -> 727.1 +0.14% Arithmetic Test (type = arithoh) || 127103.2 -> 127265.6 +0.13% Arithmetic Test (type = short) || 7508.8 -> 7515.5 +0.09% Arithmetic Test (type = register) || 8367.3 -> 8372.8 +0.07% Arithmetic Test (type = float) || 5066.8 -> 5069.3 +0.05% Arithmetic Test (type = long) || 8371.8 -> 8372.1 +0.00% Shell scripts (8 concurrent) || 13.0 -> 13.0 +0.00% Pipe Throughput Test || 17850.0 -> 17726.9 -0.69% Dhrystone 2 without register variables || 51001.9 -> 49772.1 -2.41% File Read (30 seconds) || 4613.0 -> 4404.0 -4.53% File Read (10 seconds) || 4648.0 -> 4390.0 -5.55% Dc: sqrt(2) to 99 decimal places || 11886.7 -> 10822.2 -8.96% --8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<-- From: * Linux pimpinel.fluido.org 1.3.50 #78 Mon Dec 25 11:18:00 MET 1995 i486 * Mon Dec 25 12:11:11 MET 1995 To: * Linux pimpinel.fluido.org 1.3.51 #79 Wed Dec 27 19:16:06 MET 1995 i486 * Wed Dec 27 22:41:23 MET 1995 ******* Results ******* File Read (30 seconds) || 4404.0 -> 4548.0 +3.27% File Read (10 seconds) || 4390.0 -> 4516.0 +2.87% Dc: sqrt(2) to 99 decimal places || 10822.2 -> 11034.2 +1.96% Process Creation Test || 368.9 -> 375.0 +1.65% File Copy (10 seconds) || 2645.0 -> 2683.0 +1.44% File Copy (30 seconds) || 2636.0 -> 2669.0 +1.25% Shell scripts (4 concurrent) || 26.5 -> 26.8 +1.13% C Compiler Test || 51.9 -> 52.4 +0.96% Dhrystone 2 without register variables || 49772.1 -> 49808.7 +0.07% Arithmetic Test (type = long) || 8372.1 -> 8376.6 +0.05% Arithmetic Test (type = register) || 8372.8 -> 8376.1 +0.04% Arithmetic Test (type = float) || 5069.3 -> 5069.9 +0.01% Arithmetic Test (type = short) || 7515.5 -> 7515.7 +0.00% Shell scripts (8 concurrent) || 13.0 -> 13.0 +0.00% Arithmetic Test (type = double) || 5071.1 -> 5067.4 -0.07% Arithmetic Test (type = arithoh) || 127265.6 -> 127172.0 -0.07% Dhrystone 2 using register variables || 49910.8 -> 49870.6 -0.08% Arithmetic Test (type = int) || 8377.5 -> 8370.4 -0.08% Recursion Test--Tower of Hanoi || 727.1 -> 724.3 -0.39% Shell scripts (2 concurrent) || 52.6 -> 52.3 -0.57% Shell scripts (1 concurrent) || 101.9 -> 101.2 -0.69% File Write (30 seconds) || 9460.0 -> 9356.0 -1.10% Pipe Throughput Test || 17726.9 -> 17227.1 -2.82% Pipe-based Context Switching Test || 10493.0 -> 10194.8 -2.84% System Call Overhead Test || 30523.5 -> 29476.8 -3.43% Execl Throughput Test || 85.3 -> 81.5 -4.45% File Write (10 seconds) || 8070.0 -> 7680.0 -4.83% --8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<-- From: * Linux pimpinel.fluido.org 1.2.10 #59 Tue Jun 13 09:46:17 MET DST 1995 i486 * Tue Jun 27 10:18:13 MET DST 1995 To: * Linux pimpinel.fluido.org 1.3.51 #79 Wed Dec 27 19:16:06 MET 1995 i486 * Wed Dec 27 22:41:23 MET 1995 ******* Results ******* Process Creation Test || 119.9 -> 375.0 +212.76% Pipe-based Context Switching Test || 3446.9 -> 10194.8 +195.77% Dc: sqrt(2) to 99 decimal places || 5906.2 -> 11034.2 +86.82% Execl Throughput Test || 51.6 -> 81.5 +57.95% Shell scripts (8 concurrent) || 10.0 -> 13.0 +30.00% Shell scripts (1 concurrent) || 78.3 -> 101.2 +29.25% Shell scripts (4 concurrent) || 21.0 -> 26.8 +27.62% Shell scripts (2 concurrent) || 41.0 -> 52.3 +27.56% C Compiler Test || 42.2 -> 52.4 +24.17% Dhrystone 2 without register variables || 46284.2 -> 49808.7 +7.61% File Write (30 seconds) || 8911.0 -> 9356.0 +4.99% Recursion Test--Tower of Hanoi || 709.2 -> 724.3 +2.13% System Call Overhead Test || 29238.2 -> 29476.8 +0.82% Arithmetic Test (type = float) || 5055.6 -> 5069.9 +0.28% Arithmetic Test (type = long) || 8353.5 -> 8376.6 +0.28% Arithmetic Test (type = register) || 8353.2 -> 8376.1 +0.27% Arithmetic Test (type = short) || 7496.0 -> 7515.7 +0.26% Arithmetic Test (type = double) || 5056.8 -> 5067.4 +0.21% Arithmetic Test (type = int) || 8353.4 -> 8370.4 +0.20% Arithmetic Test (type = arithoh) || 126914.4 -> 127172.0 +0.20% Dhrystone 2 using register variables || 49802.4 -> 49870.6 +0.14% File Write (10 seconds) || 8100.0 -> 7680.0 -5.19% Pipe Throughput Test || 18512.0 -> 17227.1 -6.94% --8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<-- Enjoy! Carlo -- * ...Ma appena fuori tutto e' gomma, * K * Carlo E. Prelz - fluido(a)marktest.pt tutto e' cicca impiastricciata... * (Marco Zappa-Niente cicca nella scuola) -- +----------------------------------+-----------------------------------------+ |Julian Assange | "if you think the United States has | |FAX: +61-3-9819-9066 | has stood still, who built the largest | |EMAIL: proff(a)suburbia.net | shopping centre in the world?" - Nixon | +----------------------------------+-----------------------------------------+

1 0

Re: Navy hacked by Air Force?
by anonymous-remailer＠shell.portal.com 17 Dec '03

17 Dec '03

On Fri, 22 Dec 1995, Vin McLellan wrote: > This might be relevant. This is a page from the NCCOSC web site > <http://www.nosc.mil> Thanks for posting this. It was very helpful. > The Naval Command, Control & Ocean Surveillance Center (NCCOSC) > is the U.S. Navy's warfare center for command, control and communication > systems and ocean surveillance and the integration of those systems which > overarch multiplatforms. NCCOSC is based in San Diego, CA. > > Note that NCCOSC recently decided to beef up NCI's user > authentication. See "Current Initiatives." Duly noted ... (as long as it don't lead to a false sense of security) > [* ] NCI net - What it is > > * An enterprise network serving NCCOSC and other communities of interest > * Modelled after the global Internet, logically part of the Internet ... > * Provides ubiquitous high-speed low-delay TCP/IP connectivity throughout > the organization and to the Internet > * Provides dialup access from home or TDY via 1-800 number, including > SLIP and PPP support Betchya that WATS line gets a whole lotta billings to it. <p> > * MIME adopted as corporate email standard, email systems upgraded > o Many user agents upgraded to MIME compliance > o Testing gateways for interoperability with non-compliant systems > o Performing extensive interoperability tests MIME??!!?? They adopted MIME??!!?? Good grief. This is not good ... not good at all. > * New sites connected > o CINCLANTFLT, Norfolk, VA > o The Pentagon > + BRAC Office > + OSS LAN > + DASN/C3I Oh no ... it's worse ... *sigh* ... no wonder that Newt and Dole had such a grim look on their faces when they emerged from their scheduled one-hour, (went for two) meeting with the US President -- the one that was the day before the freshman congress persons did their incredible end-run on their own leadership. Impressive. Truly. What would have caused both Newt and Dole to flush like they did? Did they demo a hack into the personal e-mail of the Vice-Chairman of the JCS? > * New Web server installed > o "neelix", a Sun SparcServer 1000, installed outside firewall > o "www.nosc.mil" now points at neelix Pretty firewall ... nice firewall ... <p> > * Enhancing Infrastructure to provide ISDN dialup service Good idea. ISDN dialup provides significant bandwidth. Very significant bandwidth. Almost enought to control a battleship. (If there were any battleships, I mean). > * Upgrading D.C. area connectivity to Metropolitan Fiber service at 10 > Mbps > * Getting sites 100% connected (TCP/IP to every desktop) > * Developing MIME to X.400 gateway for connectivity to DMS world Yep. Perfect. Just what the doctor ordered. TCP/IP to every desktop. And MIME for all. Oh, and to ice the cake, toll-free ISDN dial-ins. Hmm, let's see ... for Christmas Santa ... I'd like a packet-switched network with a public outdial to a toll-free ISDN dial-in ... oh, that and a Gulfstream V under the Christmas tree. What are they going to do next, give everyone some Czechoslovakian C-4? Stick a bit of civilian software into all of this, and let's all have a good look at whether someone can take over something a little more interesting than a battle ship. Like maybe an aircraft carrier?? Gee, that oughta harden their drawers ... Alice de 'nonymous ... <an455120(a)anon.penet.fi> ...just another one of those... P.S. This post is in the public domain. C. S. U. M. O. C. L. U. N. E. P.P.S. Feel free to repost widely ... IW ... c4i-pro ... wherever ...

1 0

Re: cyphernomicon FTP site?
by Bill Stewart 17 Dec '03

17 Dec '03

At 09:07 AM 12/20/95 -0800, you wrote: >At 12:59 AM 12/20/95 -0800, you wrote: >>At 9:18 PM 12/19/95, Vinod Valloppillil wrote: >>>Anyone know where I can FTP a full copy of the cyphernomicon? >[Much deleted] >>Anybody who plans to download the entire linear file and then print it out >>must be missing a bits in his shift register. > >There are reasons to want a non-html version. The best being uploading to >your favorite text-oriented BBSes. (Or crypto-oriented BBSes.) Not >everyone has access to the web. (Yes, I know it is blasphemy...) It's also nice to be able to read it offline, or feed it to grep, or load copies of it to other sites to reduce congestion on Netcom... #-- # Thanks; Bill # Bill Stewart, stewarts(a)ix.netcom.com, Pager/Voicemail 1-408-787-1281 # .... Heading back to The Big Phone Company

1 0

ACLU Cyber-Liberties Update, 12/22/95
by Lynnclu＠aol.com 17 Dec '03

17 Dec '03

---------------------------------------------------------------- December 22, 1995 ACLU CYBER-LIBERTIES UPDATE A bi-weekly e-zine on cyber-liberties cases and controversies at the state and federal level. ---------------------------------------------------------------- IN THIS ISSUE: * ACLU Letter to U.S. Senators Opposing the Telecommunications Deregulation Bill, S. 652 (H.R. 1555) As Reported by the Conference Committee ---------------------------------------------------------------- FEDERAL PAGE (Congress/Agency/Court Cases) ---------------------------------------------------------------- December 22, 1995 Via Fax Subject: Why the Telecommunications Deregulation Bill, S. 652 (H.R. 1555), As Reported by the Conference Committee Should Be Rejected Dear Senator: The American Civil Liberties Union urges you to vote against S. 652 (H.R. 1555), the telecommunications deregulation bill as reported by the conference committee. The conference committee has produced a bill that will immediately damage freedom of expression, the bedrock value at the core of the First Amendment and will structure the telecommunications industry so that free speech and privacy are in permanent jeopardy. While the final text is still being written, these provisions are sufficiently destructive that they warrant rejection of the entire bill. Many reasons could be cited why S. 652 should be rejected; we will focus on just three areas where the conferees have needlessly chosen to attack essential First Amendment values. I. The "Deregulation" Bill Will Establish a Big Government Censorship Regime with New Speech Crimes for the Internet and Online Communications. Title V of the telecommunications bill as adopted by the conference committee will: - Subject first-year college students under 18 to two years in prison and $100,000 fine if they engage in overly salacious dating patter online (even in their private e-mail). - Subject parents to the same prison term and fine if they provide their own teen-ager with online materials that the parents have decided have merit if the material is deemed to violate the bill. - Subject adults merely looking on their own home computer at something deemed obscene to prison for five years for the first peek, plus another ten years if they look again. This is not far-fetched. Electronic "footprints" are left behind whenever a user goes somewhere in cyberspace. Some of the censorship groups backing the bill openly support prosecuting anyone who looks at such material as way of "drying up" demand for it -- so these groups have an incentive to pressure prosecutors to follow those footprints back to the adults at home. - Effectively reduce voluntary communications among consenting adults to those appropriate only for children. Much of what consenting adults -- even married consenting adults -- prize about some of their communications could well be deemed by outsiders as indecent if addressed to minors. The bill will infantalize all communications in cyberspace as users worry about how to avoid prosecution if prohibited material is sought out by someone underage. The educational value of the Internet would be reduced to the equivalent of the children's section in the video store. - Define its new speech crimes so broadly that it will hold access and service providers criminally liable for content they did not create unless the providers have legal departments large and skilled enough to utilize limited and vague defenses. Even then, the defenses would have to be established in costly and time-consuming court proceedings. The predictable effect will be enormous self-censorship, coerced by the government's failure to precisely define what is being made criminal and the threat of prison for transgressors. - Subject all Americans to the most narrow of community standards found in the most socially limiting of locations. Even those who have chosen to adopt the social mores of such locations should not insist on imposing those mores on the millions of Americans who have chosen to live elsewhere. These proposals violate the Constitution. They are also profoundly bad public policy. Title V of the bill is unconstitutional because it takes speech protected by the First Amendment and tries to regulate it in a way that violates what the Supreme Court has said must be the touchstone for regulating protected speech. For example, the bill fails to use the constitutionally required "least restrictive means" to obtain its putative goals. It also fails to take into account the particular characteristics of interactive media in the online environment, rendering its attempt to create new speech crimes constitutionally impermissible. Title V also unconstitutionally invades the privacy rights of those who communicate online. Cyberspace is the first genuinely mass medium in human history, where many individuals can speak to many others at the same time, and where the "start-up" costs of "publishing" are so minimal that almost all users are potential publishers. This is a democratic and truly libertarian communications medium without a centralized governing body. There is no network president or standards department, for example, ultimately overseeing everything that is broadcast -- in fact there is no "network" but instead an endless series of independent areas like newsgroups, chat rooms, bulletin boards and web sites. The conference bill tries to force cyberspace into the mold of the old media with a government-dictated, centralized command structure. Cyberspace gives its users -- including parents concerned about their children -- an unprecedented power over what materials are accessed, or not accessed, from their computers. Parents, for example, already have available software and other technology that will let them control what their children access from their computer. Tragically, the conferees have rejected further private sector development of user empowerment technologies. Instead, the conference bill imposes the most restrictive regime of government regulation over content on what should be the least governmentally restricted of all media. In doing so, the bill would strangle cyberspace, violating the free speech and privacy rights of all those who communicate online. The ACLU believes that all adults have the right to choose for themselves what they see or say online. The conferees have chosen to invest a minority of censorship extremists with the coercive power of the criminal law and Federal prison in order to impose on the rest of us their constricted view of what we should say or see. This is a truly historic turning point. Title V of the bill from the conference committee confronts the Congress with a stark choice: - Will the 104th Congress be seen in history as one who stood up for the freedom of communications in cyberspace and the Internet, or will it be counted as a tool of certain censorship groups determined to impose their conception of "proper" speech on all of us? - Will the 104th Congress stand up for the continuing vitality of private sector development of interactive media, or will it impose a big-government bureaucratic regulatory regime on cyberspace and the content of its communications? - Will the 104th Congress stand up for empowering users -- including parents concerned about their children -- to control what material is accessed from their computers, or will it give the coercive power of federal prison sentences to censorship groups who care more about interfering with what other adults see or say than about protecting their own children? II. The "Deregulation" Bill Will Impose a Big-Government Censorship Regime on Television Programming. The conference committee has agreed to V-chip language in S. 652 that will stifle expression on broadcast and cable television and prevent parents from exercising greater control over their children's television viewing habits. The V-chip provision will vest the government, not parents, with control over which television programs make their way to the family television set. The V-chip hardware is technology that will automatically block a program from television reception if it carries a certain encoded rating in its transmission. The encoding would be transmitted on the same signal that currently carries closed captioning information. However, the V-chip requirement does more than simply call for new hardware in television sets; the bill would set up a television rating system driven by government guidelines on content. Although the television industry is given a one-year window to "voluntarily" develop and transmit an encoded ratings scheme for violent, sexual, or indecent programing, the Federal Communications Commission would have the power to reject the industry's system in favor of its own. In this way, the government ultimately decides what content is appropriate for viewing and what is not. The bill calls for the government to form an "advisory committee" to set recommendations for guidelines on rating content, and those guideline will be formally issued by the FCC. Although the V-chip's congressional sponsors have claimed that these guidelines will not be mandatory, the ratings guidelines will surely have a chilling effect on the creative process in television programming. Would producers make a television mini-series about the violent Civil War? Perhaps not, if the broadcast will automatically be blocked from the television sets of countless families who will not have the opportunity to make an independent judgement as to the program's appropriateness. The weightiest and clearest guidelines for content rating would be that of the government. Such chilling of expression by the government violates the First Amendment. The Supreme Court has held that violent expression enjoys full constitutional protection. Furthermore, what would constitute "sexual" expression would be left up to the government's advisory committee or the industry's "voluntary" internal censors. Would a news program or documentary on breast cancer be blocked as "sexual" expression? That answer is yet unclear, but what is clear is that the encoded ratings will block expression fully protected by the First Amendment. Furthermore, the V-chip scheme created by Congress completely shuts out families from the decision making process. Instead, it empowers bureaucrats and television executives to make decisions for parents. Would the V-chip's automatic censors block out such "violent" programs as "Schindler's List," "Roots," or "The Burning Bed"? Other options for true parental control and choice in children's television viewing will be destroyed by the government's V-chip mandate. Private companies have recently developed technology, such as the Telecommander and the TV Guardian, that would empower parents to screen out the programs or stations that they feel are inappropriate for their children. Additionally, there is the possibility of a true "choice chip," which would allow parents to subscribe to the private rating service of their choice, whether run by the National PTA, TV Guide or the Christian Coalition. Technology and initiatives developed by private business will be crushed by the government's mandatory censoring technology and ratings system. The government will step in as a surrogate parent to turn off the television when a child turns to the "wrong" channel. However, the government's version of what is "wrong" might include a documentary, an afterschool special, or other programming that a parent would actually want their child to watch. Thus, the "V" in V-chip is for the government's "victory" over parental control and the First Amendment. III. The Bill Will Foster Communications Monopolies that Stifle Diversity and Free Speech. A core value of the First Amendment's guarantees of free speech and free press is the vital role in preserving liberty played by robust discussion of public issues among a diversity of viewpoints. Unfortunately, the bill undoes much of the existing protection ensuring diversity in points of view by allowing a greater concentration of media. The conference report would, for example, allow the FCC to use waivers so that a single corporation could own the television station, radio station, cable system, newspaper, phone company and Internet access provider in a locality. On the national level, the bill will allow a greater concentration of control over programming sources. No clearer example exists of the destructive impact on free speech such media concentration will have than CNN's recent rejection of advertisements opposing the telecommunications bill itself. CNN's corporate owners, of course, have vital interests generally being advanced by the bill, but the decision to reject opposing ads (followed up by a decision to reject all ads on the bill -- when the issue was generally developing in favor of CNN's owners) is the kind of content control that will only be repeated as media concentration increases. Conclusion The American Civil Liberties Union urges you to oppose the conference version of S. 652 (H.R. 1555), the telecommunications deregulation bill because it will impose new speech crimes on cyberspace and new censorship on television programming, as well as jeopardize the future of free speech in this country by destroying the diversity of media ownership. Sincerely yours, Laura W. Murphy Director Donald Haines Legislative Counsel ---------------------------------------------------------------- ONLINE RESOURCES FROM THE ACLU NATIONAL OFFICE ---------------------------------------------------------------- Stay tuned for news on the ACLU's world wide web site, under construction at http://www.aclu.org/. America Online users should check out our live chats, auditorium events, *very* active message boards, and complete news on civil liberties, at keyword ACLU. ---------------------------------------------------------------- ACLU Cyber-Liberties Update Editor: Ann Beeson (beeson(a)aclu.org) American Civil Liberties Union National Office 132 West 43rd Street New York, New York 10036 To subscribe to the ACLU Cyber-Liberties Update, send a message to cyber-liberties(a)aclu.org with "subscribe Cyber-Liberties Update" in the subject line of your message. To terminate your subscription, send a message to cyber-liberties(a)aclu.org with "unsubscribe" in the subject line. For general information about the ACLU, write to info(a)aclu.org. ----------------------------------------------------------------

1 0

Welcome to cypherpunks
by Majordomo＠toad.com 17 Dec '03

17 Dec '03

-- Welcome to the cypherpunks mailing list! If you ever want to remove yourself from this mailing list, you can send mail to "Majordomo(a)toad.com" with the following command in the body of your email message: unsubscribe cypherpunks Cypherpunks Mailing List <cypher(a)infinity.nus.sg> Here's the general information for the list you've subscribed to, in case you don't already have it: About cypherpunks ----------------- I. Administrivia (please read, boring though it may be) The cypherpunks list is a forum for discussing personal defenses for privacy in the digital domain. It is a high volume mailing list. If you don't know how to do something, like unsubscribe, send mail to majordomo(a)toad.com and the software robot which answers that address will send you back instructions on how to do what you want. If you don't know the majordomo syntax, an empty message to this address will get you a help file, as will a command 'help' in the body. Even with all this automated help, you may still encounter problems. If you get really stuck, please feel free to contact me directly at the address I use for mailing list management: cypherpunks-owner(a)toad.com Please use this address for all mailing list management issues. Hint: if you try to unsubscribe yourself from a different account than you signed up for, it likely won't work. Log back into your old account and try again. If you no longer have access to that account, mail me at the list management address above. Also, please realize that there will be some cypherpunks messages "in transit" to you at the time you unsubscribe. If you get a response that says you are unsubscribed, but the messages keep coming, wait a day and they should stop. For other questions, my list management address is not the best place, since I don't read it every day. To reach me otherwise, send mail to eric(a)remailer.net This address is appropriate for emergencies (and wanting to get off the list is never an emergency), such as the list continuously spewing articles. Please don't send me mail to my regular mailbox asking to be removed; I'll just send you back a form letter. Do not mail to the whole list asking to be removed. It's rude. The -request address is made exactly for this purpose. To post to the whole list, send mail to cypherpunks(a)toad.com If your mail bounces repeatedly, you will be removed from the list. Nothing personal, but I have to look at all the bounce messages. There is no digest version available. There is an announcements list which is moderated and has low volume. Announcements for physical cypherpunks meetings, new software and important developments will be posted there. Mail to cypherpunks-announce-request(a)toad.com if you want to be added or removed to the announce list. All announcements also go out to the full cypherpunks list, so there is no need to subscribe to both. II. About cypherpunks The cypherpunks list is not designed for beginners, although they are welcome. If you are totally new to crypto, please get and read the crypto FAQ referenced below. This document is a good introduction, although not short. Crypto is a subtle field and a good understanding will not come without some study. Please, as a courtesy to all, do some reading to make sure that your question is not already frequently asked. There are other forums to use on the subject of cryptography. The Usenet group sci.crypt deals with technical cryptography; cypherpunks deals with technical details but slants the discussion toward their social implications. The Usenet group talk.politics.crypto, as is says, is for political theorizing, and cypherpunks gets its share of that, but cypherpunks is all pro-crypto; the debates on this list are about how to best get crypto out there. The Usenet group alt.security.pgp is a pgp-specific group, and questions about pgp as such are likely better asked there than here. Ditto for alt.security.ripem. The cypherpunks list has its very own net.loon, a fellow named L. Detweiler. The history is too long for here, but he thinks that cypherpunks are evil incarnate. If you see a densely worded rant featuring characteristic words such as "medusa", "pseudospoofing", "treachery", "poison", or "black lies", it's probably him, no matter what the From: line says. The policy is to ignore these postings. Replies have never, ever, not even once resulted in anything constructive and usually create huge flamewars on the list. Please, please, don't feed the animals. III. Resources. A. The sci.crypt FAQ anonymous ftp to rtfm.mit.edu:pub/usenet-by-group/sci.crypt The cryptography FAQ is good online intro to crypto. Very much worth reading. Last I looked, it was in ten parts. B. cypherpunks ftp site anonymous ftp to ftp.csua.berkeley.edu:pub/cypherpunks This site contains code, information, rants, and other miscellany. There is a glossary there that all new members should download and read. Also recommended for all users are Hal Finney's instructions on how to use the anonymous remailer system; the remailer sources are there for the perl-literate. C. Bruce Schneier's _Applied Cryptography_, published by Wiley This is required reading for any serious technical cypherpunk. An excellent overview of the field, it describes many of the basic algorithms and protocols with their mathematical descriptions. Some of the stuff at the edges of the scope of the book is a little incomplete, so short descriptions in here should lead to library research for the latest papers, or to the list for the current thinking. All in all, a solid and valuable book. It's even got the cypherpunks-request address. IV. Famous last words My preferred email address for list maintenance topics only is hughes(a)toad.com. All other mail, including emergency mail, should go to hughes(a)ah.com, where I read mail much more regularly. Enjoy and deploy. Eric ----------------------------------------------------------------------------- Cypherpunks assume privacy is a good thing and wish there were more of it. Cypherpunks acknowledge that those who want privacy must create it for themselves and not expect governments, corporations, or other large, faceless organizations to grant them privacy out of beneficence. Cypherpunks know that people have been creating their own privacy for centuries with whispers, envelopes, closed doors, and couriers. Cypherpunks do not seek to prevent other people from speaking about their experiences or their opinions. The most important means to the defense of privacy is encryption. To encrypt is to indicate the desire for privacy. But to encrypt with weak cryptography is to indicate not too much desire for privacy. Cypherpunks hope that all people desiring privacy will learn how best to defend it. Cypherpunks are therefore devoted to cryptography. Cypherpunks wish to learn about it, to teach it, to implement it, and to make more of it. Cypherpunks know that cryptographic protocols make social structures. Cypherpunks know how to attack a system and how to defend it. Cypherpunks know just how hard it is to make good cryptosystems. Cypherpunks love to practice. They love to play with public key cryptography. They love to play with anonymous and pseudonymous mail forwarding and delivery. They love to play with DC-nets. They love to play with secure communications of all kinds. Cypherpunks write code. They know that someone has to write code to defend privacy, and since it's their privacy, they're going to write it. Cypherpunks publish their code so that their fellow cypherpunks may practice and play with it. Cypherpunks realize that security is not built in a day and are patient with incremental progress. Cypherpunks don't care if you don't like the software they write. Cypherpunks know that software can't be destroyed. Cypherpunks know that a widely dispersed system can't be shut down. Cypherpunks will make the networks safe for privacy. [Last updated Mon Feb 21 13:18:25 1994]

1 0