December 2003 - cypherpunks-legacy

Re: Why Net Censorship Doesn't Work
by cman＠communities.com 17 Dec '03

17 Dec '03

I think that there is still a substantial possibility that many kinds of expression will be marginalized and hard to access for a great many users. One of my co-workers has pointed out that the need for something as simple as a helper application for Netscape loses about 90% of his audience. By simply making it rather more difficult for people to chat about some things, governments can effectively push such things out of the way of all but the most determined readers. This is actually one of those odd Laffer-curve-like phenomena, where as long as the expression isn't too inherently desirable, government restrictions can be somewhat effective, but the more tightly they try to control things, the more likely the are to lose, as there will be more and more desirable content outside the sanctioned sphere of activity. Consequently, I was much happier to see the "indecency" standard get passed instead of the "harmful" standard, as the former will push far more content into the "gray" area of the net, which will encourage development and adoption of appropriate tools. A quote from Star Wars (which I'm just now incorporating into my .sig) was just echoed back to me in a letter from a chap I spoke with from the Australian Office of Strategic Crime Assessment, as encapsulating what he got out of a rather long chat we had when he was passing through the Bay Area last month. Here it is: ------ , ------ Douglas Barnes "The tighter you close your fist, Governor Tarkin, cman(a)communities.com the more systems will slip through your fingers." cman(a)best.com --Princess Leia

3 2

test
by Ed Carp [khijol SysAdmin] 17 Dec '03

17 Dec '03

test, please ignore - 1 copy sent.

3 3

New Mitnick Book
by John Young 17 Dec '03

17 Dec '03

Jonathan Littman, an investigative reporter, has published "The Fugitive Game: Online With Kevin Mitnick," Little Brown, 1996. 381 pp. $23.95. ISBN 0-316-52858-7. It is a dramatic recount of Mitnick's exploits; the pursuit by Shimomura, Markoff, telcos and Feds; the bust and Markoff's tales; The Well controversies aand disputes about what really happened; suspicions of Shimomura and Markoff - - their complicity with TLAs, their movie and book dealings, their disputes with hackers and journalists. What Mitnick was telling Littman while a fugitive. Littman ends with this letter from Markoff and Shimomura: October 8, 1995 Jonathan Littman 38 Miller Avenue Suite 122 Mill Valley, California 94941 Dear Jonathan, This is in response to your separate letters to us. We apologize for not being more prompt, Tsutomu was travelling on business and did not receive your September 5 letter until recently. As you know we have a contract with Hyperion for Tsutomu's account of his participation in the arrest of Kevin Mitnick, and at the request of our publisher we have decided not to participate in other books on the same subject. First, in response to your September 7 request to John Markoff, for permission to reprint his March 14 Well posting, he is not willing to give permission. However, we do think it is appropriate to respond to several points where you have received inaccurate information. Our responses are not intended to be a comprehensive answer to your list of questions, but only to protect you from including libelous material in your book. Tsutomu was not asked by any governmental, military or intelligence representative to assist in the capture of Mr. Mitnick. All of his actions were taken in response to requests for assistance from both The Well and Netcom to deal with extensive and persistent break-ins. Tsutomu's decision to tell John Markoff that he was travelling to Raleigh on Sunday morning was done without contact with any law enforcement agency. Markoff flew to Raleigh independently six hours later after discussing the possibility of a story with his editors at the New York Times. Markoff did not at any time assist or participate in any aspect of the investigation into Kevin Mitnick's activities; Markoff was there only as an observer in his role as a newspaper reporter. Moreover, in Raleigh on Sunday evening the Cellscope equipment was never placed in Markoff's car, and there was never any discussion about taking it out of the Cellular One engineer's van or about placing it in Markoff's car. Markoff parked his car near the cell site that night and then later drove back to his hotel. Tsutomu never told anyone from law enforcement that anyone had authorized or cleared Markoff's presence in Raleigh. Tsutomu was informed by the Justice Department that his actions on behalf of the Internet providers and the cellular telephone company during the course of the investigation were covered under their fraud detection and prevention exception granted to these organizations under the ECPA. Tsutomu did have discussions with the National Security Agency about funding computer security research, the results of which were to be placed in the public domain, however no research grant was ever made. Tsutomu was not aware of any statements made in the search warrant until many days after the arrest. Tsutomu did not lure Mitnick or anyone else into breaking-in to his computers. The attack was entirely unprovoked. No copies of any files allegedly stolen by Mitnick were provided by Tsutomu to anyone other than the legitimate owners. The first discussion of the possibility of a book on the subject of Kevin Mitnick's arrest took place on Thursday February 16, when John Markoff received a telephone call from John Brockman, a New York City literary agent, proposing a collaboration between Markoff and Shimomura. You will remember, we hope, that after his July 4, 1994 article about the hunt for Mitnick, Markoff did not wish to pursue the subject of Mitnick's life as a fugitive and referred a free-lance article on the subject proposed by Playboy to you. Also please note that you are inaccurate in stating that Tsutomu requested immunity before testifying before Congress on April 1993. We realize this is a delicate issue for you because of your involvement and communication with Kevin Mitnick during the period he was a fugitive. However, since your questions suggest you believe there may have been something inappropriate in Tsutomu's cellular telephone software development work, if you do include material in your book along this line, journalistic ethics require you to include the following: Tsutomu, unlike Mitnick, in all of his computer security research over a fifteen year period, has always, whenever he has found a vulnerability, made it known to the appropriate people, whether CERT, or a private company at risk, or the United States Congress. Sincerely, (signed) John Markoff Tsutomu Shimomura

