December 2003 - cypherpunks-legacy

Princeton University muzzles students
by declan＠well.com 17 Dec '03

17 Dec '03

Date: Thu, 25 Jul 1996 20:33:38 -0500 To: fight-censorship+(a)andrew.cmu.edu From: declan(a)well.com (Declan McCullagh) Subject: Princeton University muzzles students, from HotWired Sender: owner-fight-censorship(a)vorlon.mit.edu Kudos to Brock for writing about Princeton University's attempt to muzzle student online speech -- by citing IRS regulations. Sure, Princeton isn't bound by First Amendment strictures since it's not a state university and there is no state action. Nevertheless, it should abide by the fundamental and long-standing principles of academic freedom. Especially as a supposedly leading institution of higher education, Princeton should stand head and shoulders above the rest in fighting for free expression on its campus. To its shame, it didn't. The university attorneys should have at least read the two relevant IRS revenue rulings (they didn't) before announcing such a restrictive policy. And this isn't the first overbroad censorial policy that Princeton has on the books. Carl Kadie comments on another one at: gopher://gopher.eff.org:70/00/CAF/policies/princeton.edu.critique The Justice on Campus Project (http://joc.mit.edu/) has similar info. When Princeton administrators claimed they followed the letter of the law, in truth they used the law as an excuse to muzzle their students. -Declan ----------------- Read the full article at: http://www.netizen.com/netizen/96/30/campaign_dispatch3a.html HotWired The Netizen Poison Ivy Campaign Dispatch by Brock N. Meeks Washington, DC, 24 July Princeton University is apparently prohibiting students from exercising their First Amendment rights by going after folks who set up Web pages in support of presidential candidates, Dispatch has learned. Princeton launched its preemptory strike against free speech on 19 July in a statement issued by its general counsel's office, which warns that a violation of the school's policy against politicking "will result in appropriate disciplinary action." [...] Small problem: the IRS disagrees. Although there is no direct IRS ruling involving the use of a university's computer resources by its faculty, staff, or students to set up political Web pages, agency spokesman Wilson Fadely said there are two previous rulings "that may apply." The first deals with a student newspaper that directly endorsed one candidate for office over another. Despite the fact that the newspaper was published with university resources, "that was deemed not to be intervention," Fadely said. [...] So where does Princeton get off riding its tax-exempt hobby horse as a de facto means to trample free speech? "No comment at this time," said Howard Ende, a Princeton attorney and co-author of the 19 July statement. When informed of the IRS rulings, Ende's reply was an enigmatic, "Oh, really." [...] The one saving grace of the scenario is the perverse pleasure one can take in realizing that an elitist Ivy League school is so anal-retentive that it makes the IRS look reasonable. Go figure....

2 1

IP: NSA RESPONSE TO KEY LENGTH REPORT
by farber＠central.cis.upenn.edu 17 Dec '03

17 Dec '03

Message-ID: <2.2.32.19960718184201.0070667c(a)linc.cis.upenn.edu> Date: Thu, 18 Jul 1996 12:04:27 -0400 From: Matt Blaze <mab(a)research.att.com> July 18, 1996 There is currently being circulated, to members of Congress and possibly elsewhere, a four page document entitled ``Brute-Force Cryptanalytic Attacks'' that calls into question some of the conclusions of the ``Minimum Key Lengths for Symmetric Ciphers'' white paper [1]. The document bears no author or organization attribution, but we are told that it originated from NSA. The NSA document argues that ``physical realities'' make parallel key search much more expensive and time consuming than our white paper estimated. However, the NSA document appears to have been written from the perspective of general parallel processing or cryptanalysis rather than exhaustive key search per se. It ignores several elementary principles of parallel processing that apply specifically to exhaustive key search machines of the type that our white paper considered. In particular, NSA argues that interconnections, heat dissipation, input/output bandwidth, and interprocessor communication make it difficult to ``scale up'' a key search machine by dividing the task among a large number of small components. While these factors do limit the scalability of more general purpose multiprocessor computers (such as those made by Cray), they do not apply at all to specialized exhaustive key search machines. The NSA argument ignores the most fundamental feature of brute-force key search: the processors performing the search have no need to communicate with other components of the system while they perform their share of the search, and therefore the system has no need for any of the global interconnections that limit scaling. Indeed, there is no reason that all the components of a parallel search machine must be located even within the same city, let alone the same computer housing. We note that one of our co-authors (Eric Thompson, of Access Data, Inc.) designs and builds medium-scale FPGA-based key search machines with exactly this loosely-coupled structure, and regularly uses them to recover keys for clients that include the FBI. The NSA document also calls into question our cost estimates for ASIC components, suggesting that ASIC chips of this type cost NSA approximately $1000.00 each. However, our $10.00 per chip estimate is based on an actual price quote from a commercial chip fabrication vendor for a moderate-size order for an exhaustive search ASIC designed in 1993 by Michael Wiener [2]. Perhaps NSA could reduce its own costs by changing vendors. Finally, the NSA report offers estimates of the time required to perform exhaustive search using a Cray model T3D supercomputer. This is a curious choice, for as our report notes, general-purpose supercomputers of this type make poor (and uneconomical) key search engines. However, even the artificially low performance results for this machine should give little comfort to the users of 56 bit keys. According to NSA, 56 bit keys can be searched on such a machine in less than 453 days. ``Moore's law'' predicts that it will not be long before relatively inexpensive general-purpose computers offer similar computational capability. /s/ Matt Blaze Whitfield Diffie References: [1] Blaze, M., Diffie, W., Rivest, R., Schneier, B., Shimomura, T., Thompson, E., and Wiener, M. ``Minimum Key Lengths for Symmetric Key Ciphers for Commercial Security.'' January 1996. Available from ftp://ftp.research.att.com/dist/mab/keylength.txt [2] Wiener, M. ``Exhaustive DES Key Search.'' Presented at Crypto-93, Santa Barbara, CA. August 1993. ========================================================================= [Transcription of document circulated to various members of congress and others in June, 1996, apparently by NSA] BRUTE-FORCE CRYPTANALYTIC ATTACKS Two published theoretical estimates of cost versus time to perform brute-force hardware attacks on selected cryptography key lengths differ between themselves and differ significantly from what we find when we buy or build computers to carry out such attacks. The differences lie in assumptions made in the theoretical estimates, which are not fully spelled out by the authors, and in scaling up hypothesized small machines to ever larger ones without accounting for physical realities. The factors not accounted for are: o R&D costs for the first machine, typically on the order of $10 million. o As more and more chips are added to a machine, two effects occur: o Interconnections increase and increase running time; o Heat from the chips eventually limit [sic] the size of a machine. o Memory costs are not included. o When get [sic] to the very fast processing speed estimates, machines can become Input/Output bound; so [sic] it cannot achieve the estimated speed. o Assuming every algorithm can be tested in same amount of time and key length is the only difference. Table 1 are [sic] the average time estimates made for a given cost done by Michael Wiener of Bell Norther Research in 1995. These are published in Bruce Schneier's Applied Cryptography book. Note that these are average times, one-half of the total exhaust time. Table 2 are [sic] the estimates for total exhaust times using Field Programmmable Gate Arrays (FPGA) and Application Specific ICs (ASICs) done for the Business Software Alliance by Blaze, Diffie, Rivest, Schneier, Shimomura, Thompson, and Wiener in 1996. In addition to the above factors not accounted for they have assumed ASICs cost as low as $10. We find ASICs more typically cost $1000 and their capabilities can vary considerably depending upon the specific task. Table 3 are out estimates based on our experience with a Cray T3D supercomputer with 1024 nodes. This machine costs $30 million. [Tables 1, 2, and 3 not transcribed here.]

3 4

Fireworks expected, missed at Senate crypto hearing
by declan＠well.com 17 Dec '03

17 Dec '03

Date: Thu, 25 Jul 1996 21:05:31 -0500 To: fight-censorship+(a)andrew.cmu.edu From: declan(a)well.com (Declan McCullagh) Subject: Fireworks expected, missed at Senate crypto hearing Sender: owner-fight-censorship(a)vorlon.mit.edu Precedence: bulk Contrary to the Reuters report excerpted below, there weren't any fireworks at today's ProCODE crypto hearing before the full Senate Commerce committee -- at least during the first panel when the spooks testified. (I skipped out before the second, which had industry folks.) Just more of the same, though we heard less about child pornographers and more about terrorists. And Sen. Slate Gorton (R-Wash) jumped on the committee staff for leaning too far *away* from national security interests in their summary of the legislation. Most amusing point: Sen. Larry Pressler waved a copy of the floppy with the _Applied Cryptography_ source and couldn't remember what it was called. "Um, I can't export, um, this, um," he mumbled. "Cassette," he decided it was. (Even his committee staffers smirked at that.) The FBI's Louis Freeh kept mouthing the same tired old line: "No reasonable person can envision a lawless information superhighway. It was never meant to be that. We need cops there, as we need them elsewhere. The problem is the proliferation of unbreakable encryption." He said it's "not too late" to stop the spread. After the first panel ended, a gaggle of a half-dozen camera crews waylaid Freeh in the hallway outside. The FBI director fled down the stairs. The crews split into teams. Half took the elevator and half pursued on foot. Downstairs, Freeh shot through the security checkpoint into the safety of a waiting Chevy Suburban. Why were they dogging the guy? They didn't care about crypto -- they wanted a comment about the TWA flight, and Freeh wasn't talking. He didnt' mention it at all during the hearing... -Declan -------------------- Fireworks Expected at Encryption Hearing July 25, 1996 WASHINGTON (Reuter) - After sailing through two quiet subcommittee hearings, a bill to relax restrictions on computer encoding faces a much choppier ride before the full Senate Commerce Committee on Thursday. The committee will hear from some of the Clinton administration's big guns on crime and national security, including FBI Director Louis Freeh and William Crowell, deputy director of the National Security Agency. Software manufacturers and some in Congress argued at earlier hearings that current export restrictions on encryption programs -- which code and decode information -- cost American companies billions in lost sales overseas. [...] Senate bill 1726, the Promotion of Commerce Online in the Digital Era Act of 1996, would abolish most export restrictions and prohibit mandatory key escrow. Vice President Al Gore told reporters at a press conference July 12 that the proposal, known as the ``pro-code'' bill, is ``unacceptable.'' [...] Clinton administration officials have said they favor less radical reform. Officials are expected to reject the conclusions of a study released in May by the National Research Council. The council concluded that encryption export restrictions should be relaxed and rejected key escrow as unworkable. [...]

1 0

Re: Fireworks expected, missed at Senate crypto hearing
by jim bell 17 Dec '03

17 Dec '03

At 09:19 PM 7/25/96 -0500, Declan McCullagh wrote: >Just more of the same, though we heard less about child pornographers and >more about terrorists. And Sen. Slate Gorton (R-Wash) jumped on the >committee staff for leaning too far *away* from national security interests >in their summary of the legislation. What does that mean? As opposed to what? (Gorton's my Senator, and I'm going to give a little feedback to his local office...) >The FBI's Louis Freeh kept mouthing the same tired old line: "No reasonable >person can envision a lawless information superhighway." I guess that makes me an unreasonable person! > "It was never meant to be that." Well, that's just the problem...for _him_! Sometimes actions lead to hard-to-predict outcomes. >We need cops there, as we need them elsewhere. The problem is >the proliferation of unbreakable encryption." He said it's "not too late" >to stop the spread. Wishful thinking! Not only is it too late now, it was too late with Clipper I was proposed. Jim Bell jimbell(a)pacifier.com

3 2

Re: Produce 7 Hertz Frequency
by Paul S. Penrod 17 Dec '03

17 Dec '03

On Thu, 25 Jul 1996, Jerome Tan wrote: > Does anyone know how to produce a 7 hertz frequency? > > Well, you can pick up most any project book that deals with 555 IC timers and there is some kind of circuit there dealing with frequency counting or generating. The question really is how strong a signal do you want ? ...Paul

1 0

Re: Apps: Unix for Windows 95
by AwakenToMe＠aol.com 17 Dec '03

17 Dec '03

unix doesnt have to be $$$$$$$$ you can pick up a shareware version of unix (all the power features in it) called linux. Info magic sells nice cd sets. Goto your local microcenter... or search the net for linux (warning..about 80 googleplex hits will come up hehehe)

1 0

Re: Produce 7 Hertz Frequency
by tcmay＠got.net 17 Dec '03

17 Dec '03

At 4:56 AM 7/26/96, Mike Duvos wrote: >I'm not sure what this gentleman's application is. If I wanted >a 7 hz signal, I would take my handy dandy programmable digital >signal generator, press the "sin" button, and punch in "7" on >the numeric keypad. > >Am I missing something here? What does "sin" have to do with the number 7? Oh, you must mean the movie "Se7en," in which the Se7en deadly sins were central to the plot. I get it. The seven deadly sins are the seven deadly hurts. (Cos I know about sin.) Ironic that the original message was from Jerome Tan, eh? Someone must've trigged this whole thread. I fear we're going in circles. "Kenneth, what is the frequency?" --Dan Rather Boycott "Big Brother Inside" software! We got computers, we're tapping phone lines, we know that that ain't allowed. ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)got.net 408-728-0152 | anonymous networks, digital pseudonyms, zero W.A.S.T.E.: Corralitos, CA | knowledge, reputations, information markets, Licensed Ontologist | black markets, collapse of governments. "National borders aren't even speed bumps on the information superhighway."