2 1

A weakness in PGP signatures, and a suggested solution (long)
by dlv＠bwalk.dm.com 17 Dec '03

17 Dec '03

I've been engaged in a lively debate with a few members of the cypherpunks mailing list about forgeries that are hard to repudiate even if PGP signatures are used. One of the participants suggested that I post a summary to alt.privacy.pgp and sci.crypt, which is just what I'm doing. (My apologies to the mail.cypherpunks readers who already saw much of this once.) I'll illustrate the problem with several scenarios of forgeries. (It's funny that earlier today I was showing a friend how easy it is to post forgeries. She seemed suitably impressed. :) Scenario 1: Bob once sent Carol an e-mail that looked like this: ----------------------------------------------------------------------- From: Bob@boxb To: Carol@boxc Date: 25 Dec 1965 Subject: Carol, we're history Message-ID: <111@boxb> ----BEGIN PGP SIGNED MESSAGE---- I no longer wish to go out with you. Merry Christmas! ----BEGIN PGP SIGNATURE---- Version 2.6.2 12341234... ----END PGP SIGNATURE---- ----------------------------------------------------------------------- Carol can forge an e-mail to Alice that looks like this: ----------------------------------------------------------------------- From: Bob@boxb To: Alice@boxa Date: 25 Dec 1995 Subject: Alice, we're history Message-ID: <222@bobb> ----BEGIN PGP SIGNED MESSAGE---- I no longer wish to go out with you. Merry Christmas! ----BEGIN PGP SIGNATURE---- Version 2.6.2 12341234... ----END PGP SIGNATURE---- ----------------------------------------------------------------------- We assume that it's easy for Carol to forge the RFC 822 headers to make it look like the e-mail came from Bob. That's why many of us use digital signatures. The signed portion of Bob's original e-mail did not state that the message is addressed to Carol (e.g., "Dear Carol"). Alice will probably verify that the signature matches Bob's private key and assume that the e-mail is authentic and has been sent to her by Bob. To repudiate the e-mail, Bob might have to point out that the "Received:" headers differ from his usual e-mails, without relying on PGP. In fact, the presense of his verifiable signature would create more of a presumption of authenticity of Alice's part. Scenario 2: Bob sends the same e-mail as above to Carol. David, a rogue sysadmin, gets a copy of the e-mail, forges the same e-mail as above to Alice. Scenario 3: Bob sends a signed e-mail to Alice. Alice sees it in her newsfeed, forges a Usenet article, makes it look like it came from Bob, and includes the body of Bob's e-mail as the body of the Usenet forgery. Usenet forgeries are easy. Again, if the signed text happens to be suitable, then Bob will have difficulty repudiating the forgery. He won't not be able to use the PGP signature, which will in fact verify. Hopefully, he'll be able to point out that the RFC 1036 Path: header is different from his usual header (which may not be the case). Many Usenet readers would be unconvinced and Bob's reputation would be damaged. Scenario 4: Bob posts a signed Usenet article to alt.sex. Alice forges a usenet article in Bob's name to misc.kids, recycilng the signed body, which would probably be considered inappropriate for misc.kids. Same result as #3. Scenario 5: Bob posts a signed Usenet article to some innocuous newsgroup. Alice reposts the same body in a forgery in Bob's name. The forgery can be cross-posted to numerous "inappropriate" newsgroups ("velveeta"), or multi-posted ("spam"). Certain rogue self-apponited net.cops forge cancels for all copies of Bob's article, including the original. (They are a bigger menace than the forgers :) (As several people know, I have been a victim of some of the above-described kinds of forgeries.) I think the underlying problem is that the way PGP signatures are used by most people, they validate a text, but allow it to be quoted out of context in an e-mail or Usenet forgery. I suggest to the kind folks working on PGP 3 that there should be a standard protocol to include within the signed portion the information on when and for whom this text is written: i.e. the list of e-mail recipients and/or Usenet newsgroups, which could be easily compared with the RFC 822/1036 headers of an e-mail/Usenet article. Perhaps there could be a new option for PGP to look _outside_ the signed block and match the headers with what's inside the block. For example, suppose the signature block says: this text was written by alice(a)zog.org, posted to alt.sex and alt.sex.banal and e-mailed to bob(a)masons.com. Suppose PGP is asked to check the signature in a file that purports to be a e-mail or a Usenet article and has some headers before the signed portion. If there is a list of To: recipients, and it includes someone other than the recipients listed within the signed block; or if there is a Newsgroups: header, and it includes newsgroups not listed within the signed portion; then the input is bogus. For compatibility with the existing software, if the signed block doesn't include this info, then this checking should't be done, of course. After I posted the above suggestion to cypherpunks, one very respected member of that list informed me that "the security multiparts standard (RFC 1848) includes a provision for signing the headers as well as the body of a message. The security multiparts can be used with PGP, and there is even an Internet Draft for it (draft-elkins-pem-pgp-02.txt), but there is not yet consensus for adopting this as a standard on the pgp-mime mailing list." I hope my examples will convince some that present practice of signing pieces of text which can be quoted out of context in a forgery is just not enough. We need to have an easy way to sign the headers without resorting to mine. --- Dr. Dimitri Vulis Brighton Beach Boardwalk BBS, Forest Hills, N.Y.: +1-718-261-2013, 14.4Kbps