2 1

Unix under Windows 95
by Duncan Frissell 17 Dec '03

17 Dec '03

See: http://www.windows95.com/apps/unix.html For a collection of Unix software ported to Windows 95. The PERL 5.0 works better for me under 95 than under Unix (but I probably don't know Unix. Unix Plea: Could some Unix Guru out there give me (privately) a simple alias statement or whatever that would automatically forward mail for a named user(a)host.com to another email address somewhere in the world. DCF

1 0

Re: Distributed DES crack
by shamrock＠netcom.com 17 Dec '03

17 Dec '03

At 10:30 7/23/96, Matt Blaze wrote: >My estimate is that an FPGA-based machine that can do a single DES key >every four months (eight months to exhaust the whole keyspace) could >be built with off-the-shelf stuff for comfortably under $50k (plus >labor, plus software development costs). A prototype board should cost >under $1000 and will help prove the concept and get a more accurate cost >estimate. I expect to build such a prototype machine myself, and, if it >works as I expect, maybe the whole thing. I am willing to financially contribute to the project. -- Lucky Green <mailto:shamrock@netcom.com> PGP encrypted mail preferred. Defeat the Demopublican Unity Party. Vote no on Clinton/Dole in November. Vote Harry Browne for President.

1 0

Re: www.anonymizer.com
by Bill Stewart 17 Dec '03

17 Dec '03

At 08:53 PM 7/25/96 -0700, mpd(a)netcom.com (Mike Duvos) wrote: >I had occasion to try www.anonymizer.com recently, and noticed >that it does not make SSL connections to other Web servers, nor >does it seem to accept them from the user. > >Is there some technical reason for this? If I wish to grep the >Web without my browsing habits becoming known to someone >monitoring my Net connection, https://www.anonymizer.com with 128 >bit encryption would probably be a good thing to connect to. I suspect the primary reason is "that takes work we haven't done yet" rather than anything more cryptographic :-) However, there are a couple of theoretical problems with doing it as well. 0A) Suppose You and Webserver are secure by definition (because otherwise you're hosed anyway....) 0B) Let -s- denote an SSL connection and --- denote a non-SSL connection. 0C) A connection from You-s-Webserver is as secure as SSL. 1) A connection from You-s-Anonymizer-s-Webserver is less secure, because any flaw or breakin or dishonesty or compromise of the Anonymizer compromises the security of your connection. 1A) You may get ripped off or arrested if the Anonymizer's compromised 1B) The Anonymizer may be liable if you get ripped off through it. 2) An SSL connection may carry a certain amount of indentification data across it (I'm speculating a bit), which isn't really what you want in an Anonymizer. 3) A connection You-s-Anonymizer-s-Webserver may not always work the same as You-s-Webserver, because the latter may make assumptions about the connection that don't hold with the former. 3A) Of course, that's also true with non-SSL connections*, but there's less likely to be money riding on the deal. 3B) In particular, there may be different identification data passing across the Anonymized connection than the non-Anonymized. 3C) You may trust the Anonymizer and not the Webserver, or vice versa, and SSL probably isn't designed to do both correctly. 3D) The Webserver may trust the Anonymizer and not You, or vice versa, and SSL probably isn't designed to handle those correctly either. 4) The Anonymizer may have different encryption types/strengths than You or the Webserver. 4A) If You only do 40-bit RC4 and the Anonymizer can do 3DES, the Webserver may think it's got a secure connection when your end is weak - especially a problem if the Anonymizer is a popular wiretap target. This can be remedied by having the Anonymizer only make https: connections to Webservers at the same strength as its connection to You, which either requires annoyingly complex programming (bad) or a cheap hack like running several Anonymizer servers, one with wimpy encryption and one with strong encryption. 4B) If You have a strong crypto connection to the Anonymizer and the Webserver only has wimpy RC4/40, there isn't any good way for the Anonymizer to tell you about it - so your browser may be happily telling you it's got a two-toothed 3DES/RSA-2048 connection while it's really just RC4/40/RSA-512. 4B1)And that happy Java+JavaScript application your browser is running can check that it's got the MachoCrypto flag set and send your credit card number and Secret Plans to the Secret Plan Evaluation Service Website, which is a Bad Move... 4B2)Maybe you could program the Anonymizer to check out https:URLs to see what kind of crypto they support, and return anonymizered URLs that use the different-strength Anonymizers referred to in 4A. Not sure this would always work. 5) The extra RSA encryption from using SSL would probably cause a non-trivial amount of extra load for the anonymizer machine. Summary: Having said all that, I'd probably still like to have it. <<<<>>>> * Frames, for instance, do bizzare things when anonymized, at least with Netscape 3.0b5. Frames are, of course, _evil_, and are banned by the CDA, and anyone who uses them should be flamed mercilessly and forced to use Lynx on a 24x80 monochrome display until he or she repents and sees the error of their ways, and if that doesn't work they should be exiled to AOL with only Microsoft Word Internet Assistant. But that's a flame for another day.... <<<<>>>> # Thanks; Bill # Bill Stewart +1-415-442-2215 stewarts(a)ix.netcom.com # http://www.idiom.com/~wcs # Confuse Authority!

2 1