11 10

RE: "trust management" vs. "certified identity"
by shamrock＠netcom.com 17 Dec '03

17 Dec '03

At 1:40 1/7/96, Frank O'Dwyer wrote: >But it is usually easier to >determine (and vouch for) who a stranger is than how trustworthy >they are, if only because there are quick and easy real-world >mechanisms for this (driver's licence, passport,etc.). That's all >I meant. Though it may seem that way, I am not so sure that it is true. I am told that you can buy a CA driver licence in the hispanic part of San Francisco for about $50. Hologram and all. Reputations can take years to establish. I am would feel more comfortable to sign certain statements about the (on-line) character or technical skills of some people on this list whom I have never met, than to sign the PGP key of an utter stranger that shows me his Alabama ID card. -- Lucky Green <mailto:shamrock@netcom.com> PGP encrypted mail preferred.

3 2

Re: "Re: NSA says strong crypto to china??
by jrochkin＠cs.oberlin.edu 17 Dec '03

17 Dec '03

At 10:50 PM 01/07/96, Timothy C. May wrote: >As when the Cossacks who fled the U.S.S.R. after the war and pledged to >help the West fight Communism were returned by the British to Stalin, where >they were executed. (I was reminded of this by the latest Bond movie, where >Bond avers, "Not exactly Britain's finest moment.") The Kurds in Iraw during the Persina Gulf war is an analagous situation. The Kurds supported and assisted the U.S. government during the war. Really pro-U.S.. At some point near the end of the war, though, the U.S. just started ignoring them, and Hussein started bombing them and killing huge numbers of them.

1 0

[Fwd: Re: ABOI: Desperate User Support]
by Shri 17 Dec '03

17 Dec '03

Seen on Alt.best.of.internet. Would love to find out if this is true! Shri > > Origination: alt.sysadmin.recovery > > Originator: jerry(a)worf.tcs.com (Jerry Carlin) > >Original Subject: support call - urban legand or fact? > > Date: 27 Jul 1995 16:44:18 -0700 > >... (many forwards deleted)... > > >This falls into the "Why did it have to happen on *MY* shift?" category. > > >A friend of mine is a chief engineer at SuperMac, and he related this > >story to me. > > >SuperMac records a certain number of technical support calls at random, > >to keep tabs on customer satisfaction. By wild "luck", they managed to > >catch the following conversation on tape. > > >Some poor SuperMac TechSport got a call from some middle level official... > >from the legitimate government of Trinidad. The fellow spoke very good > >English, and fairly calmly described the problem. > > >It seemed there was a coup attempt in progress at that moment. However, > >the national armoury for that city was kept in the same building as the > >Legislature, and it seems that there was a combination lock on the door > >to the armoury. Of the people in the capitol city that day, only the > >Chief of the Capitol Guard and the Chief Armourer knew the combination to > >the lock, and they had already been killed. > > >So, this officer of the government of Trinidad continued, the problem is > >this. The combination to the lock is stored in a file on the Macintosh, > >but the file has been encrypted with the SuperMac product called Sentinel. > >Was there any chance, he asked, that there was a "back door" to the > >application, so they could get the combination, open the armoury door, > >and defend the Capitol Building and the legitimately elected government > >of Trinidad against the insurgents? > > >All the while he is asking this in a very calm voice, there is the sound > >of gunfire in the background. The Technical Support guy put the person on > >hold. A phone call to the phone company verified that the origin of the > >call was in fact Trinidad. Meanwhile, there was this mad scramble to see > >if anybody knew of any "back doors" in the Sentinel program. > > >As it turned out, Sentinel uses DES to encrypt the files, and there was > >no known back door. The Tech Support fellow told the customer that aside > >from trying to guess the password, there was no way through Sentinel, and > >that they'd be better off trying to physically destroy the lock. > > >The official was very polite, thanked him for the effort, and hung up. > >That night, the legitimate government of Trinidad fell. One of the BBC > >reporters mentioned that the casualties seemed heaviest in the capitol, > >where for some reason, there seemed to be little return fire from the > >government forces. > > >O.K., so they shouldn't have kept the combination in so precarious a > >fashion. But it does place, "I can't see my Microsoft Mail server" > >complaints in a different sort of perspective, does it not?

5 8

Re: phone calls from hell
by Simon Spero 17 Dec '03

17 Dec '03

Hey - he spent so much time training suicide bombers maybe the phone was set to blow if anyone dialed the, er, Samaritans. Simon (defun modexpt (x y n) "computes (x^y) mod n" (cond ((= y 0) 1) ((= y 1) (mod x n)) ((evenp y) (mod (expt (modexpt x (/ y 2) n) 2) n)) (t (mod (* x (modexpt x (1- y) n)) n))))

1 0

Re: Microsoft continues to mislead public about Windows securitybugs (a bit long, with references)
by frantz＠netcom.com 17 Dec '03

17 Dec '03

At 0:37 1/9/96 -0800, Lucky Green wrote: > >Very true. But why does it always seem to take an exploitable crack before >companies pay attention to security flaws? Is it because they are unable to >admit that they have made a mistake? Everybody makes mistakes. What's the >big deal? I really don't understand it. Any psychologists on this list? Having, in the past, attempted to sell an Operating System with high security features, and failed, I think I can give you some insight. Security does not sell an OS to anyone, even the Department of Defense. People buy OSs to run applications. The only thing a lack of security in an OS will do is allow someone in an obscure department (perhaps called Corporate Security) to say no. Security is a checkoff item, and if you can convince a retired major that the OS is secure, then he will approve it. He is not going to check the details. His expertise is in guard stations and chain link fences. However, if someone, e.g. the trade press, rubs his nose in the fact that an OS's security can be breached, then he will take action. He will pressure the publisher to release a fix that they say will fix the problem. When they do, he will be happy. Microsoft particulary, is oriented to selling product, not pride in workmanship. ----------------------------------------------------------------- Bill Frantz Periwinkle -- Computer Consulting (408)356-8506 16345 Englewood Ave. frantz(a)netcom.com Los Gatos, CA 95032, USA

2 1

Re: Why can't I get PGP from MIT
by jis＠mit.edu 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- >I believe I had a problem when I wanted to get PGP coming from >internexus.net (New Jersey). I just e-mailed them about it and I think >they just added the site to their 'acceptable' list. I did a traceroute >to why.net and noticed that it is very close to me, coming off of >SprintNet... probably the same situation. Internexus.net has been added to the list. The heuristic that the MIT site enforces is as follows: o To get access you must properly answer some questions regarding export control law and licensing. o Your host must have an "inverse" DNS mapping so we can learn its name. o Your host's name must end in either ".EDU", ".COM", ".MIL", ".GOV", ".US", or ".CA". *or* Be on our exception list. All the ".NET's" and ".ORG's" need to be "excepted." Maintaining the exception list has turned out to be a serious problem. I receive roughly 20 messages a day from people needed to be added. To make matters worse the exception list has to be maintained in two different locations in two different formats. I just broke down today and automated the management of the lists. Unfortunately the only thing I can do for people whose machines do not have an inverse DNS mapping is to send them personal copies via e-mail. However, I have been too swamped to do this. I am looking into alternative approaches of guarding the FTP site (possibly doing a traceroute or something similar) in a better way that still meets the requirements of maintaining export restrictions. Please remember that I maintain the MIT FTP site in my all too rare spare time. Thank you. -Jeff -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMPBCFcUtR20Nv5BtAQEUhAQAnzPlxiXo33DqX0X1m39Xh1I0e7ND332n L4vZlf7T3VDU0jYv1IB/6D3aNvMXo0l8JpsXIxqzaxP5nYgVgm1idx06IgY7T1rJ vVRCIqfFleUFPTS/ndo7jznzr+w7Dq1+5wRU2Oa+ymRICBNHCeEnaxcmx3zs4R6a VEBmc/6w8TQ= =vFSt -----END PGP SIGNATURE-----

1 0