From shamrock at cypherpunks.to Thu Aug 1 01:11:27 2002 From: shamrock at cypherpunks.to (Lucky Green) Date: Thu, 1 Aug 2002 01:11:27 -0700 Subject: White House Sounds Call For New Internet Standards In-Reply-To: <5.1.0.14.2.20020731123856.04f5f9d0@pop3.lvcm.com> Message-ID: <000201c23933$09198d20$6801a8c0@xpserver> Steve wrote: > The Bush administration's cyber security czar, Richard > Clarke, said it might be time to replace the "creaky, cranky" > 20-year-old protocols that drive the Internet with standards > better able to accommodate a flood of new wireless devices. > Wireless devices, it is feared, may introduce large security > holes to the network. The White House is working with the > private sector to draft a national plan to secure the > country's most vital computer networks from cyber attack. How about IPv6 with IPSEC? --Lucky From frissell at panix.com Thu Aug 1 03:39:14 2002 From: frissell at panix.com (Duncan Frissell) Date: Thu, 1 Aug 2002 06:39:14 -0400 (EDT) Subject: White House Sounds Call For New Internet Standards In-Reply-To: <000201c23933$09198d20$6801a8c0@xpserver> Message-ID: On Thu, 1 Aug 2002, Lucky Green wrote: > > How about IPv6 with IPSEC? > > --Lucky > Isn't that a creaky, cranky 10-year-old protocol? DCF From pcwealth at yahoo.com Thu Aug 1 04:40:25 2002 From: pcwealth at yahoo.com (pcwealth at yahoo.com) Date: Thu, 1 Aug 2002 06:40:25 -0500 Subject: Is Your Financial Future Setup the Way it Should Be? Message-ID: <4119-22002841114025266@pas-tech-w2k-04> ************************************************************************************************************************************************************************************* "Thank you for posting your link on our free links page. Feel free to post your message as often as you like. This is a one time confirmation of your posting so there is no need to request removal as you have not been added to our email list." ************************************************************************************************************************************************************************************* PureInvestor is an organization that provides you with an opportunity to access a wealth of Financial Management and Investment Analyst expertise that is generally available only to major investment market players. Most people are not fortunate enough to have enough money to invest. So combining an Investment Club with an Affiliate program enables members to generate investment capital. Through the Investment Club principle we are able to leverage the investment power of our membership to ensure sound analysis and portfolio management that maximizes the yield on investment capital. Receive your own website, just like this one. http://pureinvestor.int-ltd.com/ Join PureInvestor Today and take Control of your Financial Future The PureInvestor system has been designed to be RISK FREE. With only 4 people on Level 1 your monthly fee will be covered. This does not mean your personally sponsored members, they can also be from upline referrals. And with only 169 referrals you will be making $1,500.00 per month, which is enough to have a good monthly income plus investment capital. The incredible part of the program is reverse matrix, when you have your 1st 7x4 matrix filled PureInvestor creates a second matrix for YOU and then invites your first matrix members to join your second matrix in Reverse Order. This not only ensure growth because new members have the opportunity of being at the top of the matrix but it also DOUBLES YOUR INCOME Once you become a member of the PureInvestor Organization here is a list of some of the benefits the member received from the founders. Where else can you receive so much support. http://pureinvestor.int-ltd.com/ Debit Card: Debit Card enables you to access your account funds by using it as Debit or ATM card. Investments: Investment and education are a key feature of PureInvestor providing a stable income for you and your family in the short, medium and long term. Coop Shares: You can purchase, sell and monitor the growth of your Coop Share value on a monthly basis indicating the current month profits and the accrued profits per share. Portfolio: Management of your investment portfolio is an essential part of sound financial strategy, here you are able to analyze, add and dispose of investments you have in your portfolio. Education: We know that not everyone is a financial analyst or knowledgeable when it comes to investment. Because of this PureInvestor provides a comprehensive self-paced courses on investing. Support: Having a problem, we are just an email away, our support team are here to assist you in achieving your goals. Marketing: Not sure how to market your site, we provide you with the aids to promote your site and build a successful team. Your success is very important to us and we are here to help you as much as we, we want you to succeed because then we succeed. http://pureinvestor.int-ltd.com/ To YOUR SUCCESS R.L. PC Wealth Safelist http://pcwealth.int-ltd.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From eugen at leitl.org Thu Aug 1 02:19:12 2002 From: eugen at leitl.org (Eugen Leitl) Date: Thu, 1 Aug 2002 11:19:12 +0200 (CEST) Subject: White House Sounds Call For New Internet Standards In-Reply-To: <000201c23933$09198d20$6801a8c0@xpserver> Message-ID: On Thu, 1 Aug 2002, Lucky Green wrote: > > Clarke, said it might be time to replace the "creaky, cranky" > > 20-year-old protocols that drive the Internet with standards > > better able to accommodate a flood of new wireless devices. > > Wireless devices, it is feared, may introduce large security > > holes to the network. The White House is working with the > > private sector to draft a national plan to secure the > > country's most vital computer networks from cyber attack. > > How about IPv6 with IPSEC? Wireless is the canonical case for geographic routing. Addresses as static or dynamic positions in space (either mutual time of flight or deriving refinable position from connection constraints), packet routing as the crow flies, local-knowledge routing tables that only know about a few km space around you, almost no admin traffic. Plus, routing logic thin enough to fit into deep embedded footprint, or be cast in hardware for relativistic speed cut-through. IPv6 can't handle most this, especially on the scale required. There's point in going IPv6, but at the same time one must be aware that this is just a patch, not a fix. From mv at cdc.gov Thu Aug 1 11:52:45 2002 From: mv at cdc.gov (Major Variola (ret)) Date: Thu, 01 Aug 2002 11:52:45 -0700 Subject: Mandatory hardware Message-ID: <3D49837D.B73B86BC@cdc.gov> TV makers may face mandate on digital receivers Wed Jul 31, 9:17 AM ET In an effort to jump-start the languid rollout of digital TV, federal regulators next week are expected to require all new TV sets to include digital receivers by 2006, say people familiar with the matter. TV makers say the mandate would boost the price of a TV by about $200, dampening sales. Broadcasters, who have pushed for such a rule, dispute the figure. http://news.yahoo.com/news?tmpl=story2&cid=711&ncid=738&e=8&u=/usatoday/20020731/tc_usatoday/4320647 Lets see... they think they can require crap in TVs, in teleco equiptment... anyone still doubt they will try a power grab on the motherboard? From lloyd at acm.jhu.edu Thu Aug 1 09:11:32 2002 From: lloyd at acm.jhu.edu (Jack Lloyd) Date: Thu, 1 Aug 2002 12:11:32 -0400 (EDT) Subject: Hollywood Hackers In-Reply-To: <810d9c7d6500f30c04400cbc44465dda@melontraffickers.com> Message-ID: On Wed, 31 Jul 2002, A.Melon wrote: > and on the left hand side of the page it says: > > At the moment, we do not support non-Javascript browsers. > > If they are concerned about security, Shouldn't they be avoiding > javascript? Shapiro has a strange love for Javascript. I don't know what that has to do with OpenCM either way, though... In any case, if you were running EROS you wouldn't have to worry about Javascript causing you problems. :P -Jack From schear at lvcm.com Thu Aug 1 12:29:58 2002 From: schear at lvcm.com (Steve Schear) Date: Thu, 01 Aug 2002 12:29:58 -0700 Subject: Mandatory hardware In-Reply-To: <3D49837D.B73B86BC@cdc.gov> Message-ID: <5.1.0.14.2.20020801121900.04fcec38@pop3.lvcm.com> At 11:52 AM 8/1/2002 -0700, Major Variola (ret) wrote: >TV makers may face mandate on digital receivers >Wed Jul 31, 9:17 AM ET > >In an effort to jump-start the languid rollout of digital TV, federal >regulators >next week are expected to require all new TV sets to include digital >receivers by 2006, say people familiar with the matter. > >TV makers say the mandate would boost the price >of a TV by about $200, dampening sales. >Broadcasters, who have pushed for such a rule, >dispute the figure. > >http://news.yahoo.com/news?tmpl=story2&cid=711&ncid=738&e=8&u=/usatoday/20020731/tc_usatoday/4320647 > >Lets see... they think they can require crap in TVs, in teleco >equiptment... anyone still doubt they will try a power >grab on the motherboard? I think a key difference here is that many, perhaps millions, of consumers are comfortable with assembling their own PCs from components and tweaking SW. How many consumers assemble their own TV sets? Volume black markets in underground motherboards and cracking SW may create a viable resistance. Also, the market for new wizbang PCs may be quickly drying up cutting off ======================================= Intel Bets Farm on Moore's Law By Tom Murphy -- Electronic News, 7/26/2002 Intel Corp. will supply 3GHz Pentium 4 processors in time for the holiday season, accelerating the company's previously announced timetable by nearly a quarter. Despite trends that show consumers increasingly hunting for value-priced systems with lower-performance processors, Intel is more determined than ever to stay on the Moore's Law growth curve of doubling process speeds every 18 to 24 months. \Even Gordon Moore, creator of the industry-defining Moore's Law, believes the trend line for adopting faster semiconductors is showing signs of flattening. In spite of that, Intel keeps tweaking the efficiencies of its manufacturing processes, churning out higher-speed machines and introducing eye-opening technology improvements such as HyperThreading and 300mm wafer manufacturing. But Intel's agenda may run deeper than rapid adoption of the new chips. A 3GHz machine would give Intel a substantial lead on rival Advanced Micro Devices Inc. (AMD). And with each new speed grade Intel introduces, it is able to increase the pressure on AMD by dropping the price on lower-performing parts. From mv at cdc.gov Thu Aug 1 12:46:28 2002 From: mv at cdc.gov (Major Variola (ret)) Date: Thu, 01 Aug 2002 12:46:28 -0700 Subject: Freedom of association denied in Ventura Cty Message-ID: <3D499014.EADB14F5@cdc.gov> (Note that this *is* political as the Fairgrounds are State property) Dress Code Keeps 9 Hells Angels Out of Fair in Ventura Security: The new policy is enforced after biker club members refuse to remove vests marked with group's insignia. Their leader says he will sue. By TRACY WILSON and HOLLY J. WOLCOTT, TIMES STAFF WRITERS Nine Hells Angels were denied entry to the Ventura County Fair on Wednesday evening after refusing to remove black leather vests emblazoned with the trademark winged skull of their motorcycle club. Stopped at a side entrance, the bikers were told by a security guard their clothing violated a fair policy that bans gang attire. The guard told George Christie Jr., president of the Ventura Hells Angels chapter, and his associates that they would have to remove any clothing bearing the name of their group to enter the fairgrounds. "I want to exercise my rights as a United States citizen," Christie responded. Holding up two tickets, for himself and the 9 1/2-year-old daughter of his fiancee, Christie asked, "You will not accept these tickets?" Security guard Mike Priester then handed Christie a copy of the fair's dress code policy and again told him he could not come through the gate unless he removed the clothing bearing the Angels insignia. As he walked away from the fairgrounds, Christie called the policy unconstitutional and said he will file a lawsuit challenging it. "I take offense," he said. "We are not a street gang, we are a motorcycle club.... We are going to seek legal action." Ventura attorney Kay Duffy, who had walked with the Hells Angels and a few of their family members from the group's nearby clubhouse to the fairgrounds, said she had hoped fair organizers would back down from the policy and allow the Angels inside. "The next step is the court system," she said. Fair spokesman Devlin Raley said organizers had no choice but to turn Christie and the others away. The dress policy aims to create a safe atmosphere for families to enjoy the fair, said Raley, adding that it will be enforced during the 12-day fair that began Wednesday. "They chose not to comply with the dress code. It was a challenge of the policy and the policy was enforced," Raley said, adding that the conversation with the Angels at the gate was peaceful. Concerned about gang violence, the fair board recently approved a tighter policy on gang attire. The policy specifically prohibits anyone wearing clothing, visible tattoos or other articles bearing the name or insignia of a criminal street gang from entering the fairgrounds. It does not ban the wearing of specific colors or sports team logos unless clothing has been altered to symbolize a gang. "This doesn't prevent anyone from coming to the fair," Ventura Police Lt. Ken Corney said this week. "You just can't be wearing gang attire." The policy identifies 27 local groups as criminal street gangs--including the Hells Angels and rival Mongols motorcycle clubs. Christie and lawyers representing the Hells Angels contend there is no evidence the club meets the legal definition of a criminal street gang. But police say recent convictions stemming from a massive drug-and-racketeering case involving the Hells Angels prompted law enforcement officials to deem the organization a criminal street gang. Corney said revisions to the fair's decade-old dress code were prompted by a recent appellate court decision in which justices in Northern California found a similar dress code unconstitutional. The ruling stemmed from a lawsuit filed by a Hells Angels member who was denied entry to the Sonoma County Fair after refusing to remove a vest emblazoned with the club name. The appellate court found the dress code vague and overbroad. Unlike the Sonoma decision, Ventura lawyers and police say the new policy is specific and are confident it would withstand a legal challenge. From mmotyka at lsil.com Thu Aug 1 12:02:23 2002 From: mmotyka at lsil.com (Michael Motyka) Date: Thu, 01 Aug 2002 13:02:23 -0600 Subject: Mandatory hardware Message-ID: <3D4985BF.5B8C2CA7@lsil.com> "Major Variola \(ret\)" wrote : > TV makers may face mandate on digital receivers > Wed Jul 31, 9:17 AM ET > > In an effort to jump-start the languid rollout of digital TV, federal > regulators > next week are expected to require all new TV sets to include digital > receivers by 2006, say people familiar with the matter. > > TV makers say the mandate would boost the price > of a TV by about $200, dampening sales. > Broadcasters, who have pushed for such a rule, > dispute the figure. > > http://news.yahoo.com/news?tmpl=story2&cid=711&ncid=738&e=8&u=/usatoday/2002> 0731/tc_usatoday/4320647 > > Lets see... they think they can require crap in TVs, in teleco > equiptment... anyone still doubt they will try a power > grab on the motherboard? > I have no doubt that they will try to screw the motherboard ( they are, after all, motherfuckers ) but I suspect it will turn out to be more difficult than they think to completely eradicate noncompliant devices. That is unless the new protocols that the administration wants require hw id fields and authentication before packets can be carried. Now that I think about it it could easily be like getting service to a cell phone only more so. Interestingly, wireless equipment could be used to make networks that are not part of the controlled net. Then of course those can be outlawed. It looks pretty grim. From wy1teht9f56814 at hotmail.com Fri Aug 2 01:43:53 2002 From: wy1teht9f56814 at hotmail.com (Leslie) Date: Thu, 01 Aug 2002 13:43:53 -1900 Subject: Toners and inkjet cartridges for less.... CCIGECKET Message-ID: <0000058331f5$000033a4$00002eb3@mx06.hotmail.com> A non-text attachment was scrubbed... Name: not available Type: text/html Size: 1878 bytes Desc: not available URL: From k.brown at ccs.bbk.ac.uk Thu Aug 1 05:53:02 2002 From: k.brown at ccs.bbk.ac.uk (Ken Brown) Date: Thu, 01 Aug 2002 13:53:02 +0100 Subject: Pizza with a credit card References: <3D486A4C.EB85CBCF@lsil.com> Message-ID: <3D492F2E.95C68161@ccs.bbk.ac.uk> Michael Motyka wrote: > Quite clearly cash has got to go! I'm not sure how tough this would be > to sneak past the slumbering electorate. Pretty tough I expect. But the > usage level is certainly going down while the percentage of electronic > transactions is skyrocketing. We've even had concresscritters suggesting > that the transport of $10K !interstate! should be illegal. You want to spend ten thou on pizza? Bloody hell, that's excessive. Any company selling you that much would lay themselves wide open to being sued because they got you addicted to fatty pizza and made you /obese/. They could be liable for millions! No respectable company could possibly allow that to happen. There should be a law against it! Our legislators must act to defend vulnerable corporations against predatory customers like you who spend too much money! Ken (who has to choose among the 10 or so local Pizza delivery companies in his part of London on the basis of which postcode database they use, because most of them think he lives in the wrong street) From mv at cdc.gov Thu Aug 1 14:23:48 2002 From: mv at cdc.gov (Major Variola (ret)) Date: Thu, 01 Aug 2002 14:23:48 -0700 Subject: thoughtcrime, art, mandatory youth education camps, AP, kirkland Message-ID: <3D49A6E4.8448B923@cdc.gov> Court rules student's artwork not a threat to police Published 9:35 a.m. PDT Thursday, August 1, 2002 CHICO, Calif. (AP) - A Pleasant Valley High School student's art class painting that showed him shooting a police officer who had cited him for possessing marijuana did not constitute a criminal threat, a state appeals court has ruled. The youth, identified in court papers only as Ryan D., never showed his painting to Chico Police Sgt. Lori MacPhail, the state Court of Appeals in Sacramento said Tuesday. The court said that paintings are ambiguous as a statement of intent and that the artwork didn't amount to a threat. The painting showed the boy "shooting the officer in the back of the head, blowing away pieces of her flesh and face," the court noted. "Without question, it was intemperate and demonstrated extremely poor judgment," presiding Justice Arthur Scotland wrote in his opinion. He added that "it does not appear to be anything other than pictorial ranting." The appeals court dismissed a finding by Butte County Superior Court Judge Ann Rutherford that the teenager had made a terrorist threat against MacPhail but let the marijuana violation stand. MacPhail said Wednesday she was disappointed by the ruling. "It's unfortunate that that could be the interpretation," she said. "It was clear and straightforward to me it was more than just a painting." MacPhail cited the teenager on Dec. 8, 1999, for possessing marijuana while off the high school campus during school hours. A month later, Ryan D., then 15, turned in a painting for his art class that showed a boy shooting a female police officer in the head. The artwork also included the letters "CPD," for Chico Police Department, and "67," MacPhail's badge number. The art instructor found the painting "disturbing" and "scary" and showed it to school administrators, who then showed it to MacPhail. The appeals court said there was no evidence the teenager ever intended to show the officer his artwork, Scotland noted. http://www.sacbee.com/state_wire/story/3804909p-4830234c.html From jamesd at echeque.com Thu Aug 1 14:33:43 2002 From: jamesd at echeque.com (James A. Donald) Date: Thu, 1 Aug 2002 14:33:43 -0700 Subject: Challenge to David Wagner on TCPA In-Reply-To: Message-ID: <3D4946C7.7343.1660D69@localhost> -- On 31 Jul 2002 at 23:45, AARG! Anonymous wrote: > So TCPA and Palladium "could" restrict which software you could > run. They aren't designed to do so, but the design could be > changed and restrictions added. Their design, and the institutions and software to be designed around them, is disturbingly similar to what would be needed to restrict what software we could run. TCPA institutions and infrastructure are much the same as SSSCA institutions and infrastructure. According to Microsoft, the end user can turn the palladium hardware off, and the computer will still boot. As long as that is true, it is an end user option and no one can object. But this is not what the content providers want. They want that if you disable the Fritz chip, the computer does not boot. What they want is that it shall be illegal to sell a computer capable of booting if the Fritz chip is disabled. If I have to give superroot powers to Joe in order to run Joe's software or play Joe's content, fair enough. But the hardware and institutions to implement this are disturbingly similar to the hardware and institutions needed to implement the rule that I have to give superroot powers to Joe in order to play Peter's software or content.. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG FQhKMpDHys7gyFWenHCK9p7+Xfh1DwpaqGKcztxk 20jFdJDiigV/b1fmHBudici59omqc/Ze0zXBVvQLk --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From ericm at lne.com Thu Aug 1 14:45:52 2002 From: ericm at lne.com (Eric Murray) Date: Thu, 1 Aug 2002 14:45:52 -0700 Subject: Challenge to David Wagner on TCPA In-Reply-To: ; from remailer@aarg.net on Wed, Jul 31, 2002 at 11:45:35PM -0700 References: Message-ID: <20020801144552.A14125@slack.lne.com> On Wed, Jul 31, 2002 at 11:45:35PM -0700, AARG! Anonymous wrote: > Peter Trei writes: > > AARG!, our anonymous Pangloss, is strictly correct - Wagner should have > > said "could" rather than "would". > > So TCPA and Palladium "could" restrict which software you could run. TCPA (when it isn't turned off) WILL restrict the software that you can run. Software that has an invalid or missing signature won't be able to access "sensitive data"[1]. Meaning that unapproved software won't work. Ok, technically it will run but can't access the data, but that it a very fine hair to split, and depending on the nature of the data that it can't access, it may not be able to run in truth. If TCPA allows all software to run, it defeats its purpose. Therefore Wagner's statement is logically correct. Yes, the spec says that it can be turned off. At that point you can run anything that doesn't need any of the protected data or other TCPA services. But, why would a software vendor that wants the protection that TCPA provides allow his software to run without TCPA as well, abandoning those protections? I doubt many would do so, the majority of TCPA-enabled software will be TCPA-only. Perhaps not at first, but eventually when there are enough TCPA machines out there. More likely, spiffy new content and features will be enabled if one has TCPA and is properly authenticated, disabled otherwise. But as we have seen time after time, today's spiffy new content is tomorrows virtual standard. This will require the majority of people to run with TCPA turned on if they want the content. TCPA doesn't need to be required by law, the market will require it. At some point, running without TCPA will be as difficult as avoiding MS software in an otherwise all-MS office.... theoretically possible, but difficult in practice. "TCPA could be required" by the government or MS or is, I agree, a red herring. It is not outside the realm of possibility, in fact I'd bet that someone at MS has seriously thought through the implications. But to my mind the "requirement by defacto standard" scenerio I outline above is much more likely, in fact it is certain to happen if TCPA gets in more than say 50% of computers. I worked for a short while on a very early version of TCPA with Geoff Strongin from AMD. We were both concerned that TCPA not be able to be used to restrict user's freedom, and at the time I thought that "you can always turn it off" was good enough. Now I'm not so sure. If someday all the stuff that you do with your computer touches data that can only be operated on by TCPA-enabled software, what are you going to do? BTW, what's your credentials? You seem familiar with the TCPA spec, which is no mean feat considering that it seems to have been written to make it as difficult to understand as possible (or perhaps someone hired an out-of-work ISO standards writer). I think that Peter's guess is spot on. Of course having you participate as a nym is much preferable to not having you participate at all, so don't feel as though you have to out yourself or stop posting. [1] TCPAmain_20v1_1a.pdf, section 2.2 Eric --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From ericm at lne.com Thu Aug 1 15:06:38 2002 From: ericm at lne.com (Eric Murray) Date: Thu, 1 Aug 2002 15:06:38 -0700 Subject: Challenge to David Wagner on TCPA In-Reply-To: <3D4946C7.7343.1660D69@localhost>; from jamesd@echeque.com on Thu, Aug 01, 2002 at 02:33:43PM -0700 References: <3D4946C7.7343.1660D69@localhost> Message-ID: <20020801150638.A14543@slack.lne.com> On Thu, Aug 01, 2002 at 02:33:43PM -0700, James A. Donald wrote: > According to Microsoft, the end user can turn the palladium > hardware off, and the computer will still boot. As long as that > is true, it is an end user option and no one can object. > > But this is not what the content providers want. They want that > if you disable the Fritz chip, the computer does not boot. What > they want is that it shall be illegal to sell a computer capable > of booting if the Fritz chip is disabled. Nope. They care that the Fritz chip is enabled whenever their content is played. There's no need to make it a legal requirement if the market makes it a practical requirement. The Linux folks just won't be able to watch the latest Maria Lopez or Jennifer Carey DVDs. But who cares about a few geeks? Only weirdos install alternative OSs anyhow, they can be ignored. Most of them will probably have second systems with the Fritz chip enabled anyhow. Eric From matchnews at foryou.match.com Thu Aug 1 13:12:50 2002 From: matchnews at foryou.match.com (Matchnews@match.com) Date: Thu, 01 Aug 2002 15:12:50 -0500 Subject: 15 ways to start your first email Message-ID: <20020801200437.E1FE6797E1D4@dal53005.match.com> Does your first impression thrill or kill? Add some kick to your conversation by... more http://www.match.com/matchscene/article.asp?bannerid=512555&articleid=38 Member Spotlight Meet our featured members: TDHandsome http://www.match.com/spotlight/showprofile.asp?UserID=4744434D4B474E&Bannerid=512583 SRW27 http://www.match.com/spotlight/showprofile.asp?UserID=42454B44464C494D&Bannerid=512584 3 lessons for dirty dates One guy stabs his poultry; another laps libations like Lassie. Would your date's table manners make Miss Manners swoon? http://www.match.com/matchscene/article.asp?bannerid=512561&articleid=168 matchTravel.com: Get carried away http://www.matchtravel.com You have received this email because you selected to receive Match.com updates and information when you registered. To unsubscribe, go to http://www.match.com/myinfo/emailoptions.asp log in, and un-check "Newsletter." Copyright 1993-2002 Match.com, Inc. Match.com and the radiant heart are registered trademarks of Match.com, Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/html Size: 23168 bytes Desc: not available URL: From ptrei at rsasecurity.com Thu Aug 1 13:14:06 2002 From: ptrei at rsasecurity.com (Trei, Peter) Date: Thu, 1 Aug 2002 16:14:06 -0400 Subject: Challenge to David Wagner on TCPA Message-ID: I'm going to respond to AARGH!, our new Sternlight, by asking two questions. 1. Why can't I control what signing keys the Fritz chip trusts? If the point of TCPA is make it so *I* can trust that *my* computer to run the software *I* have approved, and refuse to run something which a virus or Trojan has modifed (and this, btw, is the stated intention of TCPA), then why the hell don't I have full control over the keys? If I did, the thing might actually work to my benefit. The beneficiary of TCPA when I don't have ultimate root control is not I. It is someone else. That is not an acceptable situation. 2. It's really curious that Mr. AARGH! has shown up simultaneously on the lists and on sci.crypt, with the single brief of supporting TCPA. While I totally support his or her right to post anonymously, I can only speculate that anonymity is being used to disguise some vested interest in supporting TCPA. In other words, I infer that Mr. AARGH! is a TCPA insider, who is embarassed to reveal himself in public. So my question is: What is your reason for shielding your identity? You do so at the cost of people assuming the worst about your motives. Peter Trei PS: Speculating about the most tyrannical uses to which a technology can be put has generally proved a winning proposition. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From remailer at aarg.net Thu Aug 1 16:15:18 2002 From: remailer at aarg.net (AARG! Anonymous) Date: Thu, 1 Aug 2002 16:15:18 -0700 Subject: Challenge to David Wagner on TCPA Message-ID: <15848a6fde52312200b0ab232c1ff953@aarg.net> Peter Trei writes: > I'm going to respond to AARGH!, our new Sternlight, by asking two questions. > > 1. Why can't I control what signing keys the Fritz chip trusts? > > If the point of TCPA is make it so *I* can trust that *my* computer > to run the software *I* have approved, and refuse to run something > which a virus or Trojan has modifed (and this, btw, is the stated > intention of TCPA), then why the hell don't I have full control over > the keys? If I did, the thing might actually work to my benefit. > > The beneficiary of TCPA when I don't have ultimate root control is > not I. It is someone else. That is not an acceptable situation. You might be surprised to learn that under the TCPA, it is not necessary for the TPM (the so-called "Fritz" chip) to trust *any* signing keys! The TCPA basically provides two kinds of functionality: first, it can attest to the software which was booted and loaded. It does this by taking hashes of the software before transferring control to it, and storing those hashes in its internal secure registers. At a later time it can output those hashes, signed by its internal signature key (generated on-chip, with the private key never leaving the chip). The system also holds a cert issued on this internal key (which is called the Endorsement key), and this cert is issued by the TPM manufacturer (also called the TPME). But this functionality does not require storing the TPME key, just the cert it issued. Second, the TCPA provides for secure storage via a "sealing" function. The way this works, a key is generated and used to encrypt a data blob. Buried in the blob can be a hash of the software which was running at the time of the encryption (the same data which can be reported via the attestation function). Then, when the data is decrypted and "unsealed", the hash is compared to that which is in the TPM registers now. This can make it so that data which is encrypted when software system X boots can only be decrypted when that same software boots. Again, this functionality does not require trusting anyone's keys. Now, there is an optional function which does use the manufacturer's key, but it is intended only to be used rarely. That is for when you need to transfer your sealed data from one machine to another (either because you have bought a new machine, or because your old one crashed). In this case you go through a complicated procedure that includes encrypting some data to the TPME key (the TPM manufacturer's key) and sending it to the manufacturer, who massages the data such that it can be loaded into the new machine's TPM chip. So this function does require pre-loading a manufacturer key into the TPM, but first, it is optional, and second, it frankly appears to be so cumbersome that it is questionable whether manufacturers will want to get involved with it. OTOH it is apparently the only way to recover if your system crashes. This may indicate that TCPA is not feasible, because there is too much risk of losing locked data on a machine crash, and the recovery procedure is too cumbersome. That would be a valid basis on which to criticize TCPA, but it doesn't change the fact that many of the other claims which have been made about it are not correct. In answer to your question, then, for most purposes, there is no signing key that your TPM chip trusts, so the issue is moot. I suggest that you go ask the people who misled you about TCPA what their ulterior motives were, since you seem predisposed to ask such questions. > 2. It's really curious that Mr. AARGH! has shown up simultaneously > on the lists and on sci.crypt, with the single brief of supporting TCPA. > > While I totally support his or her right to post anonymously, I can only > speculate that anonymity is being used to disguise some vested > interest in supporting TCPA. In other words, I infer that Mr. AARGH! > is a TCPA insider, who is embarassed to reveal himself in public. > > So my question is: What is your reason for shielding your identity? > You do so at the cost of people assuming the worst about your > motives. The point of being anonymous is that there is no persistent identity to attribute motives to! Of course I have departed somewhat from this rule in the recent discussion, using a single exit remailer and maintaining continuity of persona over a series of messages. But feel free to make whatever assumptions you like about my motives. All I ask is that you respond to my facts. > Peter Trei > > PS: Speculating about the most tyrannical uses to which > a technology can be put has generally proved a winning > proposition. Of course, speculation is entirely appropriate - when labeled as such! But David Wagner gave the impression that he was talking about facts when he said, "The world is moving toward closed digital rights management systems where you may need approval to run programs," says David Wagner, an assistant professor of computer science at the University of California at Berkeley. "Both Palladium and TCPA incorporate features that would restrict what applications you could run." Do you think he was speculating? Or do you agree that if he makes such statements, he should base them on fact? TCPA appears to have no mechanism for the user to need approval in order to run programs. That is how the facts look to me, and if anyone can find out otherwise, I would appreciate knowing. Maybe someone could ask David Wagner what he based the above claim on? From remailer at aarg.net Thu Aug 1 16:45:15 2002 From: remailer at aarg.net (AARG!Anonymous) Date: Thu, 1 Aug 2002 16:45:15 -0700 Subject: Challenge to David Wagner on TCPA Message-ID: <43b43ffa9f7461355370e3d638940a21@aarg.net> Eric Murray writes: > TCPA (when it isn't turned off) WILL restrict the software that you > can run. Software that has an invalid or missing signature won't be > able to access "sensitive data"[1]. Meaning that unapproved software > won't work. > > [1] TCPAmain_20v1_1a.pdf, section 2.2 We need to look at the text of this in more detail. This is from version 1.1b of the spec: : This section introduces the architectural aspects of a Trusted Platform : that enable the collection and reporting of integrity metrics. : : Among other things, a Trusted Platform enables an entity to determine : the state of the software environment in that platform and to SEAL data : to a particular software environment in that platform. : : The entity deduces whether the state of the computing environment in : that platform is acceptable and performs some transaction with that : platform. If that transaction involves sensitive data that must be : stored on the platform, the entity can ensure that that data is held in : a confidential format unless the state of the computing environment in : that platform is acceptable to the entity. : : To enable this, a Trusted Platform provides information to enable the : entity to deduce the software environment in a Trusted Platform. That : information is reliably measured and reported to the entity. At the same : time, a Trusted Platform provides a means to encrypt cryptographic keys : and to state the software environment that must be in place before the : keys can be decrypted. What this means is that a remote system can query the local TPM and find out what software has been loaded, in order to decide whether to send it some data. It's not that unapproved software "won't work", it's that the remote guy can decide whether to trust it. Also, as stated earlier, data can be sealed such that it can only be unsealed when the same environment is booted. This is the part above about encrypting cryptographic keys and making sure the right software environment is in place when they are decrypted. > Ok, technically it will run but can't access the data, > but that it a very fine hair to split, and depending on the nature of > the data that it can't access, it may not be able to run in truth. > > If TCPA allows all software to run, it defeats its purpose. > Therefore Wagner's statement is logically correct. But no, the TCPA does allow all software to run. Just because a remote system can decide whether to send it some data doesn't mean that software can't run. And just because some data may be inaccessible because it was sealed when another OS was booted, also doesnt mean that software can't run. I think we agree on the facts, here. All software can run, but the TCPA allows software to prove its hash to remote parties, and to encrypt data such that it can't be decrypted by other software. Would you agree that this is an accurate summary of the functionality, and not misleading? If so, I don't see how you can get from this to saying that some software won't run. You might as well say that encryption means that software can't run, because if I encrypt my files then some other programs may not be able to read them. Most people, as you may have seen, interpret this part about "software can't run" much more literally. They think it means that software needs a signature in order to be loaded and run. I have been going over and over this on sci.crypt. IMO the facts as stated two paragraphs up are completely different from such a model. > Yes, the spec says that it can be turned off. At that point you > can run anything that doesn't need any of the protected data or > other TCPA services. But, why would a software vendor that wants > the protection that TCPA provides allow his software to run > without TCPA as well, abandoning those protections? That's true; in fact if you ran it earlier under TCPA and sealed some data, you will have to run under TCPA to unseal it later. The question is whether the advantages of running under TCPA (potentially greater security) outweigh the disadvantages (greater potential for loss of data, less flexibility, etc.). > I doubt many would do so, the majority of TCPA-enabled > software will be TCPA-only. Perhaps not at first, but eventually > when there are enough TCPA machines out there. More likely, spiffy > new content and features will be enabled if one has TCPA and is > properly authenticated, disabled otherwise. But as we have seen > time after time, today's spiffy new content is tomorrows > virtual standard. Right, the strongest case will probably be for DRM. You might be able to download all kinds of content if you are running an OS and application that the server (content provider) trusts. People will have a choice of using TCPA and getting this data legally, or avoiding TCPA and trying to find pirated copies as they do today. > This will require the majority of people to run with TCPA turned on > if they want the content. TCPA doesn't need to be required by law, > the market will require it. At some point, running without TCPA > will be as difficult as avoiding MS software in an otherwise all-MS > office.... theoretically possible, but difficult in practice. I am inclined to agree; in fact I have made many postings (anonymously of course) in recent weeks arguing that these systems will be entirely voluntary. If the functionality is useful, people will use it. Software vendors who use TCPA will compete with those who don't. The market will decide. I am not as certain as you that TCPA will win, but if it does, it will mean that TCPA is a good technology that solves real problems for people. > "TCPA could be required" by the government or MS or company here> is, I agree, a red herring. It is not outside > the realm of possibility, in fact I'd bet that someone at MS has > seriously thought through the implications. But to my mind > the "requirement by defacto standard" scenerio I outline above > is much more likely, in fact it is certain to happen if TCPA > gets in more than say 50% of computers. The points I made earlier were that TCPA is unlikely to be mandated, because it doesn't need to be; that TCPA should compete in the free market with other solutions; and that this approach actually expands the set of choices available to the participants. More choice is always good. > I worked for a short while on a very early version of TCPA with Geoff > Strongin from AMD. We were both concerned that TCPA not be able to > be used to restrict user's freedom, and at the time I thought that > "you can always turn it off" was good enough. Now I'm not so sure. > If someday all the stuff that you do with your computer touches data that can > only be operated on by TCPA-enabled software, what are you going to do? Well, you would use TCPA. But you have to look at how you got into that situation. The way it would have happened was by people voluntarily adopting TCPA before it became a de facto standard, simply because it was useful. > BTW, what's your credentials? You seem familiar with the TCPA spec, which > is no mean feat considering that it seems to have been written to > make it as difficult to understand as possible (or perhaps someone > hired an out-of-work ISO standards writer). I think that Peter's > guess is spot on. Of course having you participate as a nym > is much preferable to not having you participate at all, so don't > feel as though you have to out yourself or stop posting. I have no credentials in this area other than a general knowledge of crypto; I am just someone who was willing to devote some hours of his free time to educating himself on this technology. I agree that the spec is written very poorly. But let me put you on the spot: as someone who has a good understanding of TCPA, what do you think of Ross Anderson's TCPA FAQ at http://www.cl.cam.ac.uk/users/rja14/tcpa-faq.html? For example, how about his claim in answer 2, "Pirate software can be detected and deleted remotely." I must have missed that page of the TCPA spec. And then he builds on this a couple of paragraphs later: "There will be remote censorship: the mechanisms designed to delete pirated music under remote control may be used to delete documents that a court (or a software company) has decided are offensive...." He further builds on this later to claim (answer 11) that with TCPA, programs can be made to ignore documents created by pirated versions of Word, etc. All this has so little to do with anything related to TCPA that it boggles my mind. And then in answer 12 we're back to the claim that TCPA can stop computers from booting. Saddam better not buy a TCPA computer or the U.S. will render it inoperative, using a "serial number revocation list", according to the FAQ. Are you aware of any such capability in TCPA? I didn't see any such data structure. Ross Anderson means well, and so does David Wagner. But in the long run it hurts the credibility of critics when they make exaggerated and unfounded claims. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From rah at shipwright.com Thu Aug 1 15:21:05 2002 From: rah at shipwright.com (R. A. Hettinga) Date: Thu, 1 Aug 2002 18:21:05 -0400 Subject: Freedom of association denied in Ventura Cty In-Reply-To: <3D499014.EADB14F5@cdc.gov> References: <3D499014.EADB14F5@cdc.gov> Message-ID: At 12:46 PM -0700 on 8/1/02, Major Variola (ret) wrote: > Dress Code Keeps 9 Hells Angels Out of Fair in Ventura > Security: The new policy is enforced after biker club members refuse to > remove vests marked with group's insignia. Their leader says he will > sue. What ever happened to "One on all, all on one?" Cheers, RAH -- ----------------- R. A. Hettinga The Internet Bearer Underwriting Corporation 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire' From jamesd at echeque.com Thu Aug 1 19:17:40 2002 From: jamesd at echeque.com (James A. Donald) Date: Thu, 1 Aug 2002 19:17:40 -0700 Subject: TCPA In-Reply-To: <43b43ffa9f7461355370e3d638940a21@aarg.net> Message-ID: <3D498954.3356.26A0501@localhost> -- In an anarchist society, or in a world where government had given up on copyright and intellectual property, TCPA/Palladium would be a great thing, a really good substitute for law, much more effectual, much cheaper, and much less dangerous than law. In a world where we have anticircumvention laws and ever growing patent and copyright silliness, it seems a dangerously powerful addition to law. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG 6FaJusAR8fMsVvaFm9l3vbuyiQwio/YrBFLpyT6c 2Db/Fk0MeNi3mjdoDTo2IGzHeelYts0/xqiEjUFmA --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From jamesd at echeque.com Thu Aug 1 19:17:41 2002 From: jamesd at echeque.com (James A. Donald) Date: Thu, 1 Aug 2002 19:17:41 -0700 Subject: Challenge to David Wagner on TCPA In-Reply-To: References: <15848a6fde52312200b0ab232c1ff953@aarg.net> Message-ID: <3D498955.13902.26A0551@localhost> -- On 2 Aug 2002 at 3:31, Sampo Syreeni wrote: > More generally, as long as we have computers which allow data to > be addressed as code and vice versa, the ability to control use > of data will necessarily entail ability to control use of code. > So, either we will get systems where circumventing copyright > controls is trivial or ones where you cannot compile your own > code. All the rest is just meaningless syntax. The announced purpose of TCPA/Palladium is to introduce some intermediate cases. For example you could compile your own code, and then encrypt it so that it can only run on a specific target computer. As somone who sells code, I would think this would be a great idea, were it not for the excesses we have been seeing from the IP lobbyists. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG iB5WVaGfx+zq5Dani1KQGdZIU5Kl21LDrc7w4e1m 2PoKhj2EuUKqjKlZ/RN3VXdP0TFKxmpO/rR69KupZ --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From jays at panix.com Thu Aug 1 17:05:38 2002 From: jays at panix.com (Jay Sulzberger) Date: Thu, 1 Aug 2002 20:05:38 -0400 (EDT) Subject: Challenge to David Wagner on TCPA In-Reply-To: <15848a6fde52312200b0ab232c1ff953@aarg.net> Message-ID: On Thu, 1 Aug 2002, AARG!Anonymous wrote: > Peter Trei writes: > > > I'm going to respond to AARGH!, our new Sternlight, by asking two questions. > > > > 1. Why can't I control what signing keys the Fritz chip trusts? > > > > If the point of TCPA is make it so *I* can trust that *my* computer > > to run the software *I* have approved, and refuse to run something > > which a virus or Trojan has modifed (and this, btw, is the stated > > intention of TCPA), then why the hell don't I have full control over > > the keys? If I did, the thing might actually work to my benefit. > > > > The beneficiary of TCPA when I don't have ultimate root control is > > not I. It is someone else. That is not an acceptable situation. > > You might be surprised to learn that under the TCPA, it is not necessary > for the TPM (the so-called "Fritz" chip) to trust *any* signing keys! > > The TCPA basically provides two kinds of functionality: first, it can > attest to the software which was booted and loaded. It does this by > taking hashes of the software before transferring control to it, and > storing those hashes in its internal secure registers. At a later > time it can output those hashes, signed by its internal signature > key (generated on-chip, with the private key never leaving the chip). > The system also holds a cert issued on this internal key (which is called > the Endorsement key), and this cert is issued by the TPM manufacturer > (also called the TPME). But this functionality does not require storing > the TPME key, just the cert it issued. > > Second, the TCPA provides for secure storage via a "sealing" function. > The way this works, a key is generated and used to encrypt a data blob. > Buried in the blob can be a hash of the software which was running > at the time of the encryption (the same data which can be reported > via the attestation function). Then, when the data is decrypted and > "unsealed", the hash is compared to that which is in the TPM registers > now. This can make it so that data which is encrypted when software > system X boots can only be decrypted when that same software boots. > Again, this functionality does not require trusting anyone's keys. > > Now, there is an optional function which does use the manufacturer's key, > but it is intended only to be used rarely. That is for when you need to > transfer your sealed data from one machine to another (either because you > have bought a new machine, or because your old one crashed). In this > case you go through a complicated procedure that includes encrypting > some data to the TPME key (the TPM manufacturer's key) and sending it > to the manufacturer, who massages the data such that it can be loaded > into the new machine's TPM chip. > > So this function does require pre-loading a manufacturer key into the > TPM, but first, it is optional, and second, it frankly appears to be so > cumbersome that it is questionable whether manufacturers will want to > get involved with it. OTOH it is apparently the only way to recover > if your system crashes. This may indicate that TCPA is not feasible, > because there is too much risk of losing locked data on a machine crash, > and the recovery procedure is too cumbersome. That would be a valid > basis on which to criticize TCPA, but it doesn't change the fact that > many of the other claims which have been made about it are not correct. > > In answer to your question, then, for most purposes, there is no signing > key that your TPM chip trusts, so the issue is moot. I suggest that you > go ask the people who misled you about TCPA what their ulterior motives > were, since you seem predisposed to ask such questions. > > > > 2. It's really curious that Mr. AARGH! has shown up simultaneously > > on the lists and on sci.crypt, with the single brief of supporting TCPA. > > > > While I totally support his or her right to post anonymously, I can only > > speculate that anonymity is being used to disguise some vested > > interest in supporting TCPA. In other words, I infer that Mr. AARGH! > > is a TCPA insider, who is embarassed to reveal himself in public. > > > > So my question is: What is your reason for shielding your identity? > > You do so at the cost of people assuming the worst about your > > motives. > > The point of being anonymous is that there is no persistent identity to > attribute motives to! Of course I have departed somewhat from this rule > in the recent discussion, using a single exit remailer and maintaining > continuity of persona over a series of messages. But feel free to make > whatever assumptions you like about my motives. All I ask is that you > respond to my facts. > > > > Peter Trei > > > > PS: Speculating about the most tyrannical uses to which > > a technology can be put has generally proved a winning > > proposition. > > Of course, speculation is entirely appropriate - when labeled as such! > But David Wagner gave the impression that he was talking about facts > when he said, > > "The world is moving toward closed digital rights management systems > where you may need approval to run programs," says David Wagner, > an assistant professor of computer science at the University of > California at Berkeley. "Both Palladium and TCPA incorporate features > that would restrict what applications you could run." > > Do you think he was speculating? Or do you agree that if he makes > such statements, he should base them on fact? TCPA appears to have > no mechanism for the user to need approval in order to run programs. > That is how the facts look to me, and if anyone can find out otherwise, > I would appreciate knowing. Maybe someone could ask David Wagner what > he based the above claim on? By your own account the system is designed to give root in an manner claimed to be incorrigible by me, but certainly inconvenient to me, to others. May I ask whether your definition of TCPA includes the legal and economic infrastructures whose purpose is to require that at some date in the future all computers sold be TCPA enabled? If so what is the claimed advantage to me here? Since I can certainly today let you ssh in to my box and run stuff in a sandbox and I can certainly decide to not observe you running your stuff. TCPA in any form offers no advantages whatsoever except to the Englobulators. oo--JS. From jays at panix.com Thu Aug 1 17:41:23 2002 From: jays at panix.com (Jay Sulzberger) Date: Thu, 1 Aug 2002 20:41:23 -0400 (EDT) Subject: Challenge to David Wagner on TCPA In-Reply-To: <43b43ffa9f7461355370e3d638940a21@aarg.net> Message-ID: On Thu, 1 Aug 2002, AARG!Anonymous wrote: > Eric Murray writes: > > TCPA (when it isn't turned off) WILL restrict the software that you > > can run. Software that has an invalid or missing signature won't be > > able to access "sensitive data"[1]. Meaning that unapproved software > > won't work. > > > > [1] TCPAmain_20v1_1a.pdf, section 2.2 > > We need to look at the text of this in more detail. This is from > version 1.1b of the spec: > > : This section introduces the architectural aspects of a Trusted Platform > : that enable the collection and reporting of integrity metrics. > : > : Among other things, a Trusted Platform enables an entity to determine > : the state of the software environment in that platform and to SEAL data > : to a particular software environment in that platform. Claimed advantage to me here? > : > : The entity deduces whether the state of the computing environment in > : that platform is acceptable and performs some transaction with that > : platform. If that transaction involves sensitive data that must be > : stored on the platform, the entity can ensure that that data is held in > : a confidential format unless the state of the computing environment in > : that platform is acceptable to the entity. Claimed advantage to me here? > : > : To enable this, a Trusted Platform provides information to enable the > : entity to deduce the software environment in a Trusted Platform. That > : information is reliably measured and reported to the entity. At the same > : time, a Trusted Platform provides a means to encrypt cryptographic keys > : and to state the software environment that must be in place before the > : keys can be decrypted. > > What this means is that a remote system can query the local TPM and > find out what software has been loaded, in order to decide whether to > send it some data. It's not that unapproved software "won't work", > it's that the remote guy can decide whether to trust it. Claimed advantage to me here? > > Also, as stated earlier, data can be sealed such that it can only be > unsealed when the same environment is booted. This is the part above > about encrypting cryptographic keys and making sure the right software > environment is in place when they are decrypted. Claimed advantage to me here? > > > Ok, technically it will run but can't access the data, > > but that it a very fine hair to split, and depending on the nature of > > the data that it can't access, it may not be able to run in truth. > > > > If TCPA allows all software to run, it defeats its purpose. > > Therefore Wagner's statement is logically correct. > > But no, the TCPA does allow all software to run. Just because a remote > system can decide whether to send it some data doesn't mean that software > can't run. And just because some data may be inaccessible because it > was sealed when another OS was booted, also doesnt mean that software > can't run. Claimed advantage to me here? > > I think we agree on the facts, here. All software can run, but the TCPA > allows software to prove its hash to remote parties, and to encrypt data > such that it can't be decrypted by other software. Would you agree that > this is an accurate summary of the functionality, and not misleading? Of course we do not agree. Under the DRM/TCPA regime I cannot legally do the following thing: Spoof your handshake and then run my cracker on the encrypted data you send me. So some software will not legally run under DRM/TCPA. > > If so, I don't see how you can get from this to saying that some software > won't run. You might as well say that encryption means that software > can't run, because if I encrypt my files then some other programs may > not be able to read them. See above. Please be precise in your response. > > Most people, as you may have seen, interpret this part about "software > can't run" much more literally. They think it means that software needs > a signature in order to be loaded and run. I have been going over and > over this on sci.crypt. IMO the facts as stated two paragraphs up are > completely different from such a model. No. They are exactly "software needs to be signed to run". Otherwise why cannot I run cp on the movie that Time-Warner-AOL sends me? > > > Yes, the spec says that it can be turned off. At that point you > > can run anything that doesn't need any of the protected data or > > other TCPA services. But, why would a software vendor that wants > > the protection that TCPA provides allow his software to run > > without TCPA as well, abandoning those protections? > > That's true; in fact if you ran it earlier under TCPA and sealed some > data, you will have to run under TCPA to unseal it later. The question > is whether the advantages of running under TCPA (potentially greater > security) outweigh the disadvantages (greater potential for loss of > data, less flexibility, etc.). Ah, so much for your claim that all software that now runs will run under DRM/TCPA. You admit that software I may now run cannot be run under DRM/TCPA. > > > I doubt many would do so, the majority of TCPA-enabled > > software will be TCPA-only. Perhaps not at first, but eventually > > when there are enough TCPA machines out there. More likely, spiffy > > new content and features will be enabled if one has TCPA and is > > properly authenticated, disabled otherwise. But as we have seen > > time after time, today's spiffy new content is tomorrows > > virtual standard. > > Right, the strongest case will probably be for DRM. You might be able > to download all kinds of content if you are running an OS and application > that the server (content provider) trusts. People will have a choice of > using TCPA and getting this data legally, or avoiding TCPA and trying to > find pirated copies as they do today. No. Under DRM every "hole" must be plugged. Else what is the bleating about the "analogue hole"? So obviously no non-DRM computer may be allowed to be sold to the general public under DRM. Demonstration by formal admission of pro-DRM forces: Section 4.12 of the Final Report of the Broadcast Protection Discussion Group, found in the main body of the report at http://www.eff.org/IP/Video/HDTV/bpdg-report > > > This will require the majority of people to run with TCPA turned on > > if they want the content. TCPA doesn't need to be required by law, > > the market will require it. At some point, running without TCPA > > will be as difficult as avoiding MS software in an otherwise all-MS > > office.... theoretically possible, but difficult in practice. > > I am inclined to agree; in fact I have made many postings (anonymously > of course) in recent weeks arguing that these systems will be entirely > voluntary. If the functionality is useful, people will use it. > Software vendors who use TCPA will compete with those who don't. > The market will decide. I am not as certain as you that TCPA will win, > but if it does, it will mean that TCPA is a good technology that solves > real problems for people. Ah, now you have fallen off the high line of the long troll. This is simply beneath the level of your game. What you should do is claim that even if DRM is enforced all over the world, that this must be, from a higher and more encompassing viewpoint, a triumph of "the market" and the will of the people. > > > "TCPA could be required" by the government or MS or > company here> is, I agree, a red herring. It is not outside > > the realm of possibility, in fact I'd bet that someone at MS has > > seriously thought through the implications. But to my mind > > the "requirement by defacto standard" scenerio I outline above > > is much more likely, in fact it is certain to happen if TCPA > > gets in more than say 50% of computers. > > The points I made earlier were that TCPA is unlikely to be mandated, > because it doesn't need to be; that TCPA should compete in the free > market with other solutions; and that this approach actually expands the > set of choices available to the participants. More choice is always good. Good grief! Please retuen to a less hopelessly ridiculous line. If TCPA is so good, and it "might win in the market", well, let 10,000 TCPA implementations bloom! > > > > I worked for a short while on a very early version of TCPA with Geoff > > Strongin from AMD. We were both concerned that TCPA not be able to > > be used to restrict user's freedom, and at the time I thought that > > "you can always turn it off" was good enough. Now I'm not so sure. > > If someday all the stuff that you do with your computer touches data that can > > only be operated on by TCPA-enabled software, what are you going to do? > > Well, you would use TCPA. But you have to look at how you got into that > situation. The way it would have happened was by people voluntarily > adopting TCPA before it became a de facto standard, simply because it > was useful. > > > > BTW, what's your credentials? You seem familiar with the TCPA spec, which > > is no mean feat considering that it seems to have been written to > > make it as difficult to understand as possible (or perhaps someone > > hired an out-of-work ISO standards writer). I think that Peter's > > guess is spot on. Of course having you participate as a nym > > is much preferable to not having you participate at all, so don't > > feel as though you have to out yourself or stop posting. > > I have no credentials in this area other than a general knowledge of > crypto; I am just someone who was willing to devote some hours of his > free time to educating himself on this technology. I agree that the > spec is written very poorly. > > But let me put you on the spot: as someone who has a good > understanding of TCPA, what do you think of Ross Anderson's TCPA FAQ > at http://www.cl.cam.ac.uk/users/rja14/tcpa-faq.html? For example, > how about his claim in answer 2, "Pirate software can be detected and > deleted remotely." I must have missed that page of the TCPA spec. > And then he builds on this a couple of paragraphs later: "There will > be remote censorship: the mechanisms designed to delete pirated music > under remote control may be used to delete documents that a court (or > a software company) has decided are offensive...." He further builds > on this later to claim (answer 11) that with TCPA, programs can be made > to ignore documents created by pirated versions of Word, etc. All this > has so little to do with anything related to TCPA that it boggles my mind. > > And then in answer 12 we're back to the claim that TCPA can stop computers > from booting. Saddam better not buy a TCPA computer or the U.S. will > render it inoperative, using a "serial number revocation list", according > to the FAQ. Are you aware of any such capability in TCPA? I didn't see > any such data structure. > > Ross Anderson means well, and so does David Wagner. But in the long > run it hurts the credibility of critics when they make exaggerated and > unfounded claims. I have demonstrated, by example, and by official statements of your own side, that your claims are incorrect.. I recommend a broader. looser, and more amusing approach to the defense of DRM. I like the old Hegelian standard: "THE OVERMIND NEEDS DRM NOW SO AS TO BE BORN WITHOUT RIPPING ALL HUMAN HISTORY INTO NON-EXISTENCE BY BACK-REACTION." oo--JS. From jon at callas.org Thu Aug 1 20:47:05 2002 From: jon at callas.org (Jon Callas) Date: Thu, 01 Aug 2002 20:47:05 -0700 Subject: Challenge to David Wagner on TCPA In-Reply-To: Message-ID: On 8/1/02 1:14 PM, "Trei, Peter" wrote: > So my question is: What is your reason for shielding your identity? > You do so at the cost of people assuming the worst about your > motives. Is this a tacit way to suggest that the only people who need anonymity or pseudonymity are those with something to hide? Jon --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From remailer at aarg.net Thu Aug 1 21:15:09 2002 From: remailer at aarg.net (AARG! Anonymous) Date: Thu, 1 Aug 2002 21:15:09 -0700 Subject: Challenge to David Wagner on TCPA Message-ID: Sampo Syreeni writes: > On 2002-08-01, AARG!Anonymous uttered to ptrei at rsasecurity.com,...: > > >It does this by taking hashes of the software before transferring > >control to it, and storing those hashes in its internal secure > >registers. > > So, is there some sort of guarantee that the transfer of control won't be > stopped by a check against cryptographic signature within the executable > itself, in the future? That sort of thing would be trivial to enforce via > licencing terms, after all, and would allow for the introduction of a > strictly limited set of operating systems to which control would be > transferred. TCPA apparently does not have "licensing terms" per se. They say, in their FAQ, http://www.trustedcomputing.org/docs/Website_TCPA%20FAQ_0703021.pdf, "The TCPA spec is currently set up as a 'just publish' IP model." So there are no licensing terms to enforce, and no guarantees that people won't do bad things outside the scope of the spec. Of course, you realize that the same thing is true with PCs today, right? There are few guarantees in this life. If you think about it, TCPA doesn't actually facilitate the kind of crypto-signature-checking you are talking about. You don't need all this fancy hardware and secure hashes to do that. Your worrisome signature checking would be applied on the software which *hasn't yet been loaded*, right? All the TCPA hardware will give you is a secure hash on the software which has already loaded before you ran. That doesn't help you; in fact your code can pretty well predict the value of this, given that it is running. Think about this carefully, it is a complicated point but you can get it if you take your time. In short, to implement a system where only signed code can run, TCPA is not necessary and not particularly helpful. > I'm having a lot of trouble seeing the benefit in TCPA > without such extra measures, given that open source software would likely > evolve which circumvented any protection offered by the more open ended > architecture you now describe. I don't follow what you are getting at with the open source. Realize that when you boot a different OS, the TCPA attestation features will allow third parties to detect this. So your open source OS cannot masquerade as a different one and fool a third party server into downloading data to your software. And likewise, data which was sealed (encrypted) under a secure OS cannot be unsealed once a different OS boots, because the sealing/unsealing is all done on-chip, and the chip uses the secure hash registers to check if the unsealing is allowed. > >Then, when the data is decrypted and "unsealed", the hash is compared to > >that which is in the TPM registers now. This can make it so that data > >which is encrypted when software system X boots can only be decrypted > >when that same software boots. > > Again, such values would be RE'd and reported by any sane open source OS > to the circuitry, giving access to whatever data there is. If this is > prevented, one can bootstrap an absolutely secure platform where whatever > the content provider says is the Law, including a one where every piece of > runnable OS software actually enforces the kind of control over > permissible signatures Peter is so worried about. Where's the guarantee > that this won't happen, one day? Not sure I follow this here... the sealed data cannot be reported by an open source OS because the secret keys never leave the chip without being themselves encrypted. As for your second proposal, you are suggesting that you could write an OS which would only run signed applications? And run it on a TCPA platform? Sure, I guess you could. But you wouldn't need TCPA features to do it. See the comments above: any OS today could be modified to only run apps that were signed with some special key. You shouldn't blame TCPA for this. > >In answer to your question, then, for most purposes, there is no signing > >key that your TPM chip trusts, so the issue is moot. > > At the hardware level, yes. TCPA is a hardware spec. Peter was asking about TCPA, and I gave him the answer. You can hypothesize all the facist software you want, but you shouldn't blame these fantasies on TCPA. > At the software one, it probably won't be, > even in the presence of the above considerations. After you install your > next Windows version, you will be tightly locked in with whatever M$ > throws at you in their DLL's, Doesn't Microsoft already sign their system DLLs in NT? > and as I pointed out, there's absolutely no > guarantee Linux et al. might well be shut out by extra features, in the > future. In the end what we get is an architecture, which may not embody > Peter's concerns right now, but which is built from the ground up to bring > them into being, later. Again, you are being entirely hypothetical here. Please describe exactly how either attestation or secure storage would assist in creating a boot loader that would refuse to run Linux, or whatever other horrible disaster you envision. > More generally, as long as we have computers which allow data to be > addressed as code and vice versa, the ability to control use of data will > necessarily entail ability to control use of code. Look, I have describe in detail how it works, and you're just giving these meaningless slogans. TCPA lets you prove to other people what code you are running; it lets you seal data such that it can only be unsealed by the same code which sealed it. How does this relate to your little saying? The ability to encrypt data means... the ability to encrypt code? So what? > So, either we will get > systems where circumventing copyright controls is trivial or ones where > you cannot compile your own code. All the rest is just meaningless syntax. > In that light I bet you can guess why people are worried about TCPA and > its ilk. Nonsense, there is no need to stop people from compiling their own code in order to protect data! The steps are simple: trusted app runs, connects to server; proves it is trusted via TCPA attestation; server downloads data to trusted app based on attestation; trusted app seals data. User reboots into open source OS, can't access data because it is sealed; can't fool server because of attestation. He can write all the code he wants and it won't change this logic. TCPA does not depend on stopping people from running their own code; it depends on verifying what code is running, and tying it to the crypto. That's all. From uktfu at cosy.sbg.ac.at Fri Aug 2 09:16:51 2002 From: uktfu at cosy.sbg.ac.at (Garcia) Date: Thu, 01 Aug 2002 21:16:51 -1900 Subject: Stoner says, "Call now, we're open" Message-ID: <200208020551.AAB00397@einstein.ssz.com> *************************** Now Open Seven Days A Week! Call 1-623-974-2295 10:30 AM to 7:00 PM (Mountain Time) *************************** >From the ethnobotanical herbalists who brought the herba supplementals; Kathmandu Temple Kiff “1” & “2” “Personal-Choice”, pipe-smoking products/substances to the common market!!! We are finally able to offer for your “Sensitive/Responsive”, “Personal Choice” Smoking Enjoyment….the “Seventh Heaven” Temple “3” Ragga Dagga (TM) Pipe-Smoking Substance Supplemental Product…. Introduced after three years of research and development; Temple “3” is “Personal Choice” legal Smoking/Indulgence….Redefined!!! Thanks to recent, dramatic, technological advances in the laboratorial processes for the extraction of alkaloid and glycocide supplements from botanicals/herbas/plant matter, we are now able to offer….in more cultivated/enhanced/viripotent/substantiated format….what had actually already been the most significant, lawful, “Personal Choice” smoking substance available on the planet…. “Seventh Heaven” Temple “3” Ragga Dagga (TM) is the sweet, sweet evolution of all of that…. * A 20 X MORE VIRIPOTENT HERBA SUPPLEMENT THAN ITS PREDESSORS (TEMPLE “1” & “2”). * HAPPIER, HAPPY SMOKING!!! * INDEED, A DEPRESSIVE REGRESSIVE, SUPPLEMENTAL MOOD-ENHANCER. * MORE SOPHISTICATED, UPLIFTING & POISED THAN ILLEGAL SMOKING SUBSTANCES. * NO REGULATION, NO ILLEGALITY, NO FAILED DRUG TESTS!!! * INHIBITS STRESS AND ANXIETY…. * INSPIRES CONTEMPLATIVENESS & CREATIVITY…. * ENHANCES THE SEXUAL EXPERIENCE!!! * GENERATES MORE RESTFUL SLEEP & LUCID DREAMING…. * A SIGNIFICANT HERBA / BOTANICAL SUPPLEMENT IN THE BATTLES AGAINST DRUG AND ALCOHOL DEPENDENCE!!!! * EASILY IGNITED & STOKED. * SMOKES SWEETLY! * ABSOLUTELY LEGAL / NON-INVASIVE / NO DOWNSIDE!!! * LINGERS FOR A GOOD, GOODLY WHILE! * POSSESSES MANY FINE GANJA VIRTUES WITH NONE OF THE NEGATIVES!!! * JUST A LITTLE SNIPPET / PINCH GOES A LONG, LONG WAY….JUST 4 OR 5 DRAWS OF YOUR PIPE (A traditional hand herb-pipe is included with each package of Ragga Dagga). Temple “3” Ragga Dagga (TM) is an exclusive, botanical/herba, proprietary; Nepalesian formulated, ultra-“Sensitive/Responsive”, pipe-smoking/stoking substance and is undoubtedly the most prestigious, legal offering of its sort on the planet!!! So smokin/stokin potent is this cutting edge formulation, that we have even been able to establish a very happy clientele market base within the hard-core stoner arena and have made positive, happy, smoking differences in many, many lives. ABSOLUTELY LEGAL! MARVELOUSLY POTENT!! A one-of-a-kind, proprietary amalgamation, comprised of extreme high-ratio concentrated extracts which are derived from various common and uncommon “sensitive/responsive” herbas primarily cultivated within and imported from the southern and eastern hemispheres; Temple “3” Ragga Dagga (TM) high-ratio factored botanical extractions are master-crafted into solid jiggets/bars which are structurally reminiscent of what one might find in the “happiness” coffee and tea houses of Nepal/Kathmandu/Amsterdam and in many aspects, possesses a more collected and more focused, less scattered ambiance. Ingredients: Temple smoking substances and Temple “3” Ragga Dagga (TM) have always been and will always remain exclusive EXOTIC BOTANICAL RESOURCES “House Smoking Substance Specialties”. Temple “3” Ragga Dagga (TM) is both a euphonious/celebratory and relaxing/calming pipe-smoking substance that offers both physical and cerebral significators. Temple “3” Ragga Dagga (TM) is a proprietary, prescribed botanical amalgamation which includes the following synergistically/synesthesia conglomerated, core-refined, ratio-enhanced herbas/botanicals, resins, essences, flower-tops and oils in extreme ratio extractment ranging from 8.5 to 1, to 100 to 1 viripotent concentrations Drachasha, Chavana Prash, Trikatu, Black Seed Herb, Hybrid Flowering Turnera Diffusa, Capillaris Herba, Angelica Root, Wild Dagga mature leaf matter, Haritaki, Shatavari, Labdunum, Neroli, Unicorn Root, Papaver Rhoes, Dendrobian stems, Calea Zacalechichi buddings, Rue, Amla, Salvia Divinorum, Crocus Sativa, Lotus and Gokshu! ra! cuttings. Please Note: Temple “3” Ragga Dagga (TM) is an absolutely legal, herba/botanical, “Personal Choice”, pipe-smoking substantiality product!!! No included botanical factor therein is regulated by law or considered to be harmful by regulatory agencies. There is no tobacco in Temple “3” Ragga Dagga (TM). There is certainly no cannabis/marijuana in Temple “3” Ragga Dagga (TM)…. And although we are not age-governed by law….Temple “3” Ragga Dagga (TM) is intended exclusively for sophisticated adult usage! Subsequently, it is our MANDATORY ethical policy that Temple “3” Ragga Dagga (TM) may not be sold, offered, or given to any person that has not attained at least twenty-one years of age. All things in their time…. As well, Temple “3” Ragga Dagga (TM) is not intended for use during work or while driving. It should not be enjoyed during pregnancy nor is it intended to supercede physician’s care in any regard. ======================================================== Here is what our customers are saying about the Temple “3” Ragga Dagga (TM) phenomenon: “To whom it may concern, I was skeptical when I first read your ad. I grew up in the 70’s & 80’s. I was a hard core (alternative smoker) then. So I knew my stuff. But drug tests stopped that! Now I am disabled from a degenerative muscle, ligament, and tendon disease. I was smoking (an illegal product) for the pain and nausea. Now I have something just as good; Temple 3, but cheaper, and it is legal! I also have a lot of trouble sleeping, but the Capillaris Herba made into tea works and smells great! Your products that I tried so far, are as good or better than your ads say! That is hard to find nowadays in a company. Who ever put this stuff together is a botanical genius. I will be a customer for life! Also, I talked with a lady on the phone when I was ordering, and asked her to find out if I could get my products and samples to hand out for free. And just send the customers to you. Or get a discount on products that I could sell retail to people. I would prefer the earlier one becau! se! , I can just talk about your products, I am a great salesman (about 10 years experience), I could hand out flyers, give out little 1 gram pieces as samplers with your business card enclosed, etc.. I am going to be unable to work a regular job for a while, maybe indefinitely? This deal would give me my own products and samples for free? You would get free advertising, word of mouth, samples into peoples hands to try, someone that is very good with computers, someone who studied about mail order, Internet, cold calling, small business, good with people, etc.. I would like to be doing something, even if I would get on Social Security Disability. It is very disheartening not being able to work to support my 2 teenage boys, or do a lot of the things I used to do! At least I would be able to do something worthwhile. And great products makes it real easy to sell. Let me know what you think? Sincerely, RJ” Location: Midwest, U.S.A. “Thank you so much for the Ragga. It is everything you guys claim, and then some! I was a bit skeptical when I read your description of its effects, but there is literally no exaggeration in your advertisements. How nice that this is non-prohibited! It tastes great and feels great too! I am so glad I took a chance and ordered. Blessings to all of you.” -- Frankie R. Location: West Coast, USA “I’m a man of my 40’s and I really know my stuff. I don’t drink or do illegal drugs anymore and have found a much more spiritual path. I used to have to take Valium in the past. Not anymore with the Temple “3”. It really amazes me how this stuff tastes like the Lebanese and blonde stuff I used to smoke in the 70’s. I am very satisfied with all of your products. I like them a lot and will be a customer for life for sure. Whoever makes this stuff is an ARTIST at it. Who would have thought?!” -- A.J. Location: United Kingdom ======================================================== Finally, we realize of course that this Temple “3” Ragga Dagga (TM) is not inexpensive…. (Temple “3” Ragga Dagga (TM) is a very, very Sweet Smoke and “sweetness” is never acquired inexpensively. Such is the way of the Economic Tao....), nor, as a matter of fact, is it inexpensive for us to acquire, factor or master-craft…. Quite simply, it is the very best of its Kind that there is to be acquired. Just a snippet/pinch of this Temple “3” Ragga Dagga (TM)…. Four or five draws of your pipe….as is the magical way….lingers for a good, goodly while!!! (An herb pipe and usage instructions are included with each Temple “3” Ragga Dagga (TM) Package.) “Seventh Heaven” Temple “3” Ragga Dagga (TM) is offered exclusively in 56 gram (2 oz.) and 22 gram (.75 oz.) jiggets/bars for $115.00 and $65.00 respectively. Sorry, no volume discounts. Wholesale pricing is available to qualified, select merchants only. ************************************************************ Our other fine herbal, botanical products include the following: 1. Sweet Vjestika Aphrodisia Drops (tm); An erotic aphrodisia; sexual intensifier / enhancer liquid amalgamated extract for MEN and WOMEN. 2. "Seventh Heaven" Prosaka Tablets (tm); a botanical alternative to pharmaceutical medications for calm, balance, serenity and joyful living... 3. "Seventh Heaven" Gentle Ferocity Tablets (tm); a most efficacious, non-caffeine, non-ephedrine, non-MaHuang botanical energizer and cutting-edge appetite suppressant... 4. Extreme Martial Arts Botanical Remedies; Equivalence Tablets & Dragon Wing Remedy Spray ... pain management that works to alleviate pain even for arthritis and fibromyalgia sufferers... ********************************************* Sweet Vjestika Aphrodisia Drops (tm) inspires and enhances: * Extreme body sensitivity * Sensitivity to touch * Desire to touch and be touched * Fantasy, lust, rapture, erogenous sensitivity ... * Prolongs and intensifies foreplay, orgasm & climax ********************************************* "Seventh Heaven" Prosaka Tablets ... Entirely natural, proprietary, botanical prescription comprised of uncommon Asian Herbs for Calm, Balance, Serenity and Joyful Living. "Seventh Heaven" Prosaka is indeed a most extraordinary, viripotent, calming, centering, mood-enhancing, holistically-formulated, exotic herbaceous alternative to pharmaceutical medications for depression, anxiety, stress, insomnia, etc. NO side effects! NO dependency! Vivaciously Mellow! ********************************************** "Seventh Heaven" Gentle Ferocity Tablets (tm) ... a non-caffeine, non-ephedrine, non-ephedra, non-MaHuang; viripotent, herbaceous prescription for the dynamic energization of body, mind and spirit. This Gentle Ferocity Formulation is amalgamated in accordance with the fundamental Taoist herbal principle of botanical interactiveness and precursorship which in essence is a molecular equation of the relevant botanical/herbal alkaloids and glycosides interacting with one another to prolificate molecular communion and thereby to achieve demonstrative herbal efficaciousness without negative implication to any aspect of human composition. These Gentle Ferocity Cordial Tablets are incredulously and thoroughly effective. Enjoy! For those of you who seek to achieve most demonstrative/non-invasive/non-prohibitive appetite suppression without the negative implications of ongoing usage of MaHuang Herb, Ephedra/Ephedrine or Caffeine as are so magnaminously utilized in a multitude of herbal "diet aids" entitled as "Thermogenics" ... this is ABSOLUTELY the herbal agenda/product for you!! Entirely Natural! Increases Energy! Increases Metabolism! Decreases Appetite! *********************************************** Extreme Martial Arts Botanical Remedies Eastern culture has long had a treatment for bone, muscle, tendon, ligament, sinew and joint distress, traumas, afflictions and constrictions. We are pleased to offer Equivalence Tablets & Dragon Wing Remedy Spray (Hei Ping Shun) (Hei Long Chibang) PLEASE NOTE: While it is true that all physiological traumas and injuries are unique and that no product can arbitrarily eliminate all of the pain and discomfort in all people all of the time, the combination of Equivalence Tablets (Hei Ping Shun) and Dragon Wing Remedy (Hei Long Chibang) remedial botanicals does guarantee to at the least: 1. Significantly reduce discomfort and pain! (In many instances most, if not all, traumas and distress can be eliminated!) 2. Significantly increase mobility and strength ratio. (Please remember also the significance of proper diet, excercise, rest and prayer.) Equivalence Tablets & Dragon Wing Spray Remedials are comprised of entirely natural botanical factors. While Equivalence Tablets (Hei Ping Shun) and Dragon Wing Remedy Spray (Hei Long Chibang) are extremely effective individually, they are utilized to maximum advantage when used in conjunction with one another. ======================================================== !!!!Please refer to Introductory Offers further on in this text featuring Temple “3” Ragga Dagga (TM) along with our other “very fine” “Sensitive/Responsive” cordial botanical products…. Please enjoy!!! Many Blessings to you all…. ======================================================== PRICING INFORMATION: 1. SEVENTH HEAVEN Seventh Heaven Temple 3 (tm) One .75 oz. jigget/bar $65.00 One 2.0 oz. jigget/bar $115.00 (Free Capillaris Herba with 2.0 oz. bar. Refer to Capillaris paragraph at end of text) 2. SWEET VJESTIKA APHRODISIA DROPS (tm) One 1.0 oz. bottle $90.00 Two 1.0 oz. bottles $140.00 3. SEVENTH HEAVEN PROSAKA (tm) One 100 tablet tin $40.00 Three 100 tablet tins $105.00 Six 100 tablet tins $185.00 4. SEVENTH HEAVEN GENTLE FEROCITY (tm) One 300 tablet jar $130.00 5. Equivalence Tablets - Each bottle contains 90 - 500mg tablets. ** 3-pack (270 tablets) $83.00 ** 6-pack (540 tablets) $126.00 (save $40.00) ** 9-pack (810 tablets) $159.00 (save $90.00) ** 12-pack (1,080 tablets) $192.00 (save $140.00) 6. Dragon Wing Spray Remedy - Each spray bottle contains 4 liquid oz. ** 3-pack (3 - 4 oz. bottles) $83.00 ** 6-pack (6 - 4 oz. bottles) $126.00 (save $40.00) ** 9-pack (9 - 4 oz. bottles) $159.00 (save $90.00) ** 12-pack (12 - 4 oz. bottles) $192.00 (save $140.00) 7. Dynamic Duo Introductory Offers ** 3-pack Equivalence Tabs & 3-pack Dragon Wing $126.00 (save $40.00) ** 6-pack Equivalence Tabs & 3-pack Dragon Wing $159.00 (save $50.00) ** 9-pack Equivalence Tabs & 6-pack Dragon Wing $215.00 (save $70.00) ** 12-pack Equivalence Tabs & 9-pack Dragon Wing $271.00 (save $80.00) 8. SWEET APHRODISIA INTRO COMBINATION OFFER Includes one, 2.0 oz. jigget/bar of Seventh Heaven Temple 3 & one, 1 oz. bottle of Sweet Vjestika Aphrodisia Drops. For $150.00 (Reg. $205.00 Save $55) (Free Capillaris Herba with this intro offer. Refer to Capillaris paragraph at end of text) 9. BODY, MIND, SPIRIT "HEAVENLY" INTRO COMBINATION OFFER Includes one, 2.0 oz. jigget/bar of Seventh Heaven Temple 3 & 1 tin (100 tablets) of Seventh Heaven Prosaka. For $125.00 (Reg. $155.00 Save $30) (Free Capillaris Herba with this intro offer. Refer to Capillaris paragraph at end of text) 10. "PURE ENERGY" INTRO COMBINATION OFFER Includes one, 2.0 oz. jigget/bar of Seventh Heaven Temple 3 & 1 jar (300 tablets) of Seventh Heaven Gentle Ferocity. For $170.00 (Reg. $245.00 Save $75) (Free Capillaris Herba with this intro offer Refer to Capillaris paragraph at end of text) 11. "SENSITIVE" PREFERENTIAL INTRO COMBINATION OFFER Includes one, 2.0 oz. jigget/bar of Seventh Heaven Temple 3 & 1 tin (100 tablets) of Seventh Heaven Prosaka & 1 jar (300 tablets) of Seventh Heaven Gentle Ferocity For $200.00 (Reg. $285.00 Save $85) (Free Capillaris Herba with this intro offer Refer to Capillaris paragraph at end of text.) 12. ULTIMATE HERBACEOUSNESS INTRO COMBINATION OFFER Includes one - 2.0 oz. jigget / bar of Seventh Heaven Temple 3, one - 1 oz. bottle of Sweet Vjestika Aphrodisia Drops, one - 100 tablet tin of Prosaka, and one - 300 count jar of Gentle Ferocity for a deep discounted Retail Price of $260.00 (Reg. $375.00 Save $115) (Free Capillaris Herba with this intro offer Refer to Capillaris paragraph at end of text.) SPECIAL OFFER: For a limited time only, you will receive a FREE personal brass hookah with the Ultimate Herbaceous Intro Offer as our gift to you. This hookah has a retail value of $25.00. ************************************************** ORDERING INFORMATION: For your convenience, you can call us direct with your orders or questions. Call 1-623-974-2295 7 Days a Week -- 10:30 AM to 7:00 PM (Mountain Time) For all domestic orders, add $6.00 shipping & handling (shipped U.S. Priority Mail). Add $20.00 for International orders. ************************************************** SPECIAL DISCOUNT & GIFT Call now and receive a FREE botanical gift! With every order for a 2.0 oz. jigget / bar of Seventh Heaven Temple 3 or one of our four (4) Intro Combination Offers, we will include as our free gift to you ... a 2.0 oz. package of our ever so sedate, sensitive Asian import, loose-leaf Capillaris Herba for "happy" smoking or brewing ... (a $65.00 retail value). ==================================================== To remove your address from our list, click "Reply" in your email software and type "Remove" in the subject field, then send. From koontz at ariolimax.com Thu Aug 1 22:33:20 2002 From: koontz at ariolimax.com (David G. Koontz) Date: Thu, 01 Aug 2002 22:33:20 -0700 Subject: Challenge to David Wagner on TCPA References: Message-ID: <3D4A19A0.1040507@ariolimax.com> Jon Callas wrote: > On 8/1/02 1:14 PM, "Trei, Peter" wrote: > > >>So my question is: What is your reason for shielding your identity? >>You do so at the cost of people assuming the worst about your >>motives. > > > Is this a tacit way to suggest that the only people who need anonymity or > pseudonymity are those with something to hide? > . Anonymity is generally considered a a requirement for the political process in the United States to protect the right to express political speech without regard to being harrassed by those in power. There have been several federal court decisions in the last few years that have struck down laws limiting anonymity for political speech. One that comes to mind was a requirement in Chicago, I think that required the authors name on political phamplets. Would a law requiring such technical measures for controlling access to copyrighted information as proposed by representatives of Disney, et. al. in the U.S. Congress recently that incidentally by design prevented anonymity be found to be unconstitutionally limiting freedom of political speech on the internet by its chilling effect? From sfurlong at acmenet.net Thu Aug 1 19:48:07 2002 From: sfurlong at acmenet.net (Steve Furlong) Date: Thu, 1 Aug 2002 22:48:07 -0400 Subject: Freedom of association denied in Ventura Cty In-Reply-To: <3D499014.EADB14F5@cdc.gov> References: <3D499014.EADB14F5@cdc.gov> Message-ID: <200208012248.07084.sfurlong@acmenet.net> On Thursday 01 August 2002 15:46, Major Variola (ret) wrote: > Dress Code Keeps 9 Hells Angels Out of Fair in Ventura > Security: The new policy is enforced after biker club members refuse > to remove vests marked with group's insignia. Their leader says he > will sue. Is it just me, or does "I'll see you in court" lack the impact of "I'll make your bitch squeal"? -- Steve Furlong Computer Condottiere Have GNU, Will Travel Vote Idiotarian --- it's easier than thinking From daw at mozart.cs.berkeley.edu Thu Aug 1 17:36:43 2002 From: daw at mozart.cs.berkeley.edu (David Wagner) Date: 2 Aug 2002 00:36:43 GMT Subject: Challenge to David Wagner on TCPA References: <3D4946C7.7343.1660D69@localhost> Message-ID: James A. Donald wrote: >According to Microsoft, the end user can turn the palladium >hardware off, and the computer will still boot. As long as that >is true, it is an end user option and no one can object. Your point is taken. That said, even if you could turn off TCPA & Palladium and run some outdated version of Windows, whether users would object is not entirely obvious. For instance, suppose that, thanks to TCPA/Palladium, Microsoft could design Office 2005 so that it is impossible for StarOffice and other clones to read files created in Office 2005. Would some users object? I don't know. For many users, being unable to read documents created in a recent version of Office is simply not an option. However, in any case we should consider in advance the possible implications of this technology. From ray at unipay.nl Thu Aug 1 16:08:47 2002 From: ray at unipay.nl (R. Hirschfeld) Date: Fri, 2 Aug 2002 01:08:47 +0200 Subject: Challenge to David Wagner on TCPA In-Reply-To: <3D46FC4C.1146.2D7F8BE@localhost> (jamesd@echeque.com) References: <3D46FC4C.1146.2D7F8BE@localhost> Message-ID: <200208012308.BAA00912@home.unipay.nl> > From: "James A. Donald" > Date: Tue, 30 Jul 2002 20:51:24 -0700 > On 29 Jul 2002 at 15:35, AARG! Anonymous wrote: > > both Palladium and TCPA deny that they are designed to restrict > > what applications you run. The TPM FAQ at > > http://www.trustedcomputing.org/docs/TPM_QA_071802.pdf reads > > .... > > They deny that intent, but physically they have that capability. To make their denial credible, they could give the owner access to the private key of the TPM/SCP. But somehow I don't think that jibes with their agenda. If I buy a lock I expect that by demonstrating ownership I can get a replacement key or have a locksmith legally open it. From Kevin.Wall at qwest.com Thu Aug 1 22:10:15 2002 From: Kevin.Wall at qwest.com (Wall, Kevin) Date: Fri, 2 Aug 2002 01:10:15 -0400 Subject: Challenge to David Wagner on TCPA Message-ID: <9956F8424795D411B03B0008C786E60D09EA42FF@dubntex005.qwest.net> First off, let me say that in general, I am against almost everything that the DCMA stands for and am no fan of DRM either. But I do think that we will lose credibility if we can't substantiate our claims, and part of that means recognizing and acknowledging what appears to be legitimate claims from the TCPA side. Having said that, let me plunge right in and proceed to mark a complete fool of myself. Besides, so what if another hundred spambots harvest my e-mail address for breast enlargement ads (stupid spambots--think they could at least use my name to determine my sex and send me the herbal Viagra ads instead. ;-) Note that I'm interpreting Jay's reiterated question of "Claimed advantage to me here?" in the more general sense of advantage to anyone rather than to Jay personally. Not knowing him, the latter would be a rather difficult assessment to make. So, on with it already. Open mouth, insert foot... (yumm.. filet of sole)... Jay Sulzberger writes... > On Thu, 1 Aug 2002, AARG!Anonymous wrote: > > > Eric Murray writes: > > > TCPA (when it isn't turned off) WILL restrict the software that you > > > can run. Software that has an invalid or missing signature won't be > > > able to access "sensitive data"[1]. Meaning that unapproved software > > > won't work. > > > > > > [1] TCPAmain_20v1_1a.pdf, section 2.2 > > > > We need to look at the text of this in more detail. This is from > > version 1.1b of the spec: > > > > : This section introduces the architectural aspects of a Trusted > > : Platform that enable the collection and reporting of integrity > > : metrics. > > : > > : Among other things, a Trusted Platform enables an entity to > > : determine the state of the software environment in that platform > > : and to SEAL data to a particular software environment in that > > : platform. > > > Claimed advantage to me here? If you produce copyrighted materials that you don't want others to illegal copy, it can protect your assets. Might also be useful in protecting state secrets, but general crypto is sufficient for that. (Don't need it at the hardware level unless you are worried that some TLA gov't agency is out to get you.) The advantage depends on one whether is a producer of goods, or merely a consumer. I shall not make a judgement call as to which is more important. Suffice it to say that both need each other. [more from TCPA spec] > > : > > : The entity deduces whether the state of the computing environment in > > : that platform is acceptable and performs some transaction with that > > : platform. If that transaction involves sensitive data that must be > > : stored on the platform, the entity can ensure that that data is held > > : in a confidential format unless the state of the computing environment > > : in that platform is acceptable to the entity. > > Claimed advantage to me here? One could use this to detect virus infected systems, systems infected with root kits, etc., could they not? Also, ones alluded to above come to mind. > > : > > : To enable this, a Trusted Platform provides information to enable > > : the entity to deduce the software environment in a Trusted Platform. > > : That information is reliably measured and reported to the entity. > > : At the same time, a Trusted Platform provides a means to encrypt > > : cryptographic keys and to state the software environment that must > > : be in place before the keys can be decrypted. > > > > What this means is that a remote system can query the local TPM and > > find out what software has been loaded, in order to decide whether to > > send it some data. It's not that unapproved software "won't work", > > it's that the remote guy can decide whether to trust it. > > Claimed advantage to me here? Well, here's one place that I can see a potential value to consumers. I've thought a lot about how one can secure peer-to-peer (P2P) systems. Sure, if I want to allow my box be a P2P host, I can use a sandboxing technique to control and restrict (at least in theory) what rights I give other programs to run. [I'm think of a sense similar to the Java sandbox used for running applets.] However, the more interesting, and I believe more challenging piece is what guarentees can you give *ME* as a user of P2P services if I design some important code that I wish to utilize some generic P2P service. Unless I want to pay specific services for a P2P or grid computing from some company that I might happen to trust, be it IBM, HP, or whomever, I'll probably use some (future?) P2P services that are open sourced freeware that typical home users might host out of the generosity of their hearts (whereby they allow others to use some of their spare cycles). While this is all well and good, my level of trust would likely not be at the same level it would be if I paid a company to use their services. The feeling being if I buy a service from a reputable company and they intentionally do something malicious such as steal private data, etc. I can haul their butts to court. No such luck when dealing with the faceless masses. Bottom line seems to be that you get what you pay for. In particular, I'd be afraid that a few rogues might intentionally try to screw up my calculations giving me bad results or run a debugger and examine my data while it is unencrypted for some short part of the calculation, etc. How do I prevent that? Well, I don't think that it can necessarilly be PREVENTED, but all I really need to do is detect it...preferably before hand. Thus it would seem that giving the ability of a remote system to query a particular system's local TPM to see whether it is "trustworthy" (by whatever criteria that *I* decide) is just what the doctor ordered in this case. Or am I missing something here? Without this, I don't see how I would ever trust all the faceless masses P2P network for anything remotely critical or sensitive to me. > > Also, as stated earlier, data can be sealed such that it can only be > > unsealed when the same environment is booted. This is the part above > > about encrypting cryptographic keys and making sure the right software > > environment is in place when they are decrypted. > > Claimed advantage to me here? > Your turn. My little fingers are getting weary. Someone else take it from here. > > > Ok, technically it will run but can't access the data, > > > but that it a very fine hair to split, and depending on the nature > > > of the data that it can't access, it may not be able to run in truth. > > > > > > If TCPA allows all software to run, it defeats its purpose. > > > Therefore Wagner's statement is logically correct. > > > > But no, the TCPA does allow all software to run. Just because a > remote > > system can decide whether to send it some data doesn't mean that > software > > can't run. And just because some data may be inaccessible because it > > was sealed when another OS was booted, also doesnt mean that software > > can't run. > > Claimed advantage to me here? > I think that we had better define our terms here. What does it mean for a program to "run". I think most of us would hold that we mean that it executes in a way that provides the normal and generally expected functionality. Which would mean that if I put in my own copy of a audio CD that I burned for a backout copy, it should play the audio CD without any loss of quality rather than telling me that I have a pirated copy and that it's going to report me to MPAA or RIAA. However, I'm not going into any advantages or disadvantages. For the most part, I agree with Ross and David not because what they state necessarily is the intent of the TCPA or Palladium today, but because I believe that in general both humans and therefore human corporations are in essence greedy and seedy (not necessarily in that order). Of course, I have to add that I speak for myself (most of the time; sometimes my lips just move but some other voices come out ;) rather than for my company. Etc. -kevin wall From Kevin.Wall at qwest.com Thu Aug 1 22:27:19 2002 From: Kevin.Wall at qwest.com (Wall, Kevin) Date: Fri, 2 Aug 2002 01:27:19 -0400 Subject: Challenge to David Wagner on TCPA Message-ID: <9956F8424795D411B03B0008C786E60D09EA4300@dubntex005.qwest.net> Mr AARG! writes... > Eric Murray writes: > > Yes, the spec says that it can be turned off. At that point you > > can run anything that doesn't need any of the protected data or > > other TCPA services. But, why would a software vendor that wants > > the protection that TCPA provides allow his software to run > > without TCPA as well, abandoning those protections? > > That's true; in fact if you ran it earlier under TCPA and sealed some > data, you will have to run under TCPA to unseal it later. The question > is whether the advantages of running under TCPA (potentially greater > security) outweigh the disadvantages (greater potential for loss of > data, less flexibility, etc.). and in another reply to Peter Trei, Mr. AARG! also writes... > Now, there is an optional function which does use the manufacturer's key, > but it is intended only to be used rarely. That is for when you need to > transfer your sealed data from one machine to another (either because you > have bought a new machine, or because your old one crashed). In this > case you go through a complicated procedure that includes encrypting > some data to the TPME key (the TPM manufacturer's key) and sending it > to the manufacturer, who massages the data such that it can be loaded > into the new machine's TPM chip. > > So this function does require pre-loading a manufacturer key into the > TPM, but first, it is optional, and second, it frankly appears to be so > cumbersome that it is questionable whether manufacturers will want to > get involved with it. OTOH it is apparently the only way to recover > if your system crashes. This may indicate that TCPA is not feasible, > because there is too much risk of losing locked data on a machine crash, > and the recovery procedure is too cumbersome. That would be a valid > basis on which to criticize TCPA, but it doesn't change the fact that > many of the other claims which have been made about it are not correct. Correct me if I'm wrong (I'm sure you all will :), but wouldn't you also have to possibly go through this exercise with the TPME key and sending your system to the manufacturer when you wanted to, say, upgrade your operating system or switch to a completely different OS? That will go over like a lead balloon. (Gee... must be getting late. I almost wrote "like a bag of dirt". Duh! Can't even remember cliches at my age.) -kevin wall P.S.- Please excuse the sh*t formating. We use Lookout! and MS Exstrange where I work. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From adam at cypherspace.org Thu Aug 1 18:28:17 2002 From: adam at cypherspace.org (Adam Back) Date: Fri, 2 Aug 2002 02:28:17 +0100 Subject: document popularity estimation / amortizable hashcash (Re: Hollywood Hackers) In-Reply-To: <20020731213435.A346258@exeter.ac.uk>; from adam@cypherspace.org on Wed, Jul 31, 2002 at 09:34:35PM +0100 References: <8d94fd13ad3927e1ffe95293727b1cc6@ecn.org> <20020731213435.A346258@exeter.ac.uk> Message-ID: <20020802022817.A474159@exeter.ac.uk> This paper is quite interesting and proposes another method of metering content [1]: http://citeseer.nj.nec.com/naor98secure.html It's proposed in the context of web site traffic metering to determine site traffic rates (for advertising payment or other applications). It relies on a trusted auditor, which could become a central failure point so is perhaps less attractive for file sharing, but perhaps that could be fixed. Another problem is that it presumes a communication pattern where the auditor sends a secret to each user, the user makes a cheap computation involving the secret to send with each request, and then the respective server collects all of the requests it gets and does some computation to arrive at a compact proof that it received some number k of requests. (The server also receives a secret, but this is not problematic, it it anyway wants to participate). On the plus side their approach is not probabilistic -- it gives an accurate measurement of traffic, it is also not vulnerable to server traffic inflation, and is somewhat resistant to multiple client and server collusion. (Though of course any scheme is generically vulnerable to server traffic inflation -- servers can _act_ as multiple clients and simply generate the claimed traffic themselves, or contract other parties to do this for them.) Adam [1] @article{Naor:98:secure-and-efficient-metering author = "Moni Naor and Benny Pinkas", title = "Secure and Efficient Metering", journal = "Lecture Notes in Computer Science", volume = "1403", pages = "576--??", year = "1998", note = "Also available as \url{http://citeseer.nj.nec.com/naor98secure.html}" } On Wed, Jul 31, 2002 at 09:34:35PM +0100, Adam Back wrote: > I proposed a construct which could be used for this application: > called "amortizable hashcash". > > http://www.cypherspace.org/hashcash/amortizable.pdf > > The application I had in mind was also file sharing. (This was > sometime in Mar 2000). I described this problem as the "disitrbuted > document popularity estimation" problem. The other aspect of the > problem is you have to distribute the popularity estimate and make it > accessible, so I think you want it to be workably compact (you don't > want to ship around 1 million hash collisions on the document hash). > Amortizable hashcash addresses this problem. > > There is also some discussion of it here: > > http://archives.neohapsis.com/archives/crypto/2000-q1/0440.html > > Adam > > On Wed, Jul 31, 2002 at 04:25:30PM +0200, Eugen Leitl wrote: > > It should use scarce resources (e.g. crunch) to generate a trust > > currency in each node, a kind of decentralized mint (nothing > > crunches quite a few million boxes on the Net). From decoy at iki.fi Thu Aug 1 17:31:12 2002 From: decoy at iki.fi (Sampo Syreeni) Date: Fri, 2 Aug 2002 03:31:12 +0300 (EEST) Subject: Challenge to David Wagner on TCPA In-Reply-To: <15848a6fde52312200b0ab232c1ff953@aarg.net> Message-ID: On 2002-08-01, AARG!Anonymous uttered to ptrei at rsasecurity.com,...: >It does this by taking hashes of the software before transferring >control to it, and storing those hashes in its internal secure >registers. So, is there some sort of guarantee that the transfer of control won't be stopped by a check against cryptographic signature within the executable itself, in the future? That sort of thing would be trivial to enforce via licencing terms, after all, and would allow for the introduction of a strictly limited set of operating systems to which control would be transferred. I'm having a lot of trouble seeing the benefit in TCPA without such extra measures, given that open source software would likely evolve which circumvented any protection offered by the more open ended architecture you now describe. Such a development would simply mean that Peter's concern would be transferred a level up, without losing its relevance. I'd also contend that this extra level of diversion is precisely what TCPA, with its purported policy of "no trusted keys" aims at. >Then, when the data is decrypted and "unsealed", the hash is compared to >that which is in the TPM registers now. This can make it so that data >which is encrypted when software system X boots can only be decrypted >when that same software boots. Again, such values would be RE'd and reported by any sane open source OS to the circuitry, giving access to whatever data there is. If this is prevented, one can bootstrap an absolutely secure platform where whatever the content provider says is the Law, including a one where every piece of runnable OS software actually enforces the kind of control over permissible signatures Peter is so worried about. Where's the guarantee that this won't happen, one day? >In answer to your question, then, for most purposes, there is no signing >key that your TPM chip trusts, so the issue is moot. At the hardware level, yes. At the software one, it probably won't be, even in the presence of the above considerations. After you install your next Windows version, you will be tightly locked in with whatever M$ throws at you in their DLL's, and as I pointed out, there's absolutely no guarantee Linux et al. might well be shut out by extra features, in the future. In the end what we get is an architecture, which may not embody Peter's concerns right now, but which is built from the ground up to bring them into being, later. More generally, as long as we have computers which allow data to be addressed as code and vice versa, the ability to control use of data will necessarily entail ability to control use of code. So, either we will get systems where circumventing copyright controls is trivial or ones where you cannot compile your own code. All the rest is just meaningless syntax. In that light I bet you can guess why people are worried about TCPA and its ilk. -- Sampo Syreeni, aka decoy - mailto:decoy at iki.fi, tel:+358-50-5756111 student/math+cs/helsinki university, http://www.iki.fi/~decoy/front openpgp: 050985C2/025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2 --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From marhkiru564 at cln.it Fri Aug 2 16:41:06 2002 From: marhkiru564 at cln.it (Johnny Ruth) Date: Fri, 02 Aug 2002 04:41:06 -1900 Subject: Need To Know if you Got It 29994 Message-ID: <0000274063f9$00004636$00005d2c@damrak.amsterdam.dataweb.net> A non-text attachment was scrubbed... Name: not available Type: text/html Size: 8828 bytes Desc: not available URL: From al at qaeda.org Fri Aug 2 08:06:35 2002 From: al at qaeda.org (Optimizzin Al-gorithym) Date: Fri, 02 Aug 2002 08:06:35 -0700 Subject: modified consoles as disposable nodes Message-ID: <3D4A9FFA.9ED78B88@qaeda.org> At 12:19 PM 8/2/02 +0200, Eugen Leitl wrote: >While useful, they note that the other platforms lack at least one of the >Dreamcast's virtues. "It's innocuous. It looks like a toy," said Davis. >"If you bring it into a company, they're going to go, 'Wow, look at the >toy!'" Damn, first they came for my Furby. Then they came for my Dreamcast. Wait until the Dreamcasters get into stealth casemods.. From jamesd at echeque.com Fri Aug 2 08:26:35 2002 From: jamesd at echeque.com (James A. Donald) Date: Fri, 2 Aug 2002 08:26:35 -0700 Subject: Challenge to David Wagner on TCPA In-Reply-To: Message-ID: <3D4A423B.11842.53C4850@localhost> -- On 2 Aug 2002 at 0:36, David Wagner wrote: > For instance, suppose that, thanks to TCPA/Palladium, Microsoft > could design Office 2005 so that it is impossible for StarOffice > and other clones to read files created in Office 2005. Would > some users object? In an anarchic society, or under a government that did not define and defend IP, TCPA/Palladium would probably give roughly the right amount of protection to intellectual property by technical means in place of legal means. Chances are that the thinking behind Palladium is not "Let us sell out to the Hollywood lobby" but rather "Let us make those !@#$$%^& commie chinese pay for their *&^%$##@ software". Of course, in a society with both legal and technical protection of IP, the likely outcome is oppressive artificial monopolies sustained both by technology and state power. I would certainly much prefer TCPA/Palladium in place of existing IP law. What I fear is that instead legislation and technology will each reinforce the other. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG R66NXPp5xZNDYn98jcVqH5q22ikRRFR3evv5xfwF 2PNka92tYm9+/iBKaR+IcOoDA8BwXZlwcPD18Ogw8 From lennd at marketingresearchinternational.com Fri Aug 2 08:37:56 2002 From: lennd at marketingresearchinternational.com (lennd at marketingresearchinternational.com) Date: Fri, 2 Aug 2002 08:37:56 -0700 Subject: ADV: CAN'T WIN WITH HANDS TIED! Message-ID: <200208021536.g72FaSOX022687@ak47.algebra.com> A non-text attachment was scrubbed... Name: not available Type: text/html Size: 3101 bytes Desc: not available URL: From rah at shipwright.com Fri Aug 2 06:56:27 2002 From: rah at shipwright.com (R. A. Hettinga) Date: Fri, 2 Aug 2002 09:56:27 -0400 Subject: ZKS Pulls IPO Message-ID: http://www.forbes.com/newswire/2002/08/02/rtr684925.html Internet security firm pulls planned IPO Reuters, 08.02.02, 8:52 AM ET MONTREAL, August 2 (Reuters) - Zero-Knowledge Systems Inc. pulled the plug on Friday on a planned initial public offering, saying it will instead use a recently completed private financing to fund growth for its Internet security software business. Privately held Zero-Knowledge, a high-flyer during the technology boom that attracted heavy media and industry attention, did not disclose the value of the financing. "With the downturn in public market conditions since we began the process of a public offering 10 weeks ago, our investors, management and board of directors no longer felt that raising money in the public markets was the best option," said Chief Executive Tamas Hevizi in a statement. The Montreal-based company said it has signed several important sales in the past six months, including Hewlett-Packard Co. (nyse: HPQ - news - people), Telus Corp. and France Telecom . -- ----------------- R. A. Hettinga The Internet Bearer Underwriting Corporation 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire' --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From jamesd at echeque.com Fri Aug 2 10:37:16 2002 From: jamesd at echeque.com (James A. Donald) Date: Fri, 2 Aug 2002 10:37:16 -0700 Subject: Challenge to David Wagner on TCPA In-Reply-To: Message-ID: <3D4A60DC.23973.5B3EE2D@localhost> -- On 2 Aug 2002 at 10:43, Trei, Peter wrote: > Since the position argued involves nothing which would invoke > the malign interest of government powers or corporate legal > departments, it's not that. I can only think of two reasons why > our corrospondent may have decided to go undercover... I can think of two innocuous reasons, though the real reason is probably something else altogether: 1. Defending copyright enforcement is extremely unpopular because it seemingly puts you on the side of the hollywood cabal, but in fact TCPA/Paladium, if it works as described, and if it is not integrated with legal enforcement, does not over reach in the fashion that most recent intellectual property legislation, and most recent policy decisions by the patent office over reach. 2.. Legal departments are full of people who are, among their many other grievious faults, technologically illiterate. Therefore when an insider is talking about something, they cannot tell when he is leaking inside information or not, and tend to have kittens, because they have to trust him (being unable to tell if he is leaking information covered by NDA), and are constitutionally incapable of trusting anyone. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG Alf9R2ZVGqWkLhwWX2H6TBqHOunrj2Fbxy+U0ORV 2uPGI4gMDt1fTQkV1820PO3xWmAWPiaS0DqrbmobN --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From ptrei at rsasecurity.com Fri Aug 2 07:43:21 2002 From: ptrei at rsasecurity.com (Trei, Peter) Date: Fri, 2 Aug 2002 10:43:21 -0400 Subject: Challenge to David Wagner on TCPA Message-ID: > Jon Callas[SMTP:jon at callas.org] > > > On 8/1/02 1:14 PM, "Trei, Peter" wrote: > > > So my question is: What is your reason for shielding your identity? > > You do so at the cost of people assuming the worst about your > > motives. > > Is this a tacit way to suggest that the only people who need anonymity or > pseudonymity are those with something to hide? > > Jon > Not really. However, in todays actual environment, this is frequently true that those with something to hide use anonymity. While some people have maintained nyms for many years (I can't think of anyone maintaining explicit stong anonymity right now, actually - remember Sue D. Nym? ), and used them to talk about a variety of issues, it's pretty rare. It's rare enough that when a new anononym appears, we know that the poster made a considered decision to be anonymous. The current poster seems to have parachuted in from nowhere, to argue a specific position on a single topic. It's therefore reasonable to infer that the nature of that position and topic has some bearing on the decision to be anonymous. Since the position argued involves nothing which would invoke the malign interest of government powers or corporate legal departments, it's not that. I can only think of two reasons why our corrospondent may have decided to go undercover... 1. If we know who he/she/them were, it would weaken the argument (for example, by making it clear that the poster has a vested interest in the position maintained, or that 'AARGH! is the group effort of an astroturf campaign). 2. If the true identity of the poster became known, he/she/them fears some kind of retribution: * The ostracism and detestation of his peers. * The boycotting of his employer. * His employer objecting to his wasting company time on Internet mailing lists. Our corrospondent has not given us any reason not to infer the worst motives. This is, after all, a discipline where paranoia and suspicion are job requirements. Peter Trei Disclaimer: The above represents my private , personal opinions only; do not misconstrue them to represent the opinions of others. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From eresrch at eskimo.com Fri Aug 2 10:49:07 2002 From: eresrch at eskimo.com (Mike Rosing) Date: Fri, 2 Aug 2002 10:49:07 -0700 (PDT) Subject: Challenge to David Wagner on TCPA In-Reply-To: Message-ID: On Fri, 2 Aug 2002, Jay Sulzberger wrote: > To deal with the tiny bit of truth in the claims of AARG! that some > capabilities of DRM might be beneficial to me: Yes, of coures, there are > few things that have zero benefits. But this is hardly relevant. A more > relevant question here is: Can we get the benefits in a better way? And of > course, we can. For the purposes of this narrow and hypothetical > discussion, DRM might just be considered as a dongle forced on every home > computer in the world. The claims of benefit depend on this dongle being > usable by me to make sure that you do not do certain things with my > program/data when it is running on your computer, e.g., distribute the > movie I send you. Well, why must the dongle be on the whole computer > system? Why cannot it be simply a dongle that goes in a slot in a special > TV screen/speaker system? Now this is a "product"!, why we'll sell 'em the > screens and we'll sell the dongle separately, etc.. Of course, the > Englobulators have no interest in making and selling such dongles. Indeed, > were Phillips to start making and selling such, somehow a legal cause of > action against Phillips would be discovered and the suits would commence. I think this is what it boils down to. If I want a dongle for an arbitrary suite of products I should be able to go to some store and buy it. There's no reason it has to be built into the motherboard. the Microsoft X-box can have a built in dongle chip, it's purpose is to ensure that only MS certified games run on the box. I don't see any problem with that. And I don't see any problem with Hollywood (or Bollywood either) selling HDTV's with their own dongles. As an argument to congress we need to stress that TCP's are fine as isolated devices for specific purposes. There is *NO NEED* to make general purpose computers TCP's. Where there is a market for TCP's, I'd expect companies to want the ability to put their own keys into the dongle, not some outside manufacturer who they might not trust. TCP's and DRM is useful to some people, and those people should be able to buy it. But there's really no need to force it on everyone, and that's the point we need to get congress to understand. Patience, persistence, truth, Dr. mike From jays at panix.com Fri Aug 2 08:25:56 2002 From: jays at panix.com (Jay Sulzberger) Date: Fri, 2 Aug 2002 11:25:56 -0400 (EDT) Subject: Challenge to David Wagner on TCPA In-Reply-To: <9956F8424795D411B03B0008C786E60D09EA42FF@dubntex005.qwest. net> Message-ID: On Fri, 2 Aug 2002, Wall, Kevin wrote: > First off, let me say that in general, I am against almost everything > that the DCMA stands for and am no fan of DRM either. But I do think that > we will lose credibility if we can't substantiate our claims, and part of > that means recognizing and acknowledging what appears to be legitimate > claims from the TCPA side. Please forgive me for being too short in my indication of what a better longer response from me would look like, which better longer response I hope to include in a formal submission to the Department of Commerce taskforce on DRM. There is nothing to be said in favor of DRM. DRM is simply the name for the system under which the Englobulators would have root on every home and small business computer on Earth. ad propaganda: If we admit the principle that it is reasonable to outlaw the sale of computers to individuals and to outlaw the private use of computers, we place ourselves in a false posture, and a strategically weaker position. The present situation is not that of twenty-five years ago when the VCR was coming to be used in private homes. The struggles of those days were about trammels on limited purpose devices. DRM is not one trammel on a limited device, nor is it even a set of trammels on several differtent special purpose devices. In the above paragraph I use the word "computer" to mean computers of the sort we have today, that is, computers which have no wiretaps and no remote control machinery in them. ad my repeated rhetorical question "Claimed advantage to me here?": It was an error of rhetoric to put these questions in my response to AAARG!. These questions require consideration of indirect effects, which may only be roughly estimated, if we wish to be precise at the two nines level. But in each case, when one runs down the game/rhetoric tree, one sees that there is never any benefit to me in the claimed useful-to-all capabilities of DRM. I will not be able to force my wiretaps and my remote controls on RIAA-MPAA-AAP. As pointed out, section 4.12 of the Final Report of the BPDG, simply specifies that, when DRM is forced on the world, Englobulator machines will have no TCPA/Palladium/wiretaps/remote-controls in them. To deal with the tiny bit of truth in the claims of AARG! that some capabilities of DRM might be beneficial to me: Yes, of coures, there are few things that have zero benefits. But this is hardly relevant. A more relevant question here is: Can we get the benefits in a better way? And of course, we can. For the purposes of this narrow and hypothetical discussion, DRM might just be considered as a dongle forced on every home computer in the world. The claims of benefit depend on this dongle being usable by me to make sure that you do not do certain things with my program/data when it is running on your computer, e.g., distribute the movie I send you. Well, why must the dongle be on the whole computer system? Why cannot it be simply a dongle that goes in a slot in a special TV screen/speaker system? Now this is a "product"!, why we'll sell 'em the screens and we'll sell the dongle separately, etc.. Of course, the Englobulators have no interest in making and selling such dongles. Indeed, were Phillips to start making and selling such, somehow a legal cause of action against Phillips would be discovered and the suits would commence. oo--JS. > > Having said that, let me plunge right in and proceed to mark a complete > fool of myself. Besides, so what if another hundred spambots harvest > my e-mail address for breast enlargement ads (stupid spambots--think > they could at least use my name to determine my sex and send me the > herbal Viagra ads instead. ;-) > > Note that I'm interpreting Jay's reiterated question of > "Claimed advantage to me here?" in the more general sense of > advantage to anyone rather than to Jay personally. Not knowing > him, the latter would be a rather difficult assessment to make. > > So, on with it already. Open mouth, insert foot... (yumm.. > filet of sole)... > > Jay Sulzberger writes... > > > On Thu, 1 Aug 2002, AARG!Anonymous wrote: > > > > > Eric Murray writes: > > > > TCPA (when it isn't turned off) WILL restrict the software that you > > > > can run. Software that has an invalid or missing signature won't be > > > > able to access "sensitive data"[1]. Meaning that unapproved software > > > > won't work. > > > > > > > > [1] TCPAmain_20v1_1a.pdf, section 2.2 > > > > > > We need to look at the text of this in more detail. This is from > > > version 1.1b of the spec: > > > > > > : This section introduces the architectural aspects of a Trusted > > > : Platform that enable the collection and reporting of integrity > > > : metrics. > > > : > > > : Among other things, a Trusted Platform enables an entity to > > > : determine the state of the software environment in that platform > > > : and to SEAL data to a particular software environment in that > > > : platform. > > > > > > Claimed advantage to me here? > > If you produce copyrighted materials that you don't want others to > illegal copy, it can protect your assets. Might also be useful in > protecting state secrets, but general crypto is sufficient for > that. (Don't need it at the hardware level unless you are worried > that some TLA gov't agency is out to get you.) > > The advantage depends on one whether is a producer of goods, or merely > a consumer. I shall not make a judgement call as to which is more > important. Suffice it to say that both need each other. > > [more from TCPA spec] > > > : > > > : The entity deduces whether the state of the computing environment in > > > : that platform is acceptable and performs some transaction with that > > > : platform. If that transaction involves sensitive data that must be > > > : stored on the platform, the entity can ensure that that data is held > > > : in a confidential format unless the state of the computing environment > > > : in that platform is acceptable to the entity. > > > > Claimed advantage to me here? > > One could use this to detect virus infected systems, systems infected > with root kits, etc., could they not? Also, ones alluded to above > come to mind. > > > > : > > > : To enable this, a Trusted Platform provides information to enable > > > : the entity to deduce the software environment in a Trusted Platform. > > > : That information is reliably measured and reported to the entity. > > > : At the same time, a Trusted Platform provides a means to encrypt > > > : cryptographic keys and to state the software environment that must > > > : be in place before the keys can be decrypted. > > > > > > What this means is that a remote system can query the local TPM and > > > find out what software has been loaded, in order to decide whether to > > > send it some data. It's not that unapproved software "won't work", > > > it's that the remote guy can decide whether to trust it. > > > > Claimed advantage to me here? > > Well, here's one place that I can see a potential value to consumers. > I've thought a lot about how one can secure peer-to-peer (P2P) systems. > > Sure, if I want to allow my box be a P2P host, I can use a sandboxing > technique to control and restrict (at least in theory) what rights I > give other programs to run. [I'm think of a sense similar to the Java > sandbox used for running applets.] > > However, the more interesting, and I believe more challenging piece is > what guarentees can you give *ME* as a user of P2P services if I design > some important code that I wish to utilize some generic P2P service. > Unless I want to pay specific services for a P2P or grid computing from > some company that I might happen to trust, be it IBM, HP, or whomever, > I'll probably use some (future?) P2P services that are open sourced freeware > that typical home users might host out of the generosity of their hearts > (whereby they allow others to use some of their spare cycles). While this > is all well and good, my level of trust would likely not be at the same > level it would be if I paid a company to use their services. The feeling > being if I buy a service from a reputable company and they intentionally > do something malicious such as steal private data, etc. I can haul their > butts to court. No such luck when dealing with the faceless masses. > Bottom line seems to be that you get what you pay for. In particular, > I'd be afraid that a few rogues might intentionally try to screw up > my calculations giving me bad results or run a debugger and examine my > data while it is unencrypted for some short part of the calculation, > etc. How do I prevent that? Well, I don't think that it can necessarilly > be PREVENTED, but all I really need to do is detect it...preferably > before hand. > > Thus it would seem that giving the ability of a remote system to > query a particular system's local TPM to see whether it is "trustworthy" > (by whatever criteria that *I* decide) is just what the doctor ordered > in this case. > > Or am I missing something here? Without this, I don't see how I would > ever trust all the faceless masses P2P network for anything remotely > critical or sensitive to me. > > > > Also, as stated earlier, data can be sealed such that it can only be > > > unsealed when the same environment is booted. This is the part above > > > about encrypting cryptographic keys and making sure the right software > > > environment is in place when they are decrypted. > > > > Claimed advantage to me here? > > > > Your turn. My little fingers are getting weary. Someone else take it from > here. > > > > > Ok, technically it will run but can't access the data, > > > > but that it a very fine hair to split, and depending on the nature > > > > of the data that it can't access, it may not be able to run in truth. > > > > > > > > If TCPA allows all software to run, it defeats its purpose. > > > > Therefore Wagner's statement is logically correct. > > > > > > But no, the TCPA does allow all software to run. Just because a > > remote > > > system can decide whether to send it some data doesn't mean that > > software > > > can't run. And just because some data may be inaccessible because it > > > was sealed when another OS was booted, also doesnt mean that software > > > can't run. > > > > Claimed advantage to me here? > > > > I think that we had better define our terms here. What does it mean > for a program to "run". I think most of us would hold that we mean > that it executes in a way that provides the normal and generally > expected functionality. Which would mean that if I put in my own > copy of a audio CD that I burned for a backout copy, it should play > the audio CD without any loss of quality rather than telling me that > I have a pirated copy and that it's going to report me to MPAA or RIAA. > > However, I'm not going into any advantages or disadvantages. > For the most part, I agree with Ross and David not because what > they state necessarily is the intent of the TCPA or Palladium > today, but because I believe that in general both humans and > therefore human corporations are in essence greedy and seedy > (not necessarily in that order). > > Of course, I have to add that I speak for myself (most of the time; > sometimes my lips just move but some other voices come out ;) rather > than for my company. Etc. > > -kevin wall From rah at shipwright.com Fri Aug 2 08:43:39 2002 From: rah at shipwright.com (R. A. Hettinga) Date: Fri, 2 Aug 2002 11:43:39 -0400 Subject: ZKS Pulls IPO In-Reply-To: <5.1.1.6.0.20020802100317.01ab92f0@mail.well.com> References: <5.1.1.6.0.20020802100317.01ab92f0@mail.well.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 At 10:03 AM -0400 on 8/2/02, Somebody wrote: > Wow. > > Why am I not surprised? Yup. The rubble still bounces, though there are bits of grass poking through. I'm getting queries about stuff from perfect strangers, mostly researchers, for the first time in 7-8 months, reminiscent, for all the world, of 1994/5. It's pretty nice, if there wasn't so much, well, rubble, all around. Of course, in 1994/5 we were coming out of the rubble of a recession and crummy market. So, the public markets aren't a piggy bank for "bright" ideas anymore, certainly, if they ever should have been. Certainly not as they're currently organized, anyway. Maybe someday, when transaction costs are *much* lower. And, speaking of private equity bailouts of ostensibly public deals, I got yelled at by a fairly clueful venture cap friend this spring when I suggested that creating a low-cost efficient secondary market for private equity was getting much easier, would almost certainly happen, and sooner or later would blur the line between private and public equity. But, as Rodney Thayer always said, when someone with a clue yells at you, you're probably right. If course, what actually made the guy yell was when I suggested that that secondary market be done in unsponsored network bearer depository receipts. That would be, well, just, *wrong*, dammit. ;-). -----BEGIN PGP SIGNATURE----- Version: PGP 7.5 iQA/AwUBPUqoXsPxH8jf3ohaEQLF6wCfb0skJpM08IavistF87WkTwIdhDkAn18r XgXjcP5dF10lk4QoYH3G+2LA =kITY -----END PGP SIGNATURE----- -- ----------------- R. A. Hettinga The Internet Bearer Underwriting Corporation 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire' From eugen at leitl.org Fri Aug 2 03:19:02 2002 From: eugen at leitl.org (Eugen Leitl) Date: Fri, 2 Aug 2002 12:19:02 +0200 (CEST) Subject: modified consoles as disposable nodes Message-ID: Looks useful for P2P infrastructure. http://online.securityfocus.com/news/558 When Dreamcasts Attack White hat hackers use game consoles, handheld PCs to crack networks from the inside out. By Kevin Poulsen, Jul 31 2002 5:26PM LAS VEGAS--Cyberpunks will be toting cheap game consoles on their utility belts this fall if they follow the lead of a pair of white hat hackers who demonstrated Wednesday how to turn the defunct Sega Dreamcast into a disposable attack box designed to be dropped like a bug on corporate networks during covert black bag jobs. The "phone home" technique presented by Aaron Higbee of Foundstone and Chris Davis from RedSiren Technologies at the Black Hat Briefings here takes advantage of the fact that firewalls effective in blocking entry into a private network, are generally permissive in allowing connections the other way around. Higbee and Davis perform penetration tests, and developed their game box cum attack tool after finding themselves more than once with physical access to a client's facilities -- posing as an employee in once case, crawling through a drop ceiling in another -- but without a way to leverage that access into remote control of the company's network. "It's not that hard to get into an organization for one or two minutes," said Higbee. They chose the Dreamcast for its small size, availability of an Ethernet adapter, and affordability -- the console was discontinued last year, and now sells used for under $100 on eBay. Loaded with custom Linux-based software and covertly plugged into a spare network port under a desk or above a ceiling, the harmless-looking toy becomes the enemy within, probing the company firewall for a way out to Internet. The box cycles through the ports used for common services like SSH, Web surfing, and e-mail, which tend to be permitted by firewall configurations. Failing that, it tries getting "ping" packets out to the Internet, and finally looks for proxy servers bridging the network to the outside world. Whatever it finds, it uses to establish a tunnel through the firewall to the intruder's home machine. "Most organizations focus on the perimeter," said Davis. "Once you get through the outside, there's a soft chewy center." The pair suggested some techniques for mitigating the risk of dropped-in hardware -- restricting the LAN to pre-assigned MAC addresses, for one -- but said that ultimately, there may be little an organization can do to prevent an attacker with physical access from setting up a covert channel home. The pair plan to release their Dreamcast software on their website next month, along with similar code they developed for the handheld Compaq iPAQ, and a bootable CD ROM designed to be slipped into print servers and other kiosk PCs. While useful, they note that the other platforms lack at least one of the Dreamcast's virtues. "It's innocuous. It looks like a toy," said Davis. "If you bring it into a company, they're going to go, 'Wow, look at the toy!'" From bks10 at CORNELL.EDU Fri Aug 2 05:10:09 2002 From: bks10 at CORNELL.EDU (bks10) Date: Fri, 2 Aug 2002 14:10:09 +0200 (CEST) Subject: And disallow inbound packet destined to port Message-ID: <20020802121009.1EBD01FC7@digi.army.sk> A non-text attachment was scrubbed... Name: unnamed.html Type: text/html Size: 113 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: a.FIXED-554.htm Type: text/html Size: 605 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ms-proxy2_0-attack.txt Type: application/octet-stream Size: 1362 bytes Desc: not available URL: From mortgage4u116 at aol.com Sat Aug 3 01:13:58 2002 From: mortgage4u116 at aol.com (REBA) Date: Fri, 02 Aug 2002 14:13:58 -1800 Subject: lowest rate mortgage EVTNF Message-ID: <000069be61ba$00005dde$0000462c@mailin-02.mx.aol.com> Relating to Dare to Compare! Do you have the LOWEST Mortgage rate available? * Compare our rates. * No obligation. * Search hundreds of lenders instantly. * Free qoutes. * ALL Credit Accepted. A,B and subprime! One thing we all know, rates won't stay this low forever. Search now: http://nu01qaFFrq at mortgage-tree.com/ml.htm Unlist; http://NU1DUE8yeQ at mortgage-tree.com/ml.htm From ptrei at rsasecurity.com Fri Aug 2 11:36:32 2002 From: ptrei at rsasecurity.com (Trei, Peter) Date: Fri, 2 Aug 2002 14:36:32 -0400 Subject: Challenge to David Wagner on TCPA Message-ID: > AARG! Anonymous[SMTP:remailer at aarg.net] writes [...] > Now, there is an optional function which does use the manufacturer's key, > but it is intended only to be used rarely. That is for when you need to > transfer your sealed data from one machine to another (either because you > have bought a new machine, or because your old one crashed). In this > case you go through a complicated procedure that includes encrypting > some data to the TPME key (the TPM manufacturer's key) and sending it > to the manufacturer, who massages the data such that it can be loaded > into the new machine's TPM chip. > > So this function does require pre-loading a manufacturer key into the > TPM, but first, it is optional, and second, it frankly appears to be so > cumbersome that it is questionable whether manufacturers will want to > get involved with it. OTOH it is apparently the only way to recover > if your system crashes. This may indicate that TCPA is not feasible, > because there is too much risk of losing locked data on a machine crash, > and the recovery procedure is too cumbersome. That would be a valid > basis on which to criticize TCPA, but it doesn't change the fact that > many of the other claims which have been made about it are not correct. [...] While I reserve the right to respond to the rest of the poster's letter, I'd like to call out this snippet, which gives a very good reason for both corporate and individual users to avoid TCPA as if it were weaponized anthrax (Hi NSA!). ... OK, It's 2004, I'm an IT Admin, and I've converted my corporation over to TCPA/Palladium machines. My Head of Marketing has his TCPA/Palladium desktop's hard drive jam-packed with corporate confidential documents he's been actively working on - sales projections, product plans, pricing schemes. They're all sealed files. His machine crashes - the MB burns out. He wants to recover the data. HoM: I want to recover my data. Me: OK: We'll pull the HD, and get the data off it. HoM: Good - mount it as a secondary HD in my new system. Me: That isn't going to work now we have TCPA and Palladium. HoM: Well, what do you have to do? Me: Oh, it's simple. We encrypt the data under Intel's TPME key, and send it off to Intel. Since Intel has all the keys, they can unseal all your data to plaintext, copy it, and then re-seal it for your new system. It only costs $1/Mb. HoM: Let me get this straight - the only way to recover this data is to let Intel have a copy, AND pay them for it? Me: Um... Yes. I think MS might be involved as well, if your were using Word. HoM: You are *so* dead. --------------------------- Peter Trei --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From jays at panix.com Fri Aug 2 11:36:38 2002 From: jays at panix.com (Jay Sulzberger) Date: Fri, 2 Aug 2002 14:36:38 -0400 (EDT) Subject: Challenge to David Wagner on TCPA In-Reply-To: <3D4A60DC.23973.5B3EE2D@localhost> Message-ID: On Fri, 2 Aug 2002, James A. Donald wrote: > -- > On 2 Aug 2002 at 10:43, Trei, Peter wrote: > > Since the position argued involves nothing which would invoke > > the malign interest of government powers or corporate legal > > departments, it's not that. I can only think of two reasons why > > our corrospondent may have decided to go undercover... > > I can think of two innocuous reasons, though the real reason is > probably something else altogether: > > 1. Defending copyright enforcement is extremely unpopular because > it seemingly puts you on the side of the hollywood cabal, but in > fact TCPA/Paladium, if it works as described, and if it is not > integrated with legal enforcement, does not over reach in the > fashion that most recent intellectual property legislation, and > most recent policy decisions by the patent office over reach. a. TCPA/Palladium must be integrated with laws which give to the Englobulators absolute legal cudgel powers, such as the DMCA. So far I have not seen any proposal by the Englobulators to repeal the DMCA and cognate laws, so if TCPA/Palladium is imposed, the DMCA will be used, just as HP threatened to use it a couple of days ago. And, of course, today there is no imposed TCPA/Palladium, so the situation will be much worse when there is. b. Why must TCPA/Palladium be a dongle on the whole computer? Why not a separate dongle? Because, of course, the Englobulators proceed here on principle. The principle being that only the Englobulators have a right to own printing presses/music studios/movie and animation studios. > > 2.. Legal departments are full of people who are, among their > many other grievious faults, technologically illiterate. > Therefore when an insider is talking about something, they cannot > tell when he is leaking inside information or not, and tend to > have kittens, because they have to trust him (being unable to tell > if he is leaking information covered by NDA), and are > constitutionally incapable of trusting anyone. > > --digsig There is a business, not yet come into existence, of providing standard crypto services to law offices. oo--JS. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From jamesd at echeque.com Fri Aug 2 14:53:48 2002 From: jamesd at echeque.com (James A. Donald) Date: Fri, 2 Aug 2002 14:53:48 -0700 Subject: Challenge to David Wagner on TCPA In-Reply-To: Message-ID: <3D4A9CFC.22726.69ECD4C@localhost> -- On 2 Aug 2002 at 14:36, Trei, Peter wrote: > OK, It's 2004, I'm an IT Admin, > and I've converted my corporation over to TCPA/Palladium machines. My > Head of Marketing has his TCPA/Palladium desktop's hard drive > jam-packed with corporate confidential documents he's been actively > working on - sales projections, product plans, pricing schemes. > They're all sealed files. > > His machine crashes - the MB burns out. > He wants to recover the data. > > HoM: I want to recover my data. > Me: OK: We'll pull the HD, and get the data off it. > HoM: Good - mount it as a secondary HD in my new system. > Me: That isn't going to work now we have TCPA and Palladium. > HoM: Well, what do you have to do? > Me: Oh, it's simple. We encrypt the data under Intel's TPME key, > and send it off to Intel. Since Intel has all the keys, they can > unseal all your data to plaintext, copy it, and then re-seal it for > your new system. It only costs $1/Mb. > HoM: Let me get this straight - the only way to recover this data is > to let > Intel have a copy, AND pay them for it? > Me: Um... Yes. I think MS might be involved as well, if your were > using > Word. > HoM: You are *so* dead. Obviously it is insane to use keys that you do not yourself control to keep secrets. That, however, is not the purpose of TCPA/Palladium as envisaged by Microsoft. The intent is that Peter can sell Paul software or content that will only run on ONE computer for ONE time period.. When the motherboard emits blue smoke, or the time runs out, whichever happens first, Paul has to buy new software. If prices are lowered accordingly, this might be acceptable. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG 4Mqj1ia6DD0EYpdLMEd7al35eTYefnvhcFesBlMz 25n9obdfhvRVxEkY4YtWw7BuFxrOKgTtfI1Dp8uAA From acqudrugs at paris.com Fri Aug 2 15:05:21 2002 From: acqudrugs at paris.com (Prescription online) Date: Fri, 2 Aug 2002 15:05:21 -0700 Subject: Buy Drugs Online Phentermine (Weight Loss) cypherpunks@minder.net wihri Message-ID: <200208022205.g72M50J43039@locust.minder.net> A non-text attachment was scrubbed... Name: not available Type: text/html Size: 6867 bytes Desc: not available URL: From mmotyka at lsil.com Fri Aug 2 14:12:35 2002 From: mmotyka at lsil.com (Michael Motyka) Date: Fri, 02 Aug 2002 15:12:35 -0600 Subject: Open source Vs palladium-Social darwinism Vs Mutual aid? Message-ID: <3D4AF5C3.1567E544@lsil.com> Matthew X wrote : > > Possibly no connection,its late in the day here...I can feel a 'regime > change' coming > on...http://www.infoshop.org/inews/stories.php?story=02/08/01/5792459 > ""The views you have acquired about Darwinism, evolution, and the struggle > for existence won't explain to you the meaning of your life and won't give > you guidance in your actions, and a life without an explanation of its > meaning and importance, and without the unfailing guidance that stems from > it is a pitiful existence. Think about it. I say it, probably on the eve of > my death, because I love you." > Tolstoy. > Frightened words of a dying man suffering from reality overload. From remailer at aarg.net Fri Aug 2 15:30:03 2002 From: remailer at aarg.net (AARG! Anonymous) Date: Fri, 2 Aug 2002 15:30:03 -0700 Subject: Challenge to David Wagner on TCPA Message-ID: Peter Trei writes: > It's rare enough that when a new anononym appears, we know > that the poster made a considered decision to be anonymous. > > The current poster seems to have parachuted in from nowhere, > to argue a specific position on a single topic. It's therefore > reasonable to infer that the nature of that position and topic has > some bearing on the decision to be anonymous. Yes, my name is "AARG!". That was the first thing my mother said after I was born, and the name stuck. Not really. For Peter's information, the name associated with a message through an anonymous remailer is simply the name of the last remailer in the chain, whatever that remailer operator chose to call it. AARG is a relatively new remailer, but if you look at http://anon.efga.org/Remailers/TypeIIList you will see that it is very reliable and fast. I have been using it as an exit remailer lately because other ones that I have used often produce inconsistent results. It has not been unusual to have to send a message two or three times before it appears. So far that has not been a problem with this one. So don't read too much into the fact that a bunch of anonymous postings have suddenly started appearing from one particular remailer. For your information, I have sent over 400 anonymous messages in the past year to cypherpunks, coderpunks, sci.crypt and the cryptography list (35 of them on TCPA related topics). From remailer at aarg.net Fri Aug 2 16:56:42 2002 From: remailer at aarg.net (AARG!Anonymous) Date: Fri, 2 Aug 2002 16:56:42 -0700 Subject: Challenge to David Wagner on TCPA Message-ID: <39eb7c2e6804b1854dffb31bfa307865@aarg.net> Peter Trei envisions data recovery in a TCPA world: > HoM: I want to recover my data. > Me: OK: We'll pull the HD, and get the data off it. > HoM: Good - mount it as a secondary HD in my new system. > Me: That isn't going to work now we have TCPA and Palladium. > HoM: Well, what do you have to do? > Me: Oh, it's simple. We encrypt the data under Intel's TPME key, > and send it off to Intel. Since Intel has all the keys, they can > unseal all your data to plaintext, copy it, and then re-seal it for > your new system. It only costs $1/Mb. > HoM: Let me get this straight - the only way to recover this data is > to let > Intel have a copy, AND pay them for it? > Me: Um... Yes. I think MS might be involved as well, if your were > using > Word. > HoM: You are *so* dead. It's not quite as bad as all this, but it is still pretty bad. You don't have to send your data to Intel, just a master storage key. This key encrypts the other keys which encrypt your data. Normally this master key never leaves your TPM, but there is this optional feature where it can be backed up, encrypted to the manufacturer's public key, for recovery purposes. I think it is also in blinded form. Obviously you'd need to do this backup step before the TPM crashed; afterwards is too late. So maybe when you first get your system it generates the on-chip storage key (called the SRK, storage root key), and then exports the recovery blob. You'd put that on a floppy or some other removable medium and store it somewhere safe. Then when your system dies you pull out the disk and get the recovery blob. You communicate with the manufacturer, give him this recovery blob, along with the old TPM key and the key to your new TPM in the new machine. The manufacturer decrypts the blob and re-encrypts it to the TPM in the new machine. It also issues and distributes a CRL revoking the cert on the old TPM key so that the old machine can't be used to access remote TCPA data any more. (Note, the CRL is not used by the TPM itself, it is just used by remote servers to decide whether to believe client requests.) The manufacturer sends the data back to you and you load it into the TPM in your new machine, which decrypts it and stores the master storage key. Now it can read your old data. Someone asked if you'd have to go through all this if you just upgraded your OS. I'm not sure. There are several secure registers on the TPM, called PCRs, which can hash different elements of the BIOS, OS, and other software. You can lock a blob to any one of these registers. So in some circumstances it might be that upgrading the OS would keep the secure data still available. In other cases you might have to go through some kind of recovery procedure. I think this recovery business is a real Achilles heel of the TCPA and Palladium proposals. They are paranoid about leaking sealed data, because the whole point is to protect it. So they can't let you freely copy it to new machines, or decrypt it from an insecure OS. This anal protectiveness is inconsistent with the flexibility needed in an imperfect world where stuff breaks. My conclusion is that the sealed storage of TCPA will be used sparingly. Ross Anderson and others suggest that Microsoft Word will seal all of its documents so that people can't switch to StarOffice. I think that approach would be far too costly and risky, given the realities I have explained above. Instead, I would expect that only highly secure data would be sealed, and that there would often be some mechanism to recover it from elsewhere. For example, in a DRM environment, maybe the central server has a record of all the songs you have downloaded. Then if your system crashes, rather than go through a complicated crypto protocol to recover, you just buy a new machine, go to the server, and re-download all the songs you were entitled to. Or in a closed environment, like a business which seals sensitive documents, the data could be backed up redundantly to multiple central file servers, each of which seal it. Then if one machine crashes, the data is available from others and there is no need to go through the recovery protocol. So there are solutions, but they will add complexity and cost. At the same time they do add genuine security and value. Each application and market will have to find its own balance of the costs and benefits. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From AlbionZeglin at Total-Security.com Fri Aug 2 14:29:42 2002 From: AlbionZeglin at Total-Security.com (Albion Zeglin) Date: Fri, 2 Aug 2002 17:29:42 -0400 Subject: Challenge to David Wagner on TCPA Message-ID: <1028323782.3d4af9c6b69a5@mail.spamcop.net> Quoting Jay Sulzberger : > b. Why must TCPA/Palladium be a dongle on the whole computer? Why not a > separate dongle? Because, of course, the Englobulators proceed here on > principle. The principle being that only the Englobulators have a right to > own printing presses/music studios/movie and animation studios. > A separate dongle can't verify the integrity of the processor. The important part is that the processor's state (including initial RAM load) is verifiable. Without this the OS could be virtualized and modified after the integrity check. Just imagine running Windows Media Player on a virtual machine, trapping the calls to the audio card and thus being able to copy content perfectly. A dongle can't prevent this. Eventually for TCPA to be effective against hardware hacks such as memory probes, not only will the harddrive storage be sealed, but RAM must be sealed as well. Once TCPA moves onprocessor, I expect encrypted RAM will be next. Albion. From rsedc at atlantic.gse.rmit.edu.au Fri Aug 2 00:35:41 2002 From: rsedc at atlantic.gse.rmit.edu.au (rsedc at atlantic.gse.rmit.edu.au) Date: Fri, 2 Aug 2002 17:35:41 +1000 Subject: Challenge to David Wagner on TCPA In-Reply-To: <21c2b1fa881cdf27375fb175816f2ef0@aarg.net>; from AARG! Anonymous on Mon, Jul 29, 2002 at 03:35:32PM -0700 References: <21c2b1fa881cdf27375fb175816f2ef0@aarg.net> Message-ID: <20020802173541.A20075@atlantic.gse.rmit.edu.au> On Mon, Jul 29, 2002 at 03:35:32PM -0700, AARG! Anonymous wrote: > Declan McCullagh writes at > http://zdnet.com.com/2100-1107-946890.html: > > "The world is moving toward closed digital rights management systems > where you may need approval to run programs," says David Wagner, > an assistant professor of computer science at the University of > California at Berkeley. "Both Palladium and TCPA incorporate features > that would restrict what applications you could run." > > But both Palladium and TCPA deny that they are designed to restrict what > applications you run. The TPM FAQ at > http://www.trustedcomputing.org/docs/TPM_QA_071802.pdf reads, in > answer #1: > > : The TPM can store measurements of components of the user's system, but > : the TPM is a passive device and doesn't decide what software can or > : can't run on a user's system. > > An apparently legitimate but leaked Palladium White Paper at > http://www.neowin.net/staff/users/Voodoo/Palladium_White_Paper_final.pdf > says, on the page shown as number 2: > > : A Palladium-enhanced computer must continue to run any existing > : applications and device drivers. > Can you find anything in this spec that would do what David Wagner says > above, restrict what applications you could run? Despite studying this > spec for many hours, no such feature has been found. > > So here is the challenge to David Wagner, a well known and justifiably > respected computer security expert: find language in the TCPA spec to > back up your claim above, that TCPA will restrict what applications > you can run. Either that, or withdraw the claim, and try to get Declan > McCullagh to issue a correction. (Good luck with that!) 'Applications' as used in Wagner's statement can be actions or computer programs to accomplish the desired tasks for the users/owners. >From Webster's Revised Unabridged Dictionary (1913) [web1913]: Application \Ap`pli*ca"tion\, n. [L. applicatio, fr. applicare: cf. F. application. See {Apply}.] 3. The act of applying as a means; the employment of means to accomplish an end; specific use. >From WordNet (r) 1.7 [wn]: 3: a program that gives a computer instructions that provide the user with tools to accomplish a task; Both involve using the term 'accomplish'. Whereas from WordNet (r) 1.7 [wn]: software n : (computer science) written programs or procedures or rules and associated documentation pertaining to the operation of a computer system and that are stored in read/write memory; As you can see, 'application' differs from 'software' in that an 'application' needs to 'accomplish' the desired tasks. If as you said later, On Thu, Aug 01, 2002 at 04:45:15PM -0700, AARG! Anonymous wrote: > But no, the TCPA does allow all software to run. Just because a remote > system can decide whether to send it some data doesn't mean that software > can't run. And just because some data may be inaccessible because it > was sealed when another OS was booted, also doesnt mean that software > can't run. > > I think we agree on the facts, here. All software can run, but the TCPA > allows software to prove its hash to remote parties, and to encrypt data > such that it can't be decrypted by other software. Would you agree that > this is an accurate summary of the functionality, and not misleading? that the desired tasks cannot be accomplished, then the software might run but the 'application' does not. Note the TPM FAQ quoted is correct in using the term 'software' but that is not the term used by Wagner. The sentence where the term 'application' is used in the alleged Palladium White Paper might appear to be self contraditory. Therefore I do not think that Wagner needs to withdraw his claim. David Chia -- What do you call a boomerang that does not come back? A Stick. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From vyiastrid at msn.com Fri Aug 2 18:24:15 2002 From: vyiastrid at msn.com (becky) Date: Fri, 2 Aug 2002 18:24:15 -0700 Subject: Hey Message-ID: <200208030124.g731OCJ51379@locust.minder.net> ################################ Your Online Pharmacy for Prescription Drugs! ################################ NEWS 08/02/02 Last month over 20,000 new people purchased prescription drugs at our website with our limited time offer. Are you purchasing prescription drugs yet??? ------------------------ Benefits of Ordering Prescription Drugs Online: - Confidential ordering & shipped discreetly overnight. - No more embarrassing doctor visits. - Our US licensed doctors will evaluate your medical history over the internet. - Online pharmacy for FDA approved drugs. - Medication prescribed by licensed U.S. Physicians - Secure Processing with the best prices on the internet. ------------------------ Click on one of the Links Below to Order FDA Approved Prescription Drugs: Viagra (Helps Erection) Viagra is used by millions of men in the US & world wide everyday. If you feel that your erection could be better, try Viagra. Click on the link: http://www.royalmeds.com/main2.php?rx=17770 Phentermine (Weight Loss) Enables people to burn fat doing nothing by stimulating your nervous system. It will give you more energy and you'll become more active! You'll burn fat easier and eat less. It's a safe and effective treatment to lose weight. Click on the link: http://www.royalmeds.com/main2.php?rx=17770 Propecia (Hair Loss) PROPECIA is a medical breakthrough. The first pill that effectively treats male pattern hair loss (at top of head) and anterior mid-scalp area. Click on the link: http://www.royalmeds.com/main2.php?rx=17770 Zyban (Stop Smoking) Zyban is the first nicotine-free pill that can help you stop smoking. Its prescription medicine is available only for smokers 18 and older. Click on the link: http://www.royalmeds.com/main2.php?rx=17770 ------------------------------- Mike Mallucio, Los Angeles, CA Your Prescription drugs have improved my sex life. Thanks to your Viagra pills I'm going to save my marriage. Becky Gonzalez, Miami, FL By ordering prescription drugs at your website I didn't have to drive to a doctor's office and you also saved me the personal embarrassment. Matt Grossman, Manhattan, NY One month after ordering a phentermine prescription at your website I lossed 20 Lbs doing nothing, have more energy and eat less! Thank You! Removal Instructions: This email is intended to be a benefit to the recipient. If you would like to opt-out and not receive any more marketing information please click on the following link http://worldrxco.com/remove.php Your address will be removed within 24hrs. We sincerely apologize for any inconvenience. ytuhmsgsvbyibyefuhpmf From support at id-discussions.com Fri Aug 2 11:42:26 2002 From: support at id-discussions.com (Interesting Devices Discussion Forum Mailer) Date: Fri, 02 Aug 2002 18:42:26 0000 Subject: Action Required to Activate Membership for Interesting Devices Discussion Forum! Message-ID: <200208021843101.SM00916@idnt698> Dear cypherpunks, Thank you for registering for the Interesting Devices Discussion Forum forums. Before we can activate your account one last step must be taken to complete your registration! Please note - you must complete this last step to become a registered member. You will only need to click on the link once, and your account will be updated. To complete your registration, click on the link below: http://id-discussions.com/vbulletin/register.php?a=act&u=87161&i=30303666 AOL Users click Here to be Activated **** Does The Above Link Not Work? **** First make sure the link has not been split over more than one line. If it has then just cut and paste the seperate pieces into your URL bar. If that stil fails please use your Web browser to go to: http://id-discussions.com/vbulletin/register.php?a=ver Please be sure not to add extra spaces. You will need to type in your username and activation number on the page that appears when you click on our copy the above link in your browser. Your Username is: cypherpunks Your Activation ID is: 30303666 If you are still having problems signing up please contact a member of our support staff at support at id-discussions.com and make sure you include your username, email and the problem you are having. Thanks very much, Interesting Devices Discussion Forum team From longdistance at hotbot.ca Fri Aug 2 15:05:04 2002 From: longdistance at hotbot.ca (longdistance at hotbot.ca) Date: Fri, 2 Aug 2002 19:05:04 -0300 Subject: Low Cost Long Distance Message-ID: <200208022205.g72M53230249@thunder.regatanet.com.br> New Page 1   LOW COST   LONG   DISTANCE     Six Plans To Choose From Including: $9.95 Plan  * Unlimited Plan  * Travel Plan Canadian Plans *  International   *  Intra/inter State Stop paying the high cost of long distance.   Simple to understand all-inclusive pricing so you save big! Email us now with your phone number to hear how crystal clear your connection will be. To be removed please click here             -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/html Size: 2875 bytes Desc: not available URL: From save at msm.com Fri Aug 2 15:11:34 2002 From: save at msm.com (save at msm.com) Date: Fri, 2 Aug 2002 19:11:34 -0300 Subject: Low Cost Long Distance Message-ID: <200208022211.g72MBX230469@thunder.regatanet.com.br> New Page 1   LOW COST   LONG   DISTANCE     Six Plans To Choose From Including: $9.95 Plan  * Unlimited Plan  * Travel Plan Canadian Plans *  International   *  Intra/inter State Stop paying the high cost of long distance.   Simple to understand all-inclusive pricing so you save big! Email us now with your phone number to hear how crystal clear your connection will be. To be removed please click here             -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/html Size: 2875 bytes Desc: not available URL: From jays at panix.com Fri Aug 2 16:27:09 2002 From: jays at panix.com (Jay Sulzberger) Date: Fri, 2 Aug 2002 19:27:09 -0400 (EDT) Subject: Challenge to David Wagner on TCPA In-Reply-To: Message-ID: On Fri, 2 Aug 2002, Trei, Peter wrote: > > AARG! Anonymous[SMTP:remailer at aarg.net] writes > [...] > > Now, there is an optional function which does use the manufacturer's key, > > but it is intended only to be used rarely. That is for when you need to > > transfer your sealed data from one machine to another (either because you > > have bought a new machine, or because your old one crashed). In this > > case you go through a complicated procedure that includes encrypting > > some data to the TPME key (the TPM manufacturer's key) and sending it > > to the manufacturer, who massages the data such that it can be loaded > > into the new machine's TPM chip. > > > > So this function does require pre-loading a manufacturer key into the > > TPM, but first, it is optional, and second, it frankly appears to be so > > cumbersome that it is questionable whether manufacturers will want to > > get involved with it. OTOH it is apparently the only way to recover > > if your system crashes. This may indicate that TCPA is not feasible, > > because there is too much risk of losing locked data on a machine crash, > > and the recovery procedure is too cumbersome. That would be a valid > > basis on which to criticize TCPA, but it doesn't change the fact that > > many of the other claims which have been made about it are not correct. > [...] > > While I reserve the right to respond to the rest of the poster's letter, > I'd like to call out this snippet, which gives a very good reason > for both corporate and individual users to avoid TCPA as if it were > weaponized anthrax (Hi NSA!). > ... > OK, It's 2004, I'm an IT Admin, and I've converted my corporation > over to TCPA/Palladium machines. My Head of Marketing has his > TCPA/Palladium desktop's hard drive jam-packed with corporate > confidential documents he's been actively working on - sales > projections, product plans, pricing schemes. They're all sealed files. > > His machine crashes - the MB burns out. > He wants to recover the data. > > HoM: I want to recover my data. > Me: OK: We'll pull the HD, and get the data off it. > HoM: Good - mount it as a secondary HD in my new system. > Me: That isn't going to work now we have TCPA and Palladium. > HoM: Well, what do you have to do? > Me: Oh, it's simple. We encrypt the data under Intel's TPME key, > and send it off to Intel. Since Intel has all the keys, they can > unseal all your data to plaintext, copy it, and then re-seal it for > your new system. It only costs $1/Mb. > HoM: Let me get this straight - the only way to recover this data is to > let > Intel have a copy, AND pay them for it? > Me: Um... Yes. I think MS might be involved as well, if your were using > Word. > HoM: You are *so* dead. > > --------------------------- > > Peter Trei I think that many managers in this situation would feel reassured that both Intel and Microsoft would be handling these sensitve documents. Else why do lawyers use Microsoft systems to send unencrypted documents between offices? ad technicalities: Just one more level of indirection^Wencryption would answer the objections of those few managers of exquisite sensibilities, who worry about Intel/Microsoft reading their documents. oo--JS. From jays at panix.com Fri Aug 2 16:47:07 2002 From: jays at panix.com (Jay Sulzberger) Date: Fri, 2 Aug 2002 19:47:07 -0400 (EDT) Subject: Challenge to David Wagner on TCPA In-Reply-To: <1028323782.3d4af9c6b69a5@mail.spamcop.net> Message-ID: On Fri, 2 Aug 2002, Albion Zeglin wrote: > Quoting Jay Sulzberger : > > > > b. Why must TCPA/Palladium be a dongle on the whole computer? Why not a > > separate dongle? Because, of course, the Englobulators proceed here on > > principle. The principle being that only the Englobulators have a right to > > own printing presses/music studios/movie and animation studios. > > > > A separate dongle can't verify the integrity of the processor. The > important part is that the processor's state (including initial RAM load) > is verifiable. But if you just want to show movies "securely" you need not use my general purpose and today untrammeled computer. You can either show movies in movie houses, or use some slightly trammeled version of a "cable ready TV", or the variant product mentioned earlier, the "donglified monitor/speaker". There is no need for the MPAA to "verify the integrity of the processor" if all the MPAA wants to do is sell me tickets to movies. > Without this the OS could be virtualized and modified after the integrity > check. What does the enforcement of the laws against copyright infringement have to do with my general purpose and today untrammeled computer? There is no relation of the sort you, and all the mass media, implicitly assume here. Indeed no OS at all should be involved in the "secure showing of movies". It is like using the standard C libraries to write "secure code"! > > Just imagine running Windows Media Player on a virtual machine, trapping > the calls to the audio card and thus being able to copy content > perfectly. A dongle can't prevent this. My donglified monitor/speakers combination, of course, offers greater assurance. Here is part of my argument: the explanation of my proposed protocols can actually be understood. > > Eventually for TCPA to be effective against hardware hacks such as memory > probes, not only will the harddrive storage be sealed, but RAM must be > sealed as well. > Once TCPA moves onprocessor, I expect encrypted RAM will be next. > > Albion. The dilemma "Either give over all the computers in the world to the Englobulators, or never get to see another big budget Hollywood movie." is a false dichotomy. oo--JS. From eresrch at eskimo.com Fri Aug 2 21:10:32 2002 From: eresrch at eskimo.com (Mike Rosing) Date: Fri, 2 Aug 2002 21:10:32 -0700 (PDT) Subject: Challenge to David Wagner on TCPA In-Reply-To: <39eb7c2e6804b1854dffb31bfa307865@aarg.net> Message-ID: On Fri, 2 Aug 2002, AARG! Anonymous wrote: > You don't have to send your data to Intel, just a master storage key. > This key encrypts the other keys which encrypt your data. Normally this > master key never leaves your TPM, but there is this optional feature > where it can be backed up, encrypted to the manufacturer's public key, > for recovery purposes. I think it is also in blinded form. In other words, the manufacturer has access to all your data because they have the master storage key. Why would everyone want to give one manufacturer that much power? Or am I missing something... > You communicate with the manufacturer, give him this recovery blob, along > with the old TPM key and the key to your new TPM in the new machine. > The manufacturer decrypts the blob and re-encrypts it to the TPM in the and stores the blob in a safe place for future use. > The manufacturer sends the data back to you and you load it into the TPM > in your new machine, which decrypts it and stores the master storage key. > Now it can read your old data. and so can everyone else who visits the manufacturers database. > I think this recovery business is a real Achilles heel of the TCPA > and Palladium proposals. They are paranoid about leaking sealed data, > because the whole point is to protect it. So they can't let you freely > copy it to new machines, or decrypt it from an insecure OS. This anal > protectiveness is inconsistent with the flexibility needed in an imperfect > world where stuff breaks. Seems like an understatement to me :-) Explaining to every CEO left standing that one company may have access to all their buisness data because congress wants to make TCPA a law could be a very power lobby. > So there are solutions, but they will add complexity and cost. At the > same time they do add genuine security and value. Each application and > market will have to find its own balance of the costs and benefits. Yeah baby, tell them CEO's their costs are going up. That'll definitly help TCPA die quickly. Especially nowadays. Patience, persistence, truth, Dr. mike From measl at mfn.org Fri Aug 2 19:37:02 2002 From: measl at mfn.org (Alif The Terrible) Date: Fri, 2 Aug 2002 21:37:02 -0500 (CDT) Subject: Challenge to David Wagner on TCPA In-Reply-To: Message-ID: On Fri, 2 Aug 2002, AARG! Anonymous wrote: > I have sent over 400 anonymous messages in the past year > to cypherpunks, coderpunks, sci.crypt and the cryptography list (35 > of them on TCPA related topics). I see you are no too worries about traffic analysis? -- Yours, J.A. Terranson sysadmin at mfn.org If Governments really want us to behave like civilized human beings, they should give serious consideration towards setting a better example: Ruling by force, rather than consensus; the unrestrained application of unjust laws (which the victim-populations were never allowed input on in the first place); the State policy of justice only for the rich and elected; the intentional abuse and occassionally destruction of entire populations merely to distract an already apathetic and numb electorate... This type of demogoguery must surely wipe out the fascist United States as surely as it wiped out the fascist Union of Soviet Socialist Republics. The views expressed here are mine, and NOT those of my employers, associates, or others. Besides, if it *were* the opinion of all of those people, I doubt there would be a problem to bitch about in the first place... -------------------------------------------------------------------- From netexcelerator at yahoo.com Sat Aug 3 01:15:14 2002 From: netexcelerator at yahoo.com (AMY) Date: Sat, 3 Aug 2002 01:15:14 Subject: none Message-ID: <200208030821.g738LLR03091@waste.minder.net> Hello, This is a one time mailing. We are looking for people who might be interested in working P/T from home. This position involves working 10-15 hours per week. You can expect to make $15-$25 per hour worked. To see a job description, you may go to http://starttodayandbeginworkingatyourconvience.8m.com Have a great day! From nobody at dizum.com Fri Aug 2 16:40:17 2002 From: nobody at dizum.com (Nomen Nescio) Date: Sat, 3 Aug 2002 01:40:17 +0200 (CEST) Subject: Other uses of TCPA Message-ID: <3d3cb71053e71de0b181ecd56b8ba3a2@dizum.com> I think that people are beginning to understand that TCPA is not a black and white issue. It is neither the overwhelming threat that some activists are describing, nor the panacea that the vendors are selling. It is a technology with strengths and weaknesses. As an exercise, try thinking of ways you could use TCPA to promote "good guy" applications. What could you do in a P2P network if you could trust that all participants were running approved software? And if you could prevent third parties, including hostile governments, from seeing the data being used by that software? You may be surprised to find that if you look at it with an open mind, TCPA could be a tremendous boon to freedom-oriented technologies. From file sharing to crypto protocols to digital cash, TCPA lets you expand the trusted computing base to the entire set of participating machines. It's really a tremendously powerful technology. The biggest problem, ironically, is that TCPA may not be secure enough. It's one thing to make video piracy difficult, it's another matter to keep the Chinese government from prying into the sealed storage. But with future generations of TCPA integrated onto CPUs with improved tamper resistance, it will be much more difficult to defeat the protections. It may turn out that TCPA can significantly facilitate cypherpunk goals. From mortgage_quotes_fast at nationwidemortgage.us Sat Aug 3 00:04:43 2002 From: mortgage_quotes_fast at nationwidemortgage.us (mortgage_quotes_fast at nationwidemortgage.us) Date: Sat, 3 Aug 2002 02:04:43 -0500 Subject: Adv: Mortgage Quotes Fast Online, No Cost Message-ID: <200208030704.g7374hAp002249@ak47.algebra.com> A non-text attachment was scrubbed... Name: not available Type: text/html Size: 4401 bytes Desc: not available URL: From dvdcopyproinstant at cox.net Sat Aug 3 02:14:56 2002 From: dvdcopyproinstant at cox.net (DVD Copy Pro) Date: Sat, 3 Aug 2002 02:14:56 Subject: DVD Copy Pro Instant Download only $9.99! Burn DVD To CD-r! Message-ID: A non-text attachment was scrubbed... Name: not available Type: text/html Size: 18785 bytes Desc: not available URL: From mortgage_quotes_fast at nationwidemortgage.us Sat Aug 3 00:17:09 2002 From: mortgage_quotes_fast at nationwidemortgage.us (mortgage_quotes_fast at nationwidemortgage.us) Date: Sat, 3 Aug 2002 02:17:09 -0500 Subject: Adv: Mortgage Quotes Fast Online, No Cost Message-ID: <200208030717.CAA32263@einstein.ssz.com> A non-text attachment was scrubbed... Name: not available Type: text/html Size: 4401 bytes Desc: not available URL: From morlockelloi at yahoo.com Sat Aug 3 03:20:13 2002 From: morlockelloi at yahoo.com (Morlock Elloi) Date: Sat, 3 Aug 2002 03:20:13 -0700 (PDT) Subject: Challenge to David Wagner on TCPA In-Reply-To: <3D4A9CFC.22726.69ECD4C@localhost> Message-ID: <20020803102013.93930.qmail@web13208.mail.yahoo.com> The principal philosophical issue here is that the ownership of the "computer" terminates. So far most people owned their computers in the sense that they could make transistors inside do anything they liked, provided they had some easily-obtainable knowledge. Content/software vendors had their stuff executed on enemy's territory with all imaginable consequences. TCPA-ed computer is actually a single-seat movie theatre teleported to your house. It's operated and owned by one or more corporations - what you pay when "buying" the computer are up-front installation costs of the franchise. Remember that theatres are enclosed spaces with entertainment with doors that you need a ticket to go through. Sheeple will get more entertainment. The only problem seems to be that small independent producers will not get their stuff played there. Tough shit. If small producers want to fuck with all world's theatres, they need to get better. Parasiting is over. There is no natural right to program other's machines. When I go to the theatre I don't want unwashed activists flashing their stuff on the screen. At least not dumb ones. Ah, the computers. Well, those that want computers will have them. They may not be as cheap as today and there will not be as many of them, but I think that all people *I* deal with will have them, so I don't really care. ===== end (of original message) Y-a*h*o-o (yes, they scan for this) spam follows: Yahoo! Health - Feel better, live better http://health.yahoo.com From adam at cypherspace.org Fri Aug 2 21:26:12 2002 From: adam at cypherspace.org (Adam Back) Date: Sat, 3 Aug 2002 05:26:12 +0100 Subject: info-theoretic model of anonymity Message-ID: <20020803052612.A413999@exeter.ac.uk> Just read this paper published in PET02 "Towards an Information Theoretic Metric for Anonymity" [1]: http://www.cl.cam.ac.uk/~gd216/set.pdf or http://www.cl.cam.ac.uk/~gd216/set.ps it uses a Shannon like entropy model for the anonymity provided by a system uses this model to analyse the effect of different parameters one can tune with mixmaster (POOLSIZE, RATE, in mixmaster.conf). The "anonymity entropy" measurement can be interpreted as how many bits of information the attacker needs to identify a user and is computed from probabilities. Would be interesting to try estimate the entropy provided by the current mixmaster network. A number of nodes publish their parameter choices, and traffic volume over time (in hourly increments). Adam -- http://www.cypherspace.org/adam/ [1] @inproceedings{Serjantov:02:info-theoretic-anon, author = "Andrei Serjantov and George Danezis", title = "Towards an Information Theoretic Metric for Anonymity", booktitle = "Proceedings of the Workshop on Privacy Enhancing Technologies", year = "2002", note = "Also available as \url{http://www.cl.cam.ac.uk/~aas23/papers_aas/set.ps}" } From freehqefkfql at jakgym.se Sat Aug 3 06:49:09 2002 From: freehqefkfql at jakgym.se (freehqefkfql at jakgym.se) Date: Sat, 3 Aug 2002 08:49:09 -0500 Subject: Free Porn Password Get Off Now! Message-ID: <1028378949.985@localhost.localdomain> A non-text attachment was scrubbed... Name: not available Type: text/html Size: 4371 bytes Desc: not available URL: From jamesd at echeque.com Sat Aug 3 09:10:26 2002 From: jamesd at echeque.com (James A. Donald) Date: Sat, 3 Aug 2002 09:10:26 -0700 Subject: Other uses of TCPA In-Reply-To: References: <3d3cb71053e71de0b181ecd56b8ba3a2@dizum.com> Message-ID: <3D4B9E02.3999.47D95C@localhost> -- On Sat, 3 Aug 2002, Nomen Nescio wrote: > As an exercise, try thinking of ways you could use TCPA to > promote "good guy" applications. What could you do in a P2P > network if you could trust that all participants were running > approved software? And if you I can only see one application for voluntary TCPA, and that is the application it was designed to perform: Make it possible run software or content which is encrypted so that it will only run on one computer for one time period. All the other proposed uses, both good and evil, seem improbably cumbersome, or easier to do in some other fashion. There are quite a few extremely evil uses it would be good for, but they would only be feasible if enforced by legislation -- otherwise people would turn the chip off, or tear it out. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG Hzs0OpVc+bwQiFEZnMNE2zMLAXiYjMNrOWpH9WIb 2vvlvOjPeQH/ua0E9NnfeVaLvRGnxGuIvKZGcMZdN From eugen at leitl.org Sat Aug 3 00:33:47 2002 From: eugen at leitl.org (Eugen Leitl) Date: Sat, 3 Aug 2002 09:33:47 +0200 (CEST) Subject: Other uses of TCPA In-Reply-To: <3d3cb71053e71de0b181ecd56b8ba3a2@dizum.com> Message-ID: On Sat, 3 Aug 2002, Nomen Nescio wrote: > I think that people are beginning to understand that TCPA is not a > black and white issue. It is neither the overwhelming threat that some > activists are describing, nor the panacea that the vendors are selling. > It is a technology with strengths and weaknesses. No, TCPA is a technology with a potential for abuse, and there's certainly a strong economic and political drive to abuse it. As such it is simply not acceptable. I don't want this particular camel in my tent, thankyouverymuch. > As an exercise, try thinking of ways you could use TCPA to promote "good > guy" applications. What could you do in a P2P network if you could > trust that all participants were running approved software? And if you Approved by whom? There's a secret embedded into the CPU and/or chipset. I can't read it out. It was either generated within (so it can't be shared), or the vendor put it there (and kept a copy of it), or the signed code which is trusted by original vendor put it there. If you can read out a secret, and the system destroys it internal copy, you can still clone it into as many systems as you want, as long as it doesn't go pass through some Dark Tower in Mordor somewhere. Why should I trust the vendor with any of this? I don't even trust the vendor with what he puts into his BIOS. If I need secure encryption, I can put crypto into a deep embedded in a USB fob, or a smartcard, or buy some open hardware from a trusted source. If it needs high throughput, you could package it into a PCI card (and please put the secret into a removable dongle). > could prevent third parties, including hostile governments, from seeing > the data being used by that software? You may be surprised to find that You don't need big brother hardware to prevent participants from accessing the content directly. If the content is fragmented into encrypted slivers somebody else has the key for (insert onions for extra paranoia) you have no idea what is on your hard drive. The content only magically materializes on a single node when you try to access it. It comes from/passing through nodes you sure see the addresses, but these change. Both because the content moves or gets routed differently, and the nodes are largely on dynamic IPs. > if you look at it with an open mind, TCPA could be a tremendous boon to > freedom-oriented technologies. From file sharing to crypto protocols > to digital cash, TCPA lets you expand the trusted computing base to How does TCPA help you with double spending your tokens? I understand no reliable solutions without centralism exist. We should definitely aiming for something inspired by ecology (crunch being the equivalent of sunlight). > the entire set of participating machines. It's really a tremendously > powerful technology. I'd rather not have tremendously powerful technology standing under somebody's else's control sitting under my desk. > The biggest problem, ironically, is that TCPA may not be secure enough. > It's one thing to make video piracy difficult, it's another matter to keep > the Chinese government from prying into the sealed storage. But with How is the Chinese government/CoS/anybody else going to pry into a document that is encrypted on an air-gapped machine (secret stashed away elsewhere), and stored on a secure (a few iterations of MNet or similiar) P2P network? Assuming, I was nice enough to tell them the URI for it? How is the Chinese government going to effectively prevent people accessing content on a steganographic P2P network? Why, with something very like TCPA: by outlawing all purpose computers but those running code approved by an authority. > future generations of TCPA integrated onto CPUs with improved tamper > resistance, it will be much more difficult to defeat the protections. Are you somehow assuming you can magically protect state of structured matter encoding a shared (with many, many copies out there) from being read by people with basically unlimited resources? > It may turn out that TCPA can significantly facilitate cypherpunk goals. From newsusercypher_18 at driverlicense.com Sat Aug 3 09:43:33 2002 From: newsusercypher_18 at driverlicense.com (newsusercypher_18 ) Date: Sat, 03 Aug 02 09:43:33 E. Europe Daylight Time Subject: Hello cypher_18 , news for you Message-ID: <200208031215.g73CFYJ77058@locust.minder.net> INTERNATIONAL DRIVER'S LICENSE Need a new driver's license? Too many points or other trouble? Want a license that can never be suspended or revoked? Want ID for nightclubs or hotel check-in? Avoid tickets, fines, and mandatory driver's education. Protect your privacy, and hide your identity. The United Nations gave you the privilege to drive freely throughout the world! (Convention on International Road Traffic of September 19, 1949 & World Court Decision, The Hague, Netherlands, January 21, 1958) Take advantage of your rights. Order a valid International Driver's License that can never be suspended or revoked. Confidentiality assured. CALL NOW!!! 206-706-2665 ------------------------------------------------------------ WANT TO BE REMOVED? If you don't want to receive this newsletter, reply to this message with your email address in the subject line. STILL GETTING MAIL EVEN AFTER REQUESTING REMOVAL? Remember to include in the subject line the addresses your received this message. Any Vulgarity will be filtered and your request for removal will be deleted, so don't bother in vain ! Thank you for listening, Bulkers Warehouse! From tcmay at got.net Sat Aug 3 09:56:26 2002 From: tcmay at got.net (Tim May) Date: Sat, 3 Aug 2002 09:56:26 -0700 Subject: Other uses of TCPA In-Reply-To: <3D4B9E02.3999.47D95C@localhost> Message-ID: On Saturday, August 3, 2002, at 09:10 AM, James A. Donald wrote: > -- > On Sat, 3 Aug 2002, Nomen Nescio wrote: >> As an exercise, try thinking of ways you could use TCPA to >> promote "good guy" applications. What could you do in a P2P >> network if you could trust that all participants were running >> approved software? And if you > > I can only see one application for voluntary TCPA, and that is the > application it was designed to perform: Make it possible run > software or content which is encrypted so that it will only run on > one computer for one time period. > > All the other proposed uses, both good and evil, seem improbably > cumbersome, or easier to do in some other fashion. There are > quite a few extremely evil uses it would be good for, but they > would only be feasible if enforced by legislation -- otherwise > people would turn the chip off, or tear it out. "The VSPA (Video Surveillance Protection Architecture) is a completely voluntary arrangement whereby video cameras must be installed by 2003 in all new and remodeled homes, apartments, places of business, libraries, and other such places. These cameras and microphones can be used voluntarily by parents and other concerned persons to monitor children, pets, and domestic workers. Under the VSPA, the video feed will be sent to a centralized location where homeowners and parents may then access the feed, strictly voluntarily. "While installation of VSPA will be mandated by law in all new and remodeled homes, the use of VSPA features is strictly on an opt-in basis, except as authorized by law (*). "* Note that VSPA features may be accessed by court order, by presidential emergency order, by authorization of an employee of the Justice, Defense, Interior, or HomeSec departments who is above the grade level GS-7. During periods of Domestic Emergency, the President or the HomeSec Commissar may enable the VSPA on a regional or state or national basis. Additionally, Child Protective Services, the Environmental Protection Agency, and other selected agencies may be granted access, all subject to strict oversight by government officials. "Remember, VSPA is a completely voluntary system. The installation of the VSPA cameras and microphones will assist us all. The legitimate needs of law enforcement will be subject to careful oversight. "Best of all, a substantial tax credit will be granted to those who voluntarily install the VSPA system prior to the mandatory phase-in time. To pay for the voluntary VSPA system, taxes will be raised for those who fail to volunteer." --Tim May "As my father told me long ago, the objective is not to convince someone with your arguments but to provide the arguments with which he later convinces himself." -- David Friedman From rah at shipwright.com Sat Aug 3 07:05:25 2002 From: rah at shipwright.com (R. A. Hettinga) Date: Sat, 3 Aug 2002 10:05:25 -0400 Subject: Apple's Security Update Message Fails PGP Authentication Message-ID: --- begin forwarded text From jfkmbs at hotmail.com Sat Aug 3 10:11:32 2002 From: jfkmbs at hotmail.com (John) Date: Sat, 3 Aug 2002 10:11:32 Subject: No subject Message-ID: <200208031511.g73FBDAp030649@ak47.algebra.com> WHOLESALE SOURCES 2002 FIND OVER 1,000,000 PRODUCTS The most useful Wholesale Source Guide ever put together... Save up to 90% on over ONE MILLION top quality brand-name products. Get low wholesale prices directly from Wholesalers, Distributors, Vendors, and Liquidators. Eliminate the middleman! This guide is perfect for entrepreneurs that do business on the Internet, mail order, flea markets, or simply want to buy products for themselves at wholesale prices. Here is just a sample of the products you can get at wholesale prices using our guide: Computers Jewelry Electronics Household Goods Sporting Goods Clothing We will supply you with the following sources: American Wholesalers - Thousands and thousands of American companies that will sell you virtually any item you can think of at low wholesale prices. American Dropshippers - These companies will drop-ship their products right to your customers so you don't need to stock an inventory! Philippines Sources - easily buy from the Philippines at the lowest wholesale prices possible. Oriental Sources - Buy at low, low prices direct from Oriental countries like Korea, Malaysia, China, India, Thailand, Indonesia and Singapore. Hong Kong Sources - The US dollar is very valuable in Hong Kong and their factories produce thousands of products at low giveaway prices. Mexico Sources - this is a gold mine of products. Mexico is noted for their fine silver jewelry and you will have access to thousands of factories that will supply you with real profit making products. Taiwan Sources - these are manufacturers that want to sell thousands of different products to you at unbelievable low prices. Closeout Sources - Thousands of Close out companies ready to liquidate their merchandise at below wholesale prices! You will have access to thousands of wholesale sources where you can find over ONE MILLION products and wholesale products. All for Only $10.00 Discover the immense profits just waiting for you when using these wholesale sources. To order, Send $10 U.S. CASH AND Your E-Mail Address to: Publications International Attn: Tess DeShaw P. O. Box 330547 Ft. Worth, TX 76163 From protect_yourself at email.com Sat Aug 3 10:45:08 2002 From: protect_yourself at email.com (America's most needed service) Date: Sat, 3 Aug 2002 10:45:08 Subject: See The Movie !!!! Message-ID: <200208031445.g73EjdAp029177@ak47.algebra.com> This is the Cheapest form of having Quality Attorneys on Retainer that there is....Over 1,250,000 members use this service nationwide. In todays world you need to protect yourself and/or your family with America's Most needed Service. You should see the Movie ! PLEASE CLICK ON THIS LINK: ------------------------------------ http://www.prepaidlegal.com/info/teachout ------------------------------------ YOU CAN JOIN THE SERVICE ONLINE... THE PROGRAM IS MONTH TO MONTH AND CAN BE CANCELED AT ANY TIME IF YOU ARE NOT SATISFIED. Please call my toll free # below. LEARN MORE ABOUT THE SERVICE, CALL 1(888) 784-8474 option 1. After message you will be prompted for my extension # 1308 TELL ME WHAT YOU THINK OR SIGN UP ONLINE. JIM THANKS FOR YOUR TIME... INDEPENDANT ASSOCIATE F.Y.I. Under Bill s 1618 TITLE III Passed by the 105th U.S. Congress this letter can NOT be considered "SPAM" as long as we include contact information & or a remove device as follows 1) CLICK ON Contact ME tab of my web page, leave your email address to be removed. OR 2) Call the above toll free line & leave your email to be removed. From remailer at aarg.net Sat Aug 3 10:55:19 2002 From: remailer at aarg.net (AARG! Anonymous) Date: Sat, 3 Aug 2002 10:55:19 -0700 Subject: Privacy-enhancing uses for TCPA Message-ID: Here are some alternative applications for TCPA/Palladium technology which could actually promote privacy and freedom. A few caveats, though: they do depend on a somewhat idealized view of the architecture. It may be that real hardware/software implementations are not sufficiently secure for some of these purposes, but as systems become better integrated and more technologically sound, this objection may go away. And these applications do assume that the architecture is implemented without secret backdoors or other intentional flaws, which might be guaranteed through an open design process and manufacturing inspections. Despite these limitations, hopefully these ideas will show that TCPA and Palladium actually have many more uses than the heavy-handed and control-oriented ones which have been discussed so far. To recap, there are basically two technologies involved. One is "secure attestation". This allows machines to securely receive a hash of the software which is running remotely. It is used in these examples to know that a trusted client program is running on the remote machine. The other is "secure storage". This allows programs to encrypt data in such a way that no other program can decrypt it. In addition, we assume that programs are able to run "unmolested"; that is, that other software and even the user cannot peek into the program's memory and manipulate it or learn its secrets. Palladium has a feature called "trusted space" which is supposed to be some special memory that is immune from being compromised. We also assume that all data sent between computers is encrypted using something like SSL, with the secret keys being held securely by the client software (hence unavailable to anyone else, including the users). The effect of these technologies is that a number of computers across the net, all running the same client software, can form their own closed virtual world. They can exchange and store data of any form, and no one can get access to it unless the client software permits it. That means that the user, eavesdroppers, and authorities are unable to learn the secrets protected by software which uses these TCPA features. (Note, in the sequel I will just write TCPA when I mean TCPA/Palladium.) Now for a simple example of what can be done: a distributed poker game. Of course there are a number of crypto protocols for playing poker on the net, but they are quite complicated. Even though they've been around for almost 20 years, I've never seen game software which uses them. With TCPA we can do it trivially. Each person runs the same client software, which fact can be tested using secure attestation. The dealer's software randomizes a deck and passes out the cards to each player. The cards are just strings like "ace of spades", or perhaps simple numerical equivalents - nothing fancy. Of course, the dealer's software learns in this way what cards every player has. But the dealer himself (i.e. the human player) doesn't see any of that, he only sees his own hand. The software keeps the information secret from the user. As each person makes his play, his software sends simple messages telling what cards he is exposing or discarding, etc. At the end each person sends messages showing what his hand is, according to the rules of poker. This is a trivial program. You could do it in one or two pages of code. And yet, given the TCPA assumptions, it is just as secure as a complex cryptographically protected version would be that takes ten times as much code. Of course, without TCPA such a program would never work. Someone would write a cheating client which would tell them what everyone else's cards were when they were the dealer. There would be no way that people could trust each other not to do this. But TCPA lets people prove to each other that they are running the legitimate client. So this is a simple example of how the secure attestation features of TCPA/Palladium can allow a kind of software which would never work today, software where people trust each other. Let's look at another example, a P2P system with anonymity. Again, there are many cryptographic systems in the literature for anonymous communication. But they tend to be complicated and inefficient. With TCPA we only need to set up a simple flooding broadcast network. Let each peer connect to a few other peers. To prevent traffic analysis, keep each node-to-node link at a constant traffic level using dummy padding. (Recall that each link is encrypted using SSL.) When someone sends data, it gets sent everywhere via a simple routing strategy. The software then makes the received message available to the local user, if he is the recipient. Possibly the source of the message is carried along with it, to help with routing; but this information is never leaked outside the secure communications part of the software, and never shown to any users. That's all there is to it. Just send messages with flood broadcasts, but keep the source locked inside the secure part. Messages can be sent and received, and neither participants nor outsiders can tell what the source of any message is. As with the earlier example, such a system would never work without TCPA. Rogue software would easily determine which direction messages were coming from, and the anonymity provided would be extremely limited at best. But by eliminating rogues using secure attestation, and keeping the sensitive data safe from molestation, we are able to achieve using a very simple system what otherwise takes tremendous complexity. Here's one more example, which I think is quite amazing: untraceable digital cash with full anonymity, without blinding or even any cryptography at all! (Excepting of course the standard TCPA pieces like SSL and secure storage and attestation.) The idea is, again, trivial. Making a withdrawal, the client sends the user's password and account ID to the bank (this information is kept in secure storage). The bank approves, and the client increments the local "wallet" by that amount (also kept in secure storage). To make a payment, use the anonymous network for transport, and just send a message telling how much is being paid! The recipient increments his wallet by that amount and the sender decrements his. Deposit works analogously to withdrawal. Again, that's all there is to it. Nothing could be simpler. Yet it provides for secure (assuming TCPA is secure), anonymous, untraceable payments. The secure attestation is crucial, of course, to make sure that people are running legitimate clients, otherwise cheating would be rampant. And the secure storage is equally crucial, otherwise any software could increment the sum stored in the wallet and everyone would accept and believe those payments. I understand, of course, that this specific example is not very practical unless we have an extremely secure version of TCPA. If anyone who can break the security can give themselves unlimited money, it means that the security has to be essentially perfect. So this is more of a proof of concept than a realistic proposal. But eventually, with TCPA technology integrated into a tamper-proof, nanotech CPU with molecular sensors and built-in self-destructs, possibly this might be good enough. Or you could augment this solution with some crypto, similar with the "wallets with observers" proposals from Chaum and from Brands. Note that we can make the client open-source, allowing anyone to verify that it has no back doors or cheating potentials, which allows all users to trust that it is not going to hurt them (a problem that takes great complexity to solve with the observer protocols). But still the bare simplicity of the system should make clear how powerful something like TCPA can be for this kind of application. I could go on and on, but the basic idea is always the same, and hopefully once people see the pattern they will come up with their own ideas. Being able to write software that trusts other computers allows for an entirely new approach to security software design. TCPA can enhance freedom and privacy by closing off possibilities for surveillance and interference. The same technology that protects Sony's music content in a DRM application can protect the data exchanged by a P2P system. As Seth Schoen of the EFF paraphrases Microsoft, "So the protection of privacy was the same technical problem as the protection of copyright, because in each case bits owned by one party were being entrusted to another party and there was an attempt to enforce a policy." (http://vitanuova.loyalty.org/2002-07-05.html, 3rd bullet point) In fact, TCPA and Palladium have tremendous potential for enhancing and protecting privacy, if people will just look at them with an open mind. From eugen at leitl.org Sat Aug 3 03:48:22 2002 From: eugen at leitl.org (Eugen Leitl) Date: Sat, 3 Aug 2002 12:48:22 +0200 (CEST) Subject: Challenge to David Wagner on TCPA In-Reply-To: <20020803102013.93930.qmail@web13208.mail.yahoo.com> Message-ID: On Sat, 3 Aug 2002, Morlock Elloi wrote: > Ah, the computers. Well, those that want computers will have them. > They may not be as cheap as today and there will not be as many of > them, but I think that all people *I* deal with will have them, so I > don't really care. Sure, people will have computers. However, if we merrily slide down the slippery slope the authentication might move into the network layer eventually. You will be on the network, yet you will be not on the network. One might be able to fab computers at small scale (FPGA, organic transistors via inkjet, whatever), but it will be tough to create global networks using just overlapping patches of wireless. Especially, if rogue wireless will be rather illegal. From rah at shipwright.com Sat Aug 3 10:04:17 2002 From: rah at shipwright.com (R. A. Hettinga) Date: Sat, 3 Aug 2002 13:04:17 -0400 Subject: Other uses of TCPA In-Reply-To: <3D4B9E02.3999.47D95C@localhost> References: <3d3cb71053e71de0b181ecd56b8ba3a2@dizum.com> <3D4B9E02.3999.47D95C@localhost> Message-ID: At 9:10 AM -0700 on 8/3/02, James A. Donald wrote: > I can only see one application for voluntary TCPA, and that is the > application it was designed to perform: Make it possible run > software or content which is encrypted so that it will only run on > one computer for one time period. Otherwise known as "book-entry to the eyeball", and the de-facto wet dream of WAVEoids since time-immemorial, or at least 1989 or so. It's a shame that these people haven't heard of Goedel or Heisenberg. Or Coase, for that matter. :-). Cheers, RAH Cheers, RAH -- ----------------- R. A. Hettinga The Internet Bearer Underwriting Corporation 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire' From jamesd at echeque.com Sat Aug 3 14:59:23 2002 From: jamesd at echeque.com (James A. Donald) Date: Sat, 3 Aug 2002 14:59:23 -0700 Subject: Other uses of TCPA In-Reply-To: <0626f6299522f410f701f0111d02e098@dizum.com> Message-ID: <3D4BEFCB.25952.23E653@localhost> -- James Donald writes: > > I can only see one application for voluntary TCPA, and that is > > the application it was designed to perform: Make it possible > > run software or content which is encrypted so that it will > > only run on one computer for one time period. On 3 Aug 2002 at 20:10, Nomen Nescio wrote: > You've said this a few times, and while it is a plausible goal > of the designers, I don't actually see this specific capability > in the TCPA spec, nor is it mentioned in the Palladium white > paper. Think about it. > For TCPA, you'd have to have the software as a blob which is > encrypted to some key that is locked in the TPM. But the > problem is that the endorsement key is never leaked except to > the Privacy CA .... (Lots of similarly untintellible stuff deleted) You have lost me, I have no idea why you think what you are talking about might be relevant to my assertion. The TPM has its own secret key, it makes the corresponding public key widely available to everyone, and its own internal good known time. So when your customer's payment goes through, you then send him a copy of your stuff encrypted to his TPM, a copy which only his TPM can make use of. Your code, which the TPM decrypts and executes, looks at the known good time, and if the user is out of time, refuses to play. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG 8QGEo4ptd7TD5d7duyz9XkOw+th0YEG9sllM8ix 2P2uZVncMpARxQd6P5V9cXLh97ZLpgi0tHH7LyVfB From dlsmin at email.de Sat Aug 3 00:10:54 2002 From: dlsmin at email.de (Cindy) Date: Sat, 03 Aug 2002 15:10:54 +0800 Subject: metting you Message-ID: Hi there lovely, This kind of opportunity comes ones in a life. I don't want tbao miss it. Do you? I aam comingb to your placae in few days and I though may bec we can meet each other. If you don't mind I can send you my picture. I am a girl. You can correspond with me using my email eelj at summerdayzz.com From morlockelloi at yahoo.com Sat Aug 3 15:12:11 2002 From: morlockelloi at yahoo.com (Morlock Elloi) Date: Sat, 3 Aug 2002 15:12:11 -0700 (PDT) Subject: Challenge to David Wagner on TCPA In-Reply-To: Message-ID: <20020803221211.62786.qmail@web13203.mail.yahoo.com> > One might be able to fab computers at small scale (FPGA, organic > transistors via inkjet, whatever), but it will be tough to create global > networks using just overlapping patches of wireless. Especially, if rogue > wireless will be rather illegal. UUCP will work as long as people can talk over telephone and there are modems available. The harder and more inconvenient it becomes to connect the higher average IQ of participants will be. There is hope. Just imagine the absence of short-attention span morons that find uucp too complicated. Ask around. ===== end (of original message) Y-a*h*o-o (yes, they scan for this) spam follows: Yahoo! Health - Feel better, live better http://health.yahoo.com From jays at panix.com Sat Aug 3 12:34:25 2002 From: jays at panix.com (Jay Sulzberger) Date: Sat, 3 Aug 2002 15:34:25 -0400 (EDT) Subject: Privacy-enhancing uses for TCPA In-Reply-To: Message-ID: On Sat, 3 Aug 2002, AARG!Anonymous wrote: < ... /> > Now for a simple example of what can be done: a distributed poker game. > Of course there are a number of crypto protocols for playing poker on the > net, but they are quite complicated. Even though they've been around > for almost 20 years, I've never seen game software which uses them. > With TCPA we can do it trivially. < ... /> No. Have you included the cost of giving every computer on Earth to the Englobulators? If you wish, we can write an implementation of the wonderful protocols for distributed safer card drawing and we can play our games of poker. And we may run our poker room on the hardware and software we have today, no need for DRM. Indeed today millions use toady's untrammeled hardware and, this is incredible, Microsoft OSes to conduct their personal banking. If "the market" considers that present systems suffice for this, well, I do not think that we need surrender our computers to the Englobulators to save three man-months of programmer time. ad next moves in the eristic tree: You: Marginals vs. total time-space integrated costs/benefits! I: Happy to demonstrate estimates of totals come out for my side. oo--JS. From remailer at aarg.net Sat Aug 3 18:25:28 2002 From: remailer at aarg.net (AARG! Anonymous) Date: Sat, 3 Aug 2002 18:25:28 -0700 Subject: Other uses of TCPA Message-ID: <5c42704f47b04baebb34cfdea142680a@aarg.net> James Donald writes: > James Donald writes: > > > I can only see one application for voluntary TCPA, and that is > > > the application it was designed to perform: Make it possible > > > run software or content which is encrypted so that it will > > > only run on one computer for one time period. > > On 3 Aug 2002 at 20:10, Nomen Nescio wrote: > > For TCPA, you'd have to have the software as a blob which is > > encrypted to some key that is locked in the TPM. But the > > problem is that the endorsement key is never leaked except to > > the Privacy CA .... > > (Lots of similarly untintellible stuff deleted) > > You have lost me, I have no idea why you think what you are > talking about might be relevant to my assertion. I'm sorry, I'm just using the language and data structures from TCPA to try to understand how your assertion could relate to it. If you are making a claim about TCPA, perhaps you could express it in terms of those specific features which are supported by TCPA. > The TPM has its own secret key, it makes the corresponding public > key widely available to everyone, and its own internal good known > time. No, the TPM public key is not widely available to everyone. In fact, believe it or not, it is a relatively closely held secret. This is because the public key is in effect a unique identifier like the Intel processor ID number, and we all know what a firestorm that caused. Intel is paranoid about being burned again, so they have created a very elaborate system in which the TPM's public key is exposed only as narrowly as possible. The TPM public key is called the Endorsement key - this is the key which is signed by the manufacturer and which proves that the TPM is a valid implementation of TCPA. Here is what section 9.2 of the TCPA spec says about it: : A TPM only has one asymmetric endorsement key pair. Due to the nature of : this key pair, both the public and private parts of the key have privacy : and security concerns. : : Exporting the PRIVEK from the TPM must not occur. This is for security : reasons. The PRIVEK is a decryption key and never performs any signature : operations. : : Exporting the public PUBEK from the TPM under controlled circumstances : is allowable. Access to the PUBEK must be restricted to entities that : have a "need to know." This is for privacy reasons. The PUBEK is the public part of the TPM key and is not supposed to be widely available. It is only for those who have a "need to know", which definitely does not include everyone who would like to send some software to the system. In fact, it is only sent to Privacy CAs, which use it to encrypt a cert on a transient key that will be widely exposed. But I'm sorry, I'm going unintelligible again, aren't I? Also, nothing in the TCPA standard refers to securely knowing the time. Section 10.7 says "There is no requirement for a clock function in the TPM", so the date/time info comes from the normal, insecure hardware clock. > So when your customer's payment goes through, you then > send him a copy of your stuff encrypted to his TPM, a copy which > only his TPM can make use of. Your code, which the TPM decrypts > and executes, looks at the known good time, and if the user is > out of time, refuses to play. Well, without using any jargon, I will only say that TCPA doesn't work like this, and if you don't believe me, you will have to read the spec and verify it for yourself. From remailer at aarg.net Sat Aug 3 18:30:09 2002 From: remailer at aarg.net (AARG! Anonymous) Date: Sat, 3 Aug 2002 18:30:09 -0700 Subject: Challenge to David Wagner on TCPA Message-ID: <3e42b974f015ac0f9fd5cad30f83526b@aarg.net> Mike Rosing wrote: > On Fri, 2 Aug 2002, AARG! Anonymous wrote: > > > You don't have to send your data to Intel, just a master storage key. > > This key encrypts the other keys which encrypt your data. Normally this > > master key never leaves your TPM, but there is this optional feature > > where it can be backed up, encrypted to the manufacturer's public key, > > for recovery purposes. I think it is also in blinded form. > > In other words, the manufacturer has access to all your data because > they have the master storage key. > > Why would everyone want to give one manufacturer that much power? It's not quite that bad. I mentioned the blinding. What happens is that before the master storage key is encrypted, it is XOR'd with a random value, which is also output by the TPM along with the encrypted recovery blob. You save them both, but only the encrypted blob gets sent to the manufacturer. So when the manufacturer decrypts the data, he doesn't learn your secrets. The system is cumbersome, but not an obvious security leak. From nobody at dizum.com Sat Aug 3 11:10:03 2002 From: nobody at dizum.com (Nomen Nescio) Date: Sat, 3 Aug 2002 20:10:03 +0200 (CEST) Subject: Other uses of TCPA Message-ID: <0626f6299522f410f701f0111d02e098@dizum.com> James Donald writes: > I can only see one application for voluntary TCPA, and that is the > application it was designed to perform: Make it possible run > software or content which is encrypted so that it will only run on > one computer for one time period. You've said this a few times, and while it is a plausible goal of the designers, I don't actually see this specific capability in the TCPA spec, nor is it mentioned in the Palladium white paper. For TCPA, you'd have to have the software as a blob which is encrypted to some key that is locked in the TPM. But the problem is that the endorsement key is never leaked except to the Privacy CA, so the content provider can't encrypt to that key. Then there are Identity keys which are short-term generated keys that get signed by the Privacy CA, but these are primarily used to prove that you are running a TCPA system. I'm not even sure if they are decryption keys. In any case they are supposed to be relatively transient. You get a new one each time you go online so that your web activities are not linkable. So I don't think Identity keys would be very suitable for locking software too, either. I admit that it would be unlikely for Microsoft to go to all the trouble of creating Palladium, without using it to solve its own severe software piracy problems. So I certainly wouldn't be surprised to see some way of achieving what you are talking about. But it is not mentioned in the white paper, and TCPA doesn't seem to support it very well. If it was, as you say, "the application it was designed to perform," this fact is far from apparent in the design documents. From contactspecial-wp080302-100258129 at box2.mysbec.com Sat Aug 3 19:13:20 2002 From: contactspecial-wp080302-100258129 at box2.mysbec.com (mysbec) Date: Sat, 03 Aug 2002 21:13:20 -0500 Subject: Win $200 FREE! Message-ID: <200208040121.UAA03081@einstein.ssz.com> A non-text attachment was scrubbed... Name: not available Type: text/html Size: 6665 bytes Desc: not available URL: From eresrch at eskimo.com Sat Aug 3 21:44:58 2002 From: eresrch at eskimo.com (Mike Rosing) Date: Sat, 3 Aug 2002 21:44:58 -0700 (PDT) Subject: Other uses of TCPA In-Reply-To: <5c42704f47b04baebb34cfdea142680a@aarg.net> Message-ID: On Sat, 3 Aug 2002, AARG! Anonymous wrote: > The TPM public key is called the Endorsement key - this is the key which > is signed by the manufacturer and which proves that the TPM is a valid > implementation of TCPA. Here is what section 9.2 of the TCPA spec says > about it: > > : A TPM only has one asymmetric endorsement key pair. Due to the nature of > : this key pair, both the public and private parts of the key have privacy > : and security concerns. > : > : Exporting the PRIVEK from the TPM must not occur. This is for security > : reasons. The PRIVEK is a decryption key and never performs any signature > : operations. > : > : Exporting the public PUBEK from the TPM under controlled circumstances > : is allowable. Access to the PUBEK must be restricted to entities that > : have a "need to know." This is for privacy reasons. And in another message: I said: => In other words, the manufacturer has access to all your data because => they have the master storage key. => => Why would everyone want to give one manufacturer that much power? AARGH! said: >It's not quite that bad. I mentioned the blinding. What happens is >that before the master storage key is encrypted, it is XOR'd with a >random value, which is also output by the TPM along with the encrypted >recovery blob. You save them both, but only the encrypted blob gets >sent to the manufacturer. So when the manufacturer decrypts the data, >he doesn't learn your secrets. > >The system is cumbersome, but not an obvious security leak. Who owns PRIVEK? Who controls PRIVEK? That's who own's TCPA. And then there was this comment in yet another message: >In addition, we assume that programs are able to run "unmolested"; >that is, that other software and even the user cannot peek into the >program's memory and manipulate it or learn its secrets. Palladium has >a feature called "trusted space" which is supposed to be some special >memory that is immune from being compromised. We also assume that >all data sent between computers is encrypted using something like SSL, >with the secret keys being held securely by the client software (hence >unavailable to anyone else, including the users). Just how "immune" is this program space? Does the operator/owner of the machine control it, or does the owner of PRIVEK control it? So the owner of PRIVEK can send a trojan into my machine and take it over anytime they want. Cool, kind of like the movie "Collosis" where a super computer takes over the world. The more I learn about TCPA, the more I don't like it. Patience, persistence, truth, Dr. mike From remailer at aarg.net Sat Aug 3 23:50:24 2002 From: remailer at aarg.net (AARG! Anonymous) Date: Sat, 3 Aug 2002 23:50:24 -0700 Subject: Other uses of TCPA Message-ID: Mike Rosing wrote: > Who owns PRIVEK? Who controls PRIVEK? That's who own's TCPA. PRIVEK, the TPM's private key, is generated on-chip. It never leaves the chip. No one ever learns its value. Given this fact, who would you say owns and controls it? > And then there was this comment in yet another message: > > >In addition, we assume that programs are able to run "unmolested"; > >that is, that other software and even the user cannot peek into the > >program's memory and manipulate it or learn its secrets. Palladium has > >a feature called "trusted space" which is supposed to be some special > >memory that is immune from being compromised. We also assume that > >all data sent between computers is encrypted using something like SSL, > >with the secret keys being held securely by the client software (hence > >unavailable to anyone else, including the users). > > Just how "immune" is this program space? Does the operator/owner of > the machine control it, or does the owner of PRIVEK control it? Not much information is provided about this feature in the Palladium white paper. From what I understand, no one is able to manipulate the program when it is in this trusted space, not the machine owner, nor any external party. Only the program is in control. > So > the owner of PRIVEK can send a trojan into my machine and take it over > anytime they want. Cool, kind of like the movie "Collosis" where a > super computer takes over the world. No, for several reasons. First, PRIVEK doesn't really have an owner in the sense you mean. It is more like an autonomous agent. Second, the PRIVEK stuff is part of the TCPA spec, while the trusted space is from Palladium, and they don't seem to have much to do with each other. And last, just because a program can run without interference, it is a huge leap to infer that anyone can put a trojan onto your machine. > The more I learn about TCPA, the more I don't like it. No one has said anything different despite the 40+ messages I have sent on this topic. Is this because TCPA is that bad, or is it because everyone is stubborn? Look, I just showed that all these bad things you thought about TCPA were wrong. The PRIVEK is not controlled by someone else, it does not own the trusted space, and it allows no one to put a trojan onto your machine. But you won't now say that TCPA is OK, will you? You just learned some information which objectively should make you feel less bad about it, and yet you either don't feel that way, or you won't admit it. I am coming to doubt that people's feelings and beliefs about TCPA are based on facts at all. No matter how much I correct negative misconceptions about these systems, no one will admit to having any more positive feelings about it. From eknot30 at excite.com Sat Aug 3 15:55:09 2002 From: eknot30 at excite.com (eknot30 at excite.com) Date: Sun, 04 Aug 2002 03:55:09 +0500 Subject: Create a PAYCHECK with your computer Message-ID: <002b33c54a4e$3251c0c8$3ac84cb4@sxpmmt> A non-text attachment was scrubbed... Name: not available Type: text/html Size: 10531 bytes Desc: not available URL: From mortgage4u146 at aol.com Sun Aug 4 15:32:52 2002 From: mortgage4u146 at aol.com (RODOLFO) Date: Sun, 04 Aug 2002 04:32:52 -1800 Subject: get the lowest mortgage rate available B Message-ID: <00005f8c6073$000070c3$00006a99@mailin-02.mx.aol.com> Make a note of Dare to Compare! Do you have the LOWEST Mortgage rate available? * Compare our rates. * No obligation. * Search hundreds of lenders instantly. * Free qoutes. * ALL Credit Accepted. A,B and subprime! One thing we all know, rates won't stay this low forever. Search now: http://T92trwC5qt at mortgage-tree.com/ml.htm Unlist; http://T9QyaeNX3J at mortgage-tree.com/ml.htm From mv at cdc.gov Sun Aug 4 07:39:12 2002 From: mv at cdc.gov (Major Variola (ret)) Date: Sun, 04 Aug 2002 07:39:12 -0700 Subject: Simmering frogs with a drop of technology and a dash of law Message-ID: <3D4D3C90.1406E54@cdc.gov> At 12:48 PM 8/3/02 +0200, Eugen Leitl wrote: >On Sat, 3 Aug 2002, Morlock Elloi wrote: > >> Ah, the computers. Well, those that want computers will have them. >> They may not be as cheap as today and there will not be as many of >> them, but I think that all people *I* deal with will have them, so I >> don't really care. > >Sure, people will have computers. However, if we merrily slide down the >slippery slope the authentication might move into the network layer >eventually. You will be on the network, yet you will be not on the >network. Yes. As engineers we can design a system, enforced by Law only at the ISP, which makes the network usable only to those using Approved hardware/software. Try it. Then take a bath --the stench does come off. But surely the heavy hand of the Law will be required? No. This can be done with minimal *apparent* police state feeling, by attacking central communication resources. Don't think so? How about CALEA, Carnivore, etc. In the 1984+20 world, you can use your old 56K modem for point to point communications (over the message-neutral POTS) but you can't use your ISP without running Approved 'Secure Fnord Trusted' equiptment. Your ISP's assets will be seized if they route unVerified traffic from their 'subscribers'. This meets the Specs For Gentle Fascism: it requires some plausible tech, and some plausible law. No Stasi needed, just the power of Customs, IRS and business licensing. So you can distribute your xeroxed pamphlets by hand, but you can't mail them because the State runs the post, and controls the private delivery services. Most folks don't notice because they use State-Approved pens which only let them write Approved thoughts and certainly don't let them copy large excerpts of others' prose. Those 'safe' messages are transparently handled by the State post. Its great that Morloch can make pens from quills, and has a horse to carry his letters to his friends ---who have to use homemade, not State approved, candles to read them. But Morloch's consumption of goose feathers has not gone unnoticed... --- \begin{bumpersticker} Keep Your Laws Off My Machine No Stego No Freedom No Shit \end{bumpersticker} From vinnie at vmeng.com Sun Aug 4 09:14:53 2002 From: vinnie at vmeng.com (Vinnie Moscaritolo) Date: Sun, 4 Aug 2002 09:14:53 -0700 Subject: Apple's Security Update Message Fails PGP Authentication In-Reply-To: References: Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 yes, I did sign their key, Apple generated a new key and didn't sign it with the old one or have anyone continue it's trust path.. It would be a good thing if someone else signed it and sent notice to Product Security , you can contact them there and ask them to verify the fingerprint or use their website.. either way, isn't it funny that they use a PGP key to verify their security updates and yet with all the CDSA code they have on X, none of it supports the PGP key infrastucture. actually I am not sure what the Security framework is used for, I suspect encrypting passwords on keychain and now System update.. but not ssh/scp or mail.app. too bad. -----BEGIN PGP SIGNATURE----- Version: PGP 7.5 iQA/AwUBPU1S89ixAAkLPvBCEQKibgCg9DmZJt4cNsQtgXLHEtvnJT2ZW3YAoNFO sFVWo7a5peL7W8//5HSXRVAG =86oB -----END PGP SIGNATURE----- At 10:05 AM -0400 8/3/02, R. A. Hettinga wrote: >--- begin forwarded text > > >Status: RO >Delivered-To: mac_crypto at vmeng.com >To: mac_crypto at vmeng.com >From: Fearghas McKay >Subject: [Mac_crypto] "Security Update 2002-08-02 for OpenSSL, Sun RPC, >mod_ssl" does > not verify >Sender: mac_crypto-admin at vmeng.com >Date: Sat, 3 Aug 2002 08:38:50 +0100 > >**A verification of this security announcement mail fails** > >The key is signed by Vinnie Moscaritolo - vinnie at vmeng.com which is a good >thing even if Vinnie is no longer at Apple ( which is a bad thing ), it is >also signed by someone who does not appear on any of the public keyservers >that I can find which is a bit disappointing. > >Verified version is at the bottom. > > f > >--- begin forwarded text > -- Vinnie Moscaritolo ITCB-IMSH PGP: 3F903472C3AF622D5D918D9BD8B100090B3EF042 ------------------------------------------------------- From d_kar27 at post.com Sun Aug 4 00:24:32 2002 From: d_kar27 at post.com (David Kargbou) Date: Sun, 4 Aug 2002 09:24:32 +0200 Subject: DANIEL KARGBO. cypherpunks ! Message-ID: <200208040724.g747OSR30131@waste.minder.net> cypherpunks , From;Mr.David Kargbou and Family, Johannesburg,South Africa. My Dear , Good day.This very confidential request should come as a surprise to you.But it is because of the nature of what is happening to me and my family urged me to contact you, and I quite understand that this is not the best way to contact you because of the nature of my request and the attention it requires.I got your contact information from your country's information directory during my desperate search for someone who can assist me secretly and confidentially in relocating and managing some family fortunes. My name is Mr.David Kargbou,the second son of Mr.Smith Thabo Kargbou,of Beitbridge Zimbabwe.At the height of the present political crises in our country,in which the white farmers in our country are being slained and ripped off their belongings by the supporters of our president,Mr.Robert G.Mugabe,in their efforts to reclaim all the white owned farms in our country,my father and my elder brother were brutally slained to a painful death on the 13th of february,2002, in their struggle to protect some white farmers who ran to take refuge in our house.My father,during his life on earth was a prominent business man who trades on diamond and gold from some foreign countries .He publicly opposes the crude policies and crime against humanity on the white farmers by Mr.Robert Mugabe and his followers,which they enforced media law restrictions to protect their wicked acts.That not being enough,the president and his followers after winning the last undemocratic elections decided to bl! ock and confiscate all accounts and assets of our black indigenes[that included my fathers assets and accounts] who oppose his policies and render support to these white farmers,along with the assets of these white farmers themselves,that are being presently confiscated.I therefore decided to move my mother and younger sister to the Republic of South Africa,where we presently live without anything and without any source of livelyhood. During my fathers life on earth,he had deposited the sum of Seven Million and Four Hundred Thousand United States Dollars[$7.400.000.00]in a Trunk box with a Finance and Security Company in the Republic of Togo for a cash and carry Diamond and Gold business with some foreign business customers, awaiting instructions to be moved to its destination,which he never completed before he met his untimely death on that faithful day.In view of this and as the only surviving son of my father,and with the present clamp down,killing and confiscation of his assets as one of those who render support to the white farmers in our country,I therefore humbly wish to inform you of my intentions to use your name and adress in making sure that this fund is lifted out of Africa finally,to the Europe office of the finance company and also seek for your honest and trustworthy assistance to help me clear and accommodate this money over there before it is dictated out and blocked by the present Mugabe! 's regime.My mother is presently with the valid document covering this deposit. Now this is what I actually want you to do for me; 1. I want you to be presented to the Finance and Security company as the person I contacted to assist my family for this purpose, with whose name and adress myself and my mother will forward to them their office in the Republic of Togo as the person that will clear this money when they lift it out to their europe office. 2. To finally assist me in accommodating and managing this money in any lucrative business in your country for at least three years. Please,I hope you will grant and view this very request with favour and much understanding of our situation now,and will be a very honest and reliable person to deal with.And also bearing in mind the confidential nature of this my request,I emphasize please that you keep every bit of it to yourself so as to protect my familys future and yourself rendering this help.Thanking you in anticipation of your urgent response as soon as you read this very request. Best Regards, Mr.David Kargbou and family. From d_kar29 at post.com Sun Aug 4 00:54:52 2002 From: d_kar29 at post.com (David Kargbou) Date: Sun, 4 Aug 2002 09:54:52 +0200 Subject: DANIEL KARGBO. cypherpunks ! Message-ID: <200208040659.BAB11654@einstein.ssz.com> cypherpunks , From;Mr.David Kargbou and Family, Johannesburg,South Africa. My Dear , Good day.This very confidential request should come as a surprise to you.But it is because of the nature of what is happening to me and my family urged me to contact you, and I quite understand that this is not the best way to contact you because of the nature of my request and the attention it requires.I got your contact information from your country's information directory during my desperate search for someone who can assist me secretly and confidentially in relocating and managing some family fortunes. My name is Mr.David Kargbou,the second son of Mr.Smith Thabo Kargbou,of Beitbridge Zimbabwe.At the height of the present political crises in our country,in which the white farmers in our country are being slained and ripped off their belongings by the supporters of our president,Mr.Robert G.Mugabe,in their efforts to reclaim all the white owned farms in our country,my father and my elder brother were brutally slained to a painful death on the 13th of february,2002, in their struggle to protect some white farmers who ran to take refuge in our house.My father,during his life on earth was a prominent business man who trades on diamond and gold from some foreign countries .He publicly opposes the crude policies and crime against humanity on the white farmers by Mr.Robert Mugabe and his followers,which they enforced media law restrictions to protect their wicked acts.That not being enough,the president and his followers after winning the last undemocratic elections decided to bl! oc! k and confiscate all accounts and assets of our black indigenes[that included my fathers assets and accounts] who oppose his policies and render support to these white farmers,along with the assets of these white farmers themselves,that are being presently confiscated.I therefore decided to move my mother and younger sister to the Republic of South Africa,where we presently live without anything and without any source of livelyhood. During my fathers life on earth,he had deposited the sum of Seven Million and Four Hundred Thousand United States Dollars[$7.400.000.00]in a Trunk box with a Finance and Security Company in the Republic of Togo for a cash and carry Diamond and Gold business with some foreign business customers, awaiting instructions to be moved to its destination,which he never completed before he met his untimely death on that faithful day.In view of this and as the only surviving son of my father,and with the present clamp down,killing and confiscation of his assets as one of those who render support to the white farmers in our country,I therefore humbly wish to inform you of my intentions to use your name and adress in making sure that this fund is lifted out of Africa finally,to the Europe office of the finance company and also seek for your honest and trustworthy assistance to help me clear and accommodate this money over there before it is dictated out and blocked by the present Mugabe! 's! regime.My mother is presently with the valid document covering this deposit. Now this is what I actually want you to do for me; 1. I want you to be presented to the Finance and Security company as the person I contacted to assist my family for this purpose, with whose name and adress myself and my mother will forward to them their office in the Republic of Togo as the person that will clear this money when they lift it out to their europe office. 2. To finally assist me in accommodating and managing this money in any lucrative business in your country for at least three years. Please,I hope you will grant and view this very request with favour and much understanding of our situation now,and will be a very honest and reliable person to deal with.And also bearing in mind the confidential nature of this my request,I emphasize please that you keep every bit of it to yourself so as to protect my familys future and yourself rendering this help.Thanking you in anticipation of your urgent response as soon as you read this very request. Best Regards, Mr.David Kargbou and family. From d_kar29 at post.com Sun Aug 4 00:54:54 2002 From: d_kar29 at post.com (David Kargbou) Date: Sun, 4 Aug 2002 09:54:54 +0200 Subject: DANIEL KARGBO. cypherpunks ! Message-ID: <200208040659.BAA11656@einstein.ssz.com> cypherpunks , From;Mr.David Kargbou and Family, Johannesburg,South Africa. My Dear , Good day.This very confidential request should come as a surprise to you.But it is because of the nature of what is happening to me and my family urged me to contact you, and I quite understand that this is not the best way to contact you because of the nature of my request and the attention it requires.I got your contact information from your country's information directory during my desperate search for someone who can assist me secretly and confidentially in relocating and managing some family fortunes. My name is Mr.David Kargbou,the second son of Mr.Smith Thabo Kargbou,of Beitbridge Zimbabwe.At the height of the present political crises in our country,in which the white farmers in our country are being slained and ripped off their belongings by the supporters of our president,Mr.Robert G.Mugabe,in their efforts to reclaim all the white owned farms in our country,my father and my elder brother were brutally slained to a painful death on the 13th of february,2002, in their struggle to protect some white farmers who ran to take refuge in our house.My father,during his life on earth was a prominent business man who trades on diamond and gold from some foreign countries .He publicly opposes the crude policies and crime against humanity on the white farmers by Mr.Robert Mugabe and his followers,which they enforced media law restrictions to protect their wicked acts.That not being enough,the president and his followers after winning the last undemocratic elections decided to bl! oc! k and confiscate all accounts and assets of our black indigenes[that included my fathers assets and accounts] who oppose his policies and render support to these white farmers,along with the assets of these white farmers themselves,that are being presently confiscated.I therefore decided to move my mother and younger sister to the Republic of South Africa,where we presently live without anything and without any source of livelyhood. During my fathers life on earth,he had deposited the sum of Seven Million and Four Hundred Thousand United States Dollars[$7.400.000.00]in a Trunk box with a Finance and Security Company in the Republic of Togo for a cash and carry Diamond and Gold business with some foreign business customers, awaiting instructions to be moved to its destination,which he never completed before he met his untimely death on that faithful day.In view of this and as the only surviving son of my father,and with the present clamp down,killing and confiscation of his assets as one of those who render support to the white farmers in our country,I therefore humbly wish to inform you of my intentions to use your name and adress in making sure that this fund is lifted out of Africa finally,to the Europe office of the finance company and also seek for your honest and trustworthy assistance to help me clear and accommodate this money over there before it is dictated out and blocked by the present Mugabe! 's! regime.My mother is presently with the valid document covering this deposit. Now this is what I actually want you to do for me; 1. I want you to be presented to the Finance and Security company as the person I contacted to assist my family for this purpose, with whose name and adress myself and my mother will forward to them their office in the Republic of Togo as the person that will clear this money when they lift it out to their europe office. 2. To finally assist me in accommodating and managing this money in any lucrative business in your country for at least three years. Please,I hope you will grant and view this very request with favour and much understanding of our situation now,and will be a very honest and reliable person to deal with.And also bearing in mind the confidential nature of this my request,I emphasize please that you keep every bit of it to yourself so as to protect my familys future and yourself rendering this help.Thanking you in anticipation of your urgent response as soon as you read this very request. Best Regards, Mr.David Kargbou and family. From roy at sendai.scytale.com Sun Aug 4 08:06:33 2002 From: roy at sendai.scytale.com (Roy M.Silvernail) Date: Sun, 4 Aug 2002 10:06:33 -0500 Subject: Challenge to David Wagner on TCPA In-Reply-To: <20020803221211.62786.qmail@web13203.mail.yahoo.com> References: <20020803221211.62786.qmail@web13203.mail.yahoo.com> Message-ID: <02080410063300.07228@sendai.scytale.com> On Saturday 03 August 2002 05:12 pm, Morlock Elloi wrote: > UUCP will work as long as people can talk over telephone and there are > modems available. The harder and more inconvenient it becomes to connect > the higher average IQ of participants will be. > > There is hope. > > Just imagine the absence of short-attention span morons that find uucp too > complicated. Ask around. But if WorldCom disolves in bankruptcy, will UUNet still be the center of the bang-path universe? More seriously, I think many of us old-timers long for the time when a certain level of wizardry was required to get on the net. (before Prodigy and the September that Never Ended) -- Roy M. Silvernail [ ] roy at scytale.com (formerly uunet!comcon!cybrspc!roy) DNRC Minister Plenipotentiary of All Things Confusing, Software Division PGP Key 0x1AF39331 : 71D5 2EA2 4C27 D569 D96B BD40 D926 C05E Key available from pubkey at scytale.com I charge to process unsolicited commercial email From eugen at leitl.org Sun Aug 4 02:54:14 2002 From: eugen at leitl.org (Eugen Leitl) Date: Sun, 4 Aug 2002 11:54:14 +0200 (CEST) Subject: Other uses of TCPA In-Reply-To: <3D4BEFCB.25952.23E653@localhost> Message-ID: On Sat, 3 Aug 2002, James A. Donald wrote: > The TPM has its own secret key, it makes the corresponding public > key widely available to everyone, and its own internal good known > time. So when your customer's payment goes through, you then Trusted time is a useful concept. I presume the time is set by the manufacturer. Given current clock accuracy and limited lifetime of backup power I presume it is possible to adjust the time via trusted timeservers. Do they mention anything like this in the specs? > send him a copy of your stuff encrypted to his TPM, a copy which > only his TPM can make use of. Your code, which the TPM decrypts > and executes, looks at the known good time, and if the user is > out of time, refuses to play. Is there any reason to believe the implementers are telling us everything, and will implement the specs as advertised? I mean, consider the source. Sometimes it makes sense to look a gift horse in the mouth, especially if it's made from wood. From eugen at leitl.org Sun Aug 4 03:29:58 2002 From: eugen at leitl.org (Eugen Leitl) Date: Sun, 4 Aug 2002 12:29:58 +0200 (CEST) Subject: Other uses of TCPA In-Reply-To: Message-ID: On Sat, 3 Aug 2002, AARG! Anonymous wrote: > But you won't now say that TCPA is OK, will you? You just learned > some information which objectively should make you feel less bad about > it, and yet you either don't feel that way, or you won't admit it. I > am coming to doubt that people's feelings and beliefs about TCPA are > based on facts at all. No matter how much I correct negative > misconceptions about these systems, no one will admit to having any > more positive feelings about it. Whoa there. Hold the horses. You're completely inverting the burden of proof here. You're *trusting* a preliminary spec fielded by *whom* again? Were you on the design team? Are you on implementers' team? Have you reverse engineered the function from tracing the structures on the die? Will you continue doing this, sampling every batch being shipped? Consider the source. It is bogged down with enough bad mana to last for centuries. Consider the motivations. They're certainly not there to enhance end user's privacy and anonymitity. In fact, one of the design specs must have been minimizing the latter as long as it not hurts the prime design incentives. These are all facts you won't find in the specs. It boggles my mind I have to explain this, especially to a member of this particular community. Are you really sure you're not a TCPA troll? If they manage to slip that particular toad into high volume production, hackers will of course use it, inasmuch possible thwarting the original intent. But you seem to ask for blanket endorsement based merely on spec, which is a rather tall order. From remailer at aarg.net Sun Aug 4 14:30:14 2002 From: remailer at aarg.net (AARG! Anonymous) Date: Sun, 4 Aug 2002 14:30:14 -0700 Subject: Other uses of TCPA Message-ID: Eugen Leitl writes: > On Sat, 3 Aug 2002, AARG! Anonymous wrote: > > > But you won't now say that TCPA is OK, will you? You just learned > > some information which objectively should make you feel less bad about > > it, and yet you either don't feel that way, or you won't admit it. I > > am coming to doubt that people's feelings and beliefs about TCPA are > > based on facts at all. No matter how much I correct negative > > misconceptions about these systems, no one will admit to having any > > more positive feelings about it. > > Whoa there. Hold the horses. You're completely inverting the burden of > proof here. You're *trusting* a preliminary spec fielded by *whom* again? > Were you on the design team? Are you on implementers' team? Have you > reverse engineered the function from tracing the structures on the die? > Will you continue doing this, sampling every batch being shipped? I am judging the proposal on the basis of the spec. I think that is the correct way to do the analysis. Then, you can extend your analysis on the basis of ways you think the spec might change. But surely the spec ought to be a starting point for any judgement. Otherwise there is no factual basis for the analysis. Yet no one here has said that now that they understand the spec better, they don't think TCPA as specified would be as bad as they thought. Some people, like James Donald and Ryan Lackey, have said that they don't think TCPA would be all that bad if it weren't for government, copyright laws, etc. But no one has suggested that my many postings have changed their opinion about TCPA in and of itself. > Consider the source. It is bogged down with enough bad mana to last for > centuries. The Alliance consists of Compaq, Intel, IBM, HP, and Microsoft. (Since then HP has bought Compaq.) Even if you hate Microsoft, you probably don't hate all of these companies, do you? > Consider the motivations. They're certainly not there to > enhance end user's privacy and anonymitity. In fact, one of the design > specs must have been minimizing the latter as long as it not hurts the > prime design incentives. These are all facts you won't find in the specs. I think the spec directly contradicts this claim! If they cared so little about user privacy, why would they use an elaborate system with a Privacy CA to make sure no user-identifiable information leaks onto the net? Surely the simpler approach would be what James Donald suggested, to send out the TPM's public key and let people use that. But it is a per-user identifier and so they went to great lengths to conceal it. Furthermore, if their motivations were so bad, wouldn't it have been better for them for TCPA to work the way most people assume, to only load software which has been signed by some authority? Instead they are careful to let any software load, and to report its status to third parties, so the third parties can make their own judgements about what to trust. Why do you think they did it like this, if they were so determined to minimize the control of the end user? > It boggles my mind I have to explain this, especially to a member of this > particular community. Are you really sure you're not a TCPA troll? Who cares what I am? It's facts that count! I could be Satan Incarnate and it wouldn't matter. I am giving you facts about TCPA based on my personal investment of time to study the system. Tell me this: if you care about this standard, why not get it and learn it yourself? Not one person here has done this! Everyone prefers to believe falsehoods than to learn the truth for themself. Do you think that is a good strategy for survival in a potentially hostile and dangerous world? > If they manage to slip that particular toad into high volume production, > hackers will of course use it, inasmuch possible thwarting the original > intent. But you seem to ask for blanket endorsement based merely on spec, > which is a rather tall order. All I am really asking for is someone to acknowledge that I have provided information to them which makes them see TCPA as less dangerous and damaging than they had thought based on the false information which has been circulating. I don't see how anyone can deny this. The caricature of TCPA that most people believe is very bad. The truth is not so bad. Logically, you *have* to believe that TCPA is not as bad as you thought, when you are provided with the truth. Let me ask you, Eugen: isn't a TCPA which is open, which will run all software, which does not prevent any software from running, better than a TCPA which will only run signed software? I know you are a person who is willing to think for himself and defy the conventional wisdom. Please respond to this message and explain to me how this logic strikes you. From eresrch at eskimo.com Sun Aug 4 19:38:37 2002 From: eresrch at eskimo.com (Mike Rosing) Date: Sun, 4 Aug 2002 19:38:37 -0700 (PDT) Subject: Other uses of TCPA In-Reply-To: Message-ID: On Sun, 4 Aug 2002, AARG! Anonymous wrote: > Eugen Leitl writes: > > > On Sat, 3 Aug 2002, AARG! Anonymous wrote: > > > > > But you won't now say that TCPA is OK, will you? You just learned > > > some information which objectively should make you feel less bad about > > > it, and yet you either don't feel that way, or you won't admit it. I > > > am coming to doubt that people's feelings and beliefs about TCPA are > > > based on facts at all. No matter how much I correct negative > > > misconceptions about these systems, no one will admit to having any > > > more positive feelings about it. > > > > Whoa there. Hold the horses. You're completely inverting the burden of > > proof here. You're *trusting* a preliminary spec fielded by *whom* again? > > Were you on the design team? Are you on implementers' team? Have you > > reverse engineered the function from tracing the structures on the die? > > Will you continue doing this, sampling every batch being shipped? Whoa there is right! Yes, you are definitly educating me. Thank you. I am now totally confused on a lot of issues. So far, you have moved me from thinking TCPA seems like it might be useful to thinking that it's pretty monstrous. If you want to be a good teacher, you will have some patience. If you are a troll, you will get frustrated and leave soon. > I am judging the proposal on the basis of the spec. I think that is the > correct way to do the analysis. Then, you can extend your analysis on > the basis of ways you think the spec might change. But surely the spec > ought to be a starting point for any judgement. Otherwise there is no > factual basis for the analysis. Agreed. > Yet no one here has said that now that they understand the spec better, > they don't think TCPA as specified would be as bad as they thought. > Some people, like James Donald and Ryan Lackey, have said that they > don't think TCPA would be all that bad if it weren't for government, > copyright laws, etc. But no one has suggested that my many postings > have changed their opinion about TCPA in and of itself. Maybe that's because I'm not convinced yet. I've got a thick skull :-) > The Alliance consists of Compaq, Intel, IBM, HP, and Microsoft. > (Since then HP has bought Compaq.) Even if you hate Microsoft, you > probably don't hate all of these companies, do you? Hate is too strong a word. They aren't evil because they want to be, but because they have to be. They won't survive if they don't optimize society to their advantage. > I think the spec directly contradicts this claim! If they cared so little > about user privacy, why would they use an elaborate system with a Privacy > CA to make sure no user-identifiable information leaks onto the net? > Surely the simpler approach would be what James Donald suggested, to send > out the TPM's public key and let people use that. But it is a per-user > identifier and so they went to great lengths to conceal it. It creates a single point of attack. It reminds me of key escrow. Once you get to the chewy center, you can control everything. More questions below. > Furthermore, if their motivations were so bad, wouldn't it have been > better for them for TCPA to work the way most people assume, to only > load software which has been signed by some authority? Instead they > are careful to let any software load, and to report its status to third > parties, so the third parties can make their own judgements about what > to trust. Why do you think they did it like this, if they were so > determined to minimize the control of the end user? Because it's hard to think about everything. Maybe they didn't finish thinking all the ramifications through. I would hope we'll be able to ask enough questions that you'll have a hard time quoting the spec. > Who cares what I am? It's facts that count! I could be Satan Incarnate > and it wouldn't matter. I am giving you facts about TCPA based on my > personal investment of time to study the system. Tell me this: if you > care about this standard, why not get it and learn it yourself? Not one > person here has done this! Everyone prefers to believe falsehoods than > to learn the truth for themself. Do you think that is a good strategy > for survival in a potentially hostile and dangerous world? Not in a democracy. All laws are based on belief. They have nothing to do with facts. Facts get in the way and are far too confusing for a majority of humans. While understanding the facts is useful to anyone who wants real power, you can still accomplish a lot in the short run with a good lie. But I would like to understand TCPA enough that I can tell which newspaper article is the lie and which isn't. > All I am really asking for is someone to acknowledge that I have provided > information to them which makes them see TCPA as less dangerous and > damaging than they had thought based on the false information which has > been circulating. I don't see how anyone can deny this. The caricature > of TCPA that most people believe is very bad. The truth is not so bad. > Logically, you *have* to believe that TCPA is not as bad as you thought, > when you are provided with the truth. Well I deny it. So far, I am still confused and amazed at how powerful a device you have described. >From a different message- :Date: Sat, 3 Aug 2002 23:50:24 -0700 :From: AARG! Anonymous :To: cypherpunks at lne.com :Subject: Re: Other uses of TCPA : :Mike Rosing wrote: :> Who owns PRIVEK? Who controls PRIVEK? That's who own's TCPA. : :PRIVEK, the TPM's private key, is generated on-chip. It never leaves :the chip. No one ever learns its value. Given this fact, who would :you say owns and controls it? OK, so why can't any joe hacker create their own PRIVEK? _nobody_ knows it's value? Then how can anyone know if a chip is "real" or "imitation". What happens when the motherboard dies again? PRIVEK was copied out of the chip to some "fob" right? I thought you said the manufacturer put the keys in at the factory. I'm confused dude, straighten me out. Patience, persistence, truth, Dr. mike From remailer at aarg.net Sun Aug 4 22:30:14 2002 From: remailer at aarg.net (AARG! Anonymous) Date: Sun, 4 Aug 2002 22:30:14 -0700 Subject: Other uses of TCPA Message-ID: <97ae2010fd503056b22ed1e86cdc0853@aarg.net> Mike Rosing wrote: > :Mike Rosing wrote: > :> Who owns PRIVEK? Who controls PRIVEK? That's who own's TCPA. > : > :PRIVEK, the TPM's private key, is generated on-chip. It never leaves > :the chip. No one ever learns its value. Given this fact, who would > :you say owns and controls it? > > OK, so why can't any joe hacker create their own PRIVEK? _nobody_ knows > it's value? Then how can anyone know if a chip is "real" or "imitation". > What happens when the motherboard dies again? PRIVEK was copied out of > the chip to some "fob" right? I thought you said the manufacturer put > the keys in at the factory. Maybe I wasn't too clear in my explanation. I assume you know how public key cryptography works. The TPM chip generates an RSA key pair. This key pair is called the Endorsement Key. The private key is called PRIVEK and never leaves the chip. The public key is called PUBEK and although it is "sensitive", it does leave the chip under some circumstances. One of those circumstances is when the chip is manufactured and comes off the line. It is powered up, generates the key pair, and exports PUBEK. At that point the chip manufacturer creates an X.509 certificate that signs PUBEK. It is this cert which proves that the PUBEK is a legitimate Endorsement Key. While the cert is not widely shown (for privacy reasons), it is used in a TCPA protocol, and this is ultimately what makes it impossible for Joe Hacker to create a fake TCPA key. Now, the part about recovering from a dead chip refers to a different key. It's called the "root of trust for storage" key, RTS. This is used for encrypting data on the disk. The PUBEK was used for communicating with third parties to prove that you had a legitimate TPM. So there are two different keys used for two different purposes. Both of them are generated on-chip, and no one ever learns either private key. If your chip dies, you lose the PUBEK but that doesn't matter, nothing is really locked to it. You can just get a new motherboard and start using the new PUBEK from that one's TPM chip. It's the RTS key that is a problem, because if you can't retrieve that, all the data on your disk that was sealed (encrypted) using the TCPA mechanisms could be lost. So they have a system to transfer the RTS key from one machine to another. I've been thinking about writing a few pages summarizing TCPA and how the crypto works, but then I think, why bother? Everyone is already convinced that the system is the spawn of Satan. Nobody cares about the facts. BTW I found a post by Ross Anderson, http://www.chiark.greenend.org.uk/pipermail/ukcrypto/2002-June/019463.html, in which he says that one of the worst claimed feaures from his TCPA FAQ (http://www.cl.cam.ac.uk/~rja14/tcpa-faq.html), censoring objectionable programs/data off people's computers against their will, actually doesn't rely on TCPA at all. In fact he says they could do it with existing Windows OS's just as well. It's such an obviously nasty feature that I can't see them ever actually trying this, but in any case it really doesn't have anything to do with TCPA. Maybe someone could ask Ross why his FAQ blames TCPA for a feature that he admits isn't really related! But no, that would be crazy. Better to believe comfortable falsehoods than to seek the truth. From usacard at marketingontarget.net Sun Aug 4 17:05:06 2002 From: usacard at marketingontarget.net (USA CreditCard) Date: 5 Aug 2002 00:05:06 -0000 Subject: Get a $5000 Credit Limit Message-ID: <200208041604.g74G4XV2027772@ak47.algebra.com> A non-text attachment was scrubbed... Name: not available Type: text/html Size: 2113 bytes Desc: not available URL: From remailer at aarg.net Mon Aug 5 00:10:12 2002 From: remailer at aarg.net (AARG! Anonymous) Date: Mon, 5 Aug 2002 00:10:12 -0700 Subject: dangers of TCPA/palladium Message-ID: Adam Back writes: > - Palladium is a proposed OS feature-set based on the TCPA hardware > (Microsoft) Actually there seem to be some hardware differences between TCPA and Palladium. TCPA relies on a TPM, while Palladium uses some kind of new CPU mode. Palladium also includes some secure memory, a concept which does not exist in TCPA. > The main 4 features proposed in the TCPA/palladium scheme are: > > 1. secure bootstrap -- checksums of BIOS, firmware, privileged OS code > are used to ensure the machine knows whether it is running certified > software or not. This is rooted in hardware, so you can't by pass it > by using virtualization, only by hardware hacking (*). > > 2. software attestation -- the hardware supports attesting to a third > party whether a call comes from a certified software component as > assured by the hardware described in feature 1. More generally, the hardware can attest to many aspects of the current machine state, including the cumulative hash of the software which has booted so far. > 3. hardware assisted compartmentalization -- CPU can run privileged > software, and RAM can contain information that you can not examine, > and can not modify. (Optionally the software source can be published, > but that is not necessary, and if it's not you won't be able to > reverse-engineer it as it can be encrypted for the CPU). TCPA does not get into this part, only the Palladium white paper mentions this. However it does seem to be a logical component for effective trusted computing. > 4. sealing -- applications can store data that can only be read by > that application. This works based on more hardware -- the software > state checksums developed in feature 1 are used by hardware to > generate encryption keys. The hardware will refuse to generate the > key unless the same software state is running. Right. This plus the attestation are what allow an application to create a "closed world". See my earlier message for examples of how this could be used to enhance privacy and anonymity. What better example of a closed world than your own secrets? > It's interesting to see that one of the author's of [6] has said that > TCPA as curently formed is a bad thing and is trying to influence TCPA > to make it more open, to exhibit stronger privacy properties read his > comments at [7]. I don't think his comments make that much sense. I'd be curious to read your take on them. What is he talking about with the non-malleable root of trusted storage? Trusted storage seems like one of the least objectionable aspects. Is he confusing this with the endorsement key, used to make the remote attestations? Or is this related to the idea that you won't be able to boot your OS of choice? > There are a lot of potential negative implications of this technology, > it represents a major shift in the balance of power comparable in > magnitude to the clipper chip: > > 1. Potentially cedes control of the platform -- while the palladium > docs talk about being able to boot the hardware with TCPA turned off, > there exists possibility that with minor configuration change the > hardware / firmware ensemble that forms palladium/TCPA could be > configured to allow only certified OSes to boot, period. It's > intereseting to note, if I read correctly, that the X-box (based on > celeron processor and TCPA / TCPA-like features) does employ this > feature. See for example: [8]. This is of course one of the biggest criticisms of TCPA - that it could be changed so that you will only be able to boot certified OS's. Don't you think that would have to be done by law, rather than as a preemptive act by the technologists (for antitrust reasons if nothing else)? Why would such a law be passed? IMO the social changes necessary to even begin to imagine such a drastic step are so huge that the technological implementation seems minor in comparison. I don't think it is fair to criticize this proposal for such a far-fetched possibility. > The documents talk about there being no barrier to certifying TCPA > aware extensions to open-source OSes. However I'm having trouble > figuring out how this would work. Perhaps IBM with it's linux support > would build a TCPA extension for linux. Think about it -- the > extension runs in privileged mode, and presumably won't be certified > unless it passes some audit enforcing TCPA policies. (Such as keeping > the owner of the machine from reading sealed documents, or reading the > contents of DRM policy controlled documents without meeting the > requirements for the DRM policy.) TCPA doesn't currently cover certifying operating systems. They talk about certifying TPMs, about certifying PC hardware designs and implementations. Possibly in the next version they will get into issues like this. In the mean time, supposedly HP is going forward with an OS that can use TCPA features. > 2. DSS over-again -- a big aspect of the DSS reverse-engineering was > to allow DVDs to be played in software on linux. The TCPA platform > seems to have the primary goal of making a framework within which it > is possible to build extensions to implement hardware tamper resistant > DRM. (The DRM implementation would run in a hardware assisted code > compartment as described in feature 3 above). So now where does that > put open source platforms? Will they be able to read such DRM > protected content? It seems likely that in the longer term the DRM > platform will include video cards without access to video memory, > perhaps encryption of the video signal out to the monitor, and of > audio out to the speakers. (There are other existing schemes to do > these things which dovetail into the likely TCPA DRM framework.) > > With the secure boot strap described in feature 1, the video card and > so on are also part of the boot strap process, so the DRM system would > have ready support from the platform for robustly refusing to play > except on certain types of hardware. Similarly the application > software which plays these DRM policy protected files and talks to the > DRM policy module in the hardware assisted code compartment will > itself be an application which uses the security boot-strapping > features. So it won't be possible to write an application on for > example linux to play these files without an audit and license etc > from various content, DRM and OS cartels. This will lead to exactly > the kind of thing Richard Stallman talked about in his prescient paper > on the coming platform and right to develop competing software control > wars [9]. I think this analysis is largely correct, except that it won't be as monolithic as you make it sound. There won't be just one content supplier who judges all software, that's obviously impossible. Rather, each different supplier will make its own determination of which software you can trust. And likewise for non-DRM applications. Banks will decide which banking software to trust. Game networks will decide which game clients to trust, etc. > 3. Privacy support is broken -- the "privacy" features while clearly > attempts to defuse a re-run at the pentium serial number debacle, have > not really fixed it's problems. You have to trust the "Trusted Third > Party" privacy CA not to track you and not to collude with other CAs > and software vendors. There are known solutions to this particular > sub-problem, for example Stefan Brands digital credentials [10], which > can be used to build a cryptographically assured privacy preserving > PKI avoiding the linking problems arising from identity based and > attribute certificates. I agree that it would be nice to see more flexibility there. The Chaum blinding patent expires in 2005, so maybe around then we can start seeing privacy CA's that use blind signatures, which solves that problem. The spec is obviously trying hard to protect privacy, it's just that the mechanisms to do it right are extremely complex compared to the straightforward way. > 4. Strong enforcement for DMCA DRM excesses -- the types of DRM system > which the platform enables stand a fair chance of providing high > levels of enforcement for things which though strictly legally > mandated (copyright licensing restrictions, limited number of plays of > CDs / DVDs other disadvantageous schemes; inflexible and usurious > software licensing), if enforced strictly would have deleterious > effects on society and freedom. Copyright violation is widely > practiced to a greater or less extent by just about all individuals. > It is widely viewed as acceptable behavior. These social realities > and personal freedoms are not taken into account or represented in the > lobbying schemes which lead to the media cartels obtaining legal > support for the erosion of users rights and expansionist power grabs > in DMCA, WIPO etc. > > Some of these issues might be not so bad except for the track records, > and obvious monopolistic tendencies and economic pressures on the > entities who will have the root keys to the worlds computers. There > will be no effect choice or competition due to existing near > monopolies, or cartelisation in the hardware, operating system, and > content distribution conglomerates. Nobody's putting a gun to your head and making you download content. If you can't agree to the conditions, go do something else. There are much worse things that can happen in the world than that copyright becomes enforceable. Why not give the market a chance? Company A provides the data with Draconian DRM restrictions; company B gives you more flexibility in what you do. All else being equal, people will prefer company B. So they can charge more. In this way a balance will be reached depending on how much people really value this kind of flexibility and how much they are willing to pay for it. You and I don't get to decide, the people who are making the decisions about what content to buy will decide. And nobody's got the root key to my computer. You make this claim in many places in the document. What exactly is this "root key" in TCPA terms? The endorsement key? It's private part is generated on-chip and never leaves the chip! > 5. Strong enforcement for the software renting model -- the types of > software licensing policy enforcement that can be built with the > platform will also start to strongly enable the software and object > rental ideas. Again potentially these models have some merit except > that they will be sabotaged by API lock out, where the root key owners > will be able to charge monopoly rents for access to APIs. I don't follow this. What root key owners? What APIs? Could you say more about how TCPA will help with software rental? > 6. Audits and certification become vastly more prevalent. Having had > some involvement with software certification (FIPS 140-1 / CC) I can > attest that this can be expensive exercises. It is unlikely that the > open source community will be able to get software certified due to > cost (the software is free, there is no business entity to claim > ownership of the certification rights, and so no way to recuperate the > costs). While certification where competition is able to function is > a good thing, providing users with a transparency and needed > assurance, the danger with tying audits to TCPA is that it will be > another barrier to entry for small businesses, and for open source > particularly. This is a good point, but again it depends on the specific content realm. There are not just one or two - there are thousands of kinds of content, or even more. Not everyone is going to require FIPS 140 levels of certification! But possibly Disney and Sony will. My guess is that if there ever is a Linux program that will play their movies, it will be because those companies contracted to get it written. You may see this in many contexts - software applications don't get certified, rather they are supplied by the vendors, or the vendors arrange to get them done. > 7. Untrusted, unauditable software will be able to run without > scrutiny inside the hardware assisted code compartments. Some of the > documentation talks about open sourcing some aspects. While this may > come to pass, but that sounded like the TOR (Trusted Operating Root); > other extension modules also running in unauditable compartments will > not be so published. This part I don't understand too much; it's not a TCPA concept, and there is little known about Palladium. Supposedly the idea is that this is a place that code can run without being touched by debuggers or viruses. I don't know what happens if a virus gets itself loaded into this area, if that is even possible. Maybe all the different compartments are isolated from each other. Does this seem like a bad feature to you? > 8. Gives away root control of your machine -- providing potentially > universal remote control of users machines to any government agencies > with access to the TCPA certification master keys, or policies > allowing them to demand certifications on hostile code on demand. > Central authorities are likely to be the only, or the default > controllers of the firmware/software upgrade mechanism which comes as > part of the secure bootstrap feature. Now you're starting to go paranoid. All the TCPA certification master keys do is to certify that a system is TCPA compliant. They don't have a remote control over your machine! They are more analogous to Verisign in the X.509 world. Last I checked they hadn't taken over my box. As far as the field upgrade, it has to be authorized by the owner. I'm disappointed to see this kind of fantasizing in what has been a well grounded document until now. If you're going to make this kind of charge, that TCPA gives a universal remote control to government, you need to back it up in detail. > 9. Provides a dangerously tempting target for government power-grabs > -- governments will be very interested to be able to abuse the power > provided by the platform, to gain access to it's keys to be able to > insert remote backdoors, and/or to try to mandate government policy > enforcement modules once such a platform is built. Think this is > unrealistic? Recall clipper? The TCPA is a generic extensible policy > enforcement architecture which can be configured to robustly enforce > policies against the interests of the machine owner. Clipper, > key-escrow the whole multi-year fight, at some point in the near > future if some of the more egregious TCPA/Palladium framework features > and configuration possibilities becomes widely deployed could be > implemented after the fact, as a TCPA/Palladium policy extentsion > which runs in the hardware assisted code compartment and is > authenticated up to the hardware boot by the secure bootstrapping > process. I don't agree with your characterization that TCPA enforces policies against the owner's interests. He has to voluntarily agree to everything, from turning on TCPA, to booting a TCPA compliant program, to running an application which some third party will trust, to accepting data from that third party under agreed-upon conditions. If at any step he didn't feel that what he was doing was in his interests, he can stop and do something else. When you walk into a store and pay money for food, is that store enforcing policies against your interests? Only from the most shallow perspective, for if such policies were not widely enforced, you and I and everyone else would starve. We all participate voluntarily in these institutions. Each payment we make is in our interests. And the same thing is true if you receive some data with conditions on how it is manipulated. As far as the concern about changes, I think the smart thing to do is to fight the bad and promote the good. Definitely we should oppose any proposal to make TCPA non-voluntary, to force people to boot a certain OS, to limit what they can do on their computers. But presently none of those features are in TCPA. Rather than saying TCPA is bad because someone could make all these hypothetical changes, it makes more sense to judge TCPA on its own, as a system that emphasizes user choice. Involuntary TCPA is bad, voluntary is good. So we should not fight TCPA, we should fight proposals to make it involuntary. > So what I've read so far, I think people's gut reactions are right -- > that it's an aggressive and abmitious power grab by the evil empire -- > the 3 cartels / monopolies surrounding PC hardware, Operating systems > and Content Distribution. The operating system near monoply will > doubtless find creative ways to use and expand the increased control > to control application interoperability (with the sealing function), > to control with hardware assistance the access to undocumented APIs > (no more reverse engineering, or using the APIs even if you do / could > reverse engineer). I think you are looking at it far too narrowly. Yes, this will provide many opportunities for Microsoft to write new kinds of software. But the same is true for every other software company! Financial software, web services, security software, accounting - anything that involves trust and security can benefit from TCPA. Look at the example I gave earlier for a TCPA based anonymous comm network. Multiply that a thousand fold. It's stupid to just look at what one company can do with this, without considering what a whole world of creative people can accomplish. Yes, it can make reverse engineering much more difficult. But I'd rather see people put their creative efforts into creating new products rather than copying and piggybacking off someone else's success. > So some of the already applications are immediately objectionable. > The scope for them to become more so with limited recourse or > technical counter-measures possible on the part of the user community > is huge. Probably the worst aspect is the central control -- it > really effectively does give remote root control to your machine to > people you don't want to trust. Also the control _will_ be abused for > monopolistic rent seeking and exclusionary policies to lock-out > competition. Don't forget the fact that microsoft views linux as a > major enemy as revealed by documents uncovered some the anti-trust > discovery process. Again, you need to justify this remote root control notion. I don't see it at all. Go back to your four functions of TCPA/Palladium - they were pretty accurate. Where was the remote root control in there? > In fact I'd say this is the biggest coming risk to personal freedom > since the days during the onset of the clipper chip / key escrow > looked like they stood some chance of becoming reality. I'd say that it is a powerful technology with an almost infinite number of potential applications. Being able to trust software running on a remote system is something that has never been possible before on the Internet. We can only begin to see what will be possible with this capability. From OoAmBiGuOuSQToO at msn.com Sun Aug 4 22:24:16 2002 From: OoAmBiGuOuSQToO at msn.com (OoAmBiGuOuSQToO at msn.com) Date: Mon, 5 Aug 2002 02:24:16 -0300 Subject: (no subject) Message-ID: <200208050524.CAA14494@server.tdf.com.br> Below is the result of your feedback form. It was submitted by (OoAmBiGuOuSQToO at msn.com) on Monday, August 5, 2002 at 02:24:16 --------------------------------------------------------------------------- message: Hey!! What's Up? I'm *Monica* 20/F/Arizona/Webcam & Pics. I'm *LIVE* on my *FREE* Webcam mostly 24/7 so if you wanna come in and chat or see a couple of my pics on my website please go to my Personal Homepage at http://www.freelivewebcamchicks.net and hopefully i'll talk to you in a bit hun! If you join and the webchat is already full im sorry, just wait like 5 minutes and then you'll be able to see me LIVE!! If you don't have a webcam of your own its okay!! You can still watch and chat with me then!! *Remember* this is my Personal Homepage so of course its *FREE*!!! *ByE* <333 Monica <333 --------------------------------------------------------------------------- From adam at cypherspace.org Sun Aug 4 22:00:31 2002 From: adam at cypherspace.org (Adam Back) Date: Mon, 5 Aug 2002 06:00:31 +0100 Subject: dangers of TCPA/palladium Message-ID: <20020805060031.A518477@exeter.ac.uk> Like anonymous, I've been reading some of the palladium and TCPA docs. I think some of the current disagreements and not very strongly technology grounded responses to anonymous are due to the lack of any concise and informative papers describing TCPA and palladium. Not everyone has the energy to reverse engineer a detailed 300-odd pages of TCPA spec [1] back into high-level design considerations; the more manageably short business level TCPA FAQs [2], [3] are too heavily PR spun and biased to extract much useful information from. So so far I've read Ross Anderson's initial expose of the problem [4]; plus Ross's FAQ [5]. (And more, reading list continues below...). The relationship between TCPA, and Palladium is: - TCPA is the hardware and firmware (Compaq, Intel, IBM, HP, and Microsoft, plus 135+ other companies) - Palladium is a proposed OS feature-set based on the TCPA hardware (Microsoft) The main 4 features proposed in the TCPA/palladium scheme are: 1. secure bootstrap -- checksums of BIOS, firmware, privileged OS code are used to ensure the machine knows whether it is running certified software or not. This is rooted in hardware, so you can't by pass it by using virtualization, only by hardware hacking (*). 2. software attestation -- the hardware supports attesting to a third party whether a call comes from a certified software component as assured by the hardware described in feature 1. 3. hardware assisted compartmentalization -- CPU can run privileged software, and RAM can contain information that you can not examine, and can not modify. (Optionally the software source can be published, but that is not necessary, and if it's not you won't be able to reverse-engineer it as it can be encrypted for the CPU). 4. sealing -- applications can store data that can only be read by that application. This works based on more hardware -- the software state checksums developed in feature 1 are used by hardware to generate encryption keys. The hardware will refuse to generate the key unless the same software state is running. One good paper to understand the secure bootstrap is an academic paper "A Secure and Reliable Bootstrap architecture" [6]. It's interesting to see that one of the author's of [6] has said that TCPA as curently formed is a bad thing and is trying to influence TCPA to make it more open, to exhibit stronger privacy properties read his comments at [7]. There are a lot of potential negative implications of this technology, it represents a major shift in the balance of power comparable in magnitude to the clipper chip: 1. Potentially cedes control of the platform -- while the palladium docs talk about being able to boot the hardware with TCPA turned off, there exists possibility that with minor configuration change the hardware / firmware ensemble that forms palladium/TCPA could be configured to allow only certified OSes to boot, period. It's intereseting to note, if I read correctly, that the X-box (based on celeron processor and TCPA / TCPA-like features) does employ this feature. See for example: [8]. The documents talk about there being no barrier to certifying TCPA aware extensions to open-source OSes. However I'm having trouble figuring out how this would work. Perhaps IBM with it's linux support would build a TCPA extension for linux. Think about it -- the extension runs in privileged mode, and presumably won't be certified unless it passes some audit enforcing TCPA policies. (Such as keeping the owner of the machine from reading sealed documents, or reading the contents of DRM policy controlled documents without meeting the requirements for the DRM policy.) 2. DSS over-again -- a big aspect of the DSS reverse-engineering was to allow DVDs to be played in software on linux. The TCPA platform seems to have the primary goal of making a framework within which it is possible to build extensions to implement hardware tamper resistant DRM. (The DRM implementation would run in a hardware assisted code compartment as described in feature 3 above). So now where does that put open source platforms? Will they be able to read such DRM protected content? It seems likely that in the longer term the DRM platform will include video cards without access to video memory, perhaps encryption of the video signal out to the monitor, and of audio out to the speakers. (There are other existing schemes to do these things which dovetail into the likely TCPA DRM framework.) With the secure boot strap described in feature 1, the video card and so on are also part of the boot strap process, so the DRM system would have ready support from the platform for robustly refusing to play except on certain types of hardware. Similarly the application software which plays these DRM policy protected files and talks to the DRM policy module in the hardware assisted code compartment will itself be an application which uses the security boot-strapping features. So it won't be possible to write an application on for example linux to play these files without an audit and license etc from various content, DRM and OS cartels. This will lead to exactly the kind of thing Richard Stallman talked about in his prescient paper on the coming platform and right to develop competing software control wars [9]. 3. Privacy support is broken -- the "privacy" features while clearly attempts to defuse a re-run at the pentium serial number debacle, have not really fixed it's problems. You have to trust the "Trusted Third Party" privacy CA not to track you and not to collude with other CAs and software vendors. There are known solutions to this particular sub-problem, for example Stefan Brands digital credentials [10], which can be used to build a cryptographically assured privacy preserving PKI avoiding the linking problems arising from identity based and attribute certificates. 4. Strong enforcement for DMCA DRM excesses -- the types of DRM system which the platform enables stand a fair chance of providing high levels of enforcement for things which though strictly legally mandated (copyright licensing restrictions, limited number of plays of CDs / DVDs other disadvantageous schemes; inflexible and usurious software licensing), if enforced strictly would have deleterious effects on society and freedom. Copyright violation is widely practiced to a greater or less extent by just about all individuals. It is widely viewed as acceptable behavior. These social realities and personal freedoms are not taken into account or represented in the lobbying schemes which lead to the media cartels obtaining legal support for the erosion of users rights and expansionist power grabs in DMCA, WIPO etc. Some of these issues might be not so bad except for the track records, and obvious monopolistic tendencies and economic pressures on the entities who will have the root keys to the worlds computers. There will be no effect choice or competition due to existing near monopolies, or cartelisation in the hardware, operating system, and content distribution conglomerates. 5. Strong enforcement for the software renting model -- the types of software licensing policy enforcement that can be built with the platform will also start to strongly enable the software and object rental ideas. Again potentially these models have some merit except that they will be sabotaged by API lock out, where the root key owners will be able to charge monopoly rents for access to APIs. 6. Audits and certification become vastly more prevalent. Having had some involvement with software certification (FIPS 140-1 / CC) I can attest that this can be expensive exercises. It is unlikely that the open source community will be able to get software certified due to cost (the software is free, there is no business entity to claim ownership of the certification rights, and so no way to recuperate the costs). While certification where competition is able to function is a good thing, providing users with a transparency and needed assurance, the danger with tying audits to TCPA is that it will be another barrier to entry for small businesses, and for open source particularly. 7. Untrusted, unauditable software will be able to run without scrutiny inside the hardware assisted code compartments. Some of the documentation talks about open sourcing some aspects. While this may come to pass, but that sounded like the TOR (Trusted Operating Root); other extension modules also running in unauditable compartments will not be so published. 8. Gives away root control of your machine -- providing potentially universal remote control of users machines to any government agencies with access to the TCPA certification master keys, or policies allowing them to demand certifications on hostile code on demand. Central authorities are likely to be the only, or the default controllers of the firmware/software upgrade mechanism which comes as part of the secure bootstrap feature. 9. Provides a dangerously tempting target for government power-grabs -- governments will be very interested to be able to abuse the power provided by the platform, to gain access to it's keys to be able to insert remote backdoors, and/or to try to mandate government policy enforcement modules once such a platform is built. Think this is unrealistic? Recall clipper? The TCPA is a generic extensible policy enforcement architecture which can be configured to robustly enforce policies against the interests of the machine owner. Clipper, key-escrow the whole multi-year fight, at some point in the near future if some of the more egregious TCPA/Palladium framework features and configuration possibilities becomes widely deployed could be implemented after the fact, as a TCPA/Palladium policy extentsion which runs in the hardware assisted code compartment and is authenticated up to the hardware boot by the secure bootstrapping process. So what I've read so far, I think people's gut reactions are right -- that it's an aggressive and abmitious power grab by the evil empire -- the 3 cartels / monopolies surrounding PC hardware, Operating systems and Content Distribution. The operating system near monoply will doubtless find creative ways to use and expand the increased control to control application interoperability (with the sealing function), to control with hardware assistance the access to undocumented APIs (no more reverse engineering, or using the APIs even if you do / could reverse engineer). So some of the already applications are immediately objectionable. The scope for them to become more so with limited recourse or technical counter-measures possible on the part of the user community is huge. Probably the worst aspect is the central control -- it really effectively does give remote root control to your machine to people you don't want to trust. Also the control _will_ be abused for monopolistic rent seeking and exclusionary policies to lock-out competition. Don't forget the fact that microsoft views linux as a major enemy as revealed by documents uncovered some the anti-trust discovery process. In fact I'd say this is the biggest coming risk to personal freedom since the days during the onset of the clipper chip / key escrow looked like they stood some chance of becoming reality. Adam -- http://www.cypherspace.org/adam/ (*) It may be possible to hack the firmware, given access to source temporarily. [1] "Trusted Computing Platform Alliance (TCPA) Main Specification Version 1.1b", TCPA http://www.trustedcomputing.org/docs/main%20v1_1b.pdf [2] "TCPA Specification/TPM Q&A", TCPA http://www.trustedcomputing.org/docs/TPM_QA_071802.pdf [3] "TCPA Frequently Asked Questions Rev 5.0", TCPA http://www.trustedcomputing.org/docs/Website_TCPA%20FAQ_0703021.pdf [4] "Security in Open versus Closed Systems (The Dance of Boltzmann, Coase and Moore)", Ross Anderson, (Sections 4 and 5 only, rest is unrelated) ftp://ftp.cl.cam.ac.uk/users/rja14/toulouse.pdf [5] "TCPA / Palladium Frequently Asked Questions Version 1.0" http://www.cl.cam.ac.uk/~rja14/tcpa-faq.html [6] "A Secure and Reliable Bootstrap Architecture" @inproceedings{Arbaugh:97:secure-bootstrap, author = "Bill Arbaugh and Dave Farber and Jonathan Smith", title = "A Secure and Reliable Bootstrap Architecture", booktitle = "Proceedings of the IEEE Symposium on Security and Privacy", pages = 65-71, note = "Also available as \url{http://www.cis.upenn.edu/~waa/aegis.ps}" } [7] "The TCPA; What's wrong; What's right and what to do about", William Arbaugh, 20 Jul 2002 http://www.cs.umd.edu/~waa/TCPA/TCPA-goodnbad.html [8] "Keeping Secrets in Hardware: the Micrsoft Xbox Case Study", Andre "bunnie" Huang, 26 May 2002 http://web.mit.edu/bunnie/www/proj/anatak/AIM-2002-008.pdf [9] "The Right to Read", Richard Stallman, Feb 1997, Communications of the ACM (Volume 40, Number 2). http://www.gnu.org/philosophy/right-to-read.html [10] Stefan Brands Book "Rethinking Public Key Infrastructures and Digital Certificates - Building in Privacy", MIT Press, Aug 2000. http://www.xs4all.nl/~brands/ Number of other technical and semi-technical papers on that page. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From adam at cypherspace.org Sun Aug 4 22:48:01 2002 From: adam at cypherspace.org (Adam Back) Date: Mon, 5 Aug 2002 06:48:01 +0100 Subject: "trust me" pseudonyms in TCPA (Re: Other uses of TCPA) In-Reply-To: ; from eresrch@eskimo.com on Sun, Aug 04, 2002 at 07:38:37PM -0700 References: Message-ID: <20020805064801.A532566@exeter.ac.uk> I haven't read the TCPA detailed spec yet (next on TCPA/Palladium list of reading material), but this bit I can infer I think: > :Mike Rosing wrote: > :> Who owns PRIVEK? Who controls PRIVEK? That's who own's TCPA. > : > :PRIVEK, the TPM's private key, is generated on-chip. It never leaves > :the chip. No one ever learns its value. Given this fact, who would > :you say owns and controls it? > > OK, so why can't any joe hacker create their own PRIVEK? _nobody_ knows > it's value? Then how can anyone know if a chip is "real" or "imitation". > What happens when the motherboard dies again? PRIVEK was copied out of > the chip to some "fob" right? I thought you said the manufacturer put > the keys in at the factory. The corresponding public key is certified by the secure hardware manufacturer, I think. Then they have this privacy CA which accepts requests signed by the platform's signature key, and gives in return a certified pseudonym of the users choice. They claim this gives privacy, which it only does if you trusted the "privacy CA" -- the privacy CA can link all of your anonymous and pseudonymous credentials. (Anonymous may want to straighten out the different keys names -- I think there are some encryption, some signature, some sealing keys derived from other secret keys and the checksum of the application and OS / firmware etc.) Brands digital credentials could be used to fix this sub-problem I think. They put in the privacy CA thing as a defense against the PR problems Intel had with the pentium serial number. The FAQs at www.trustedpc.org talk about this arguing how this is better than pentium serial number at avoiding linkability. The documentation problem I find is there isn't much documentation available which is technical except for the 330 page spec which drops right down to implementation details in RFC standards style. Adam -- http://www.cypherspace.org/adam/ From eresrch at eskimo.com Mon Aug 5 07:19:39 2002 From: eresrch at eskimo.com (Mike Rosing) Date: Mon, 5 Aug 2002 07:19:39 -0700 (PDT) Subject: dangers of TCPA/palladium In-Reply-To: Message-ID: On Mon, 5 Aug 2002, AARG! Anonymous wrote: > Adam Back writes: > > > 2. DSS over-again -- a big aspect of the DSS reverse-engineering was > > to allow DVDs to be played in software on linux. The TCPA platform > > seems to have the primary goal of making a framework within which it > > is possible to build extensions to implement hardware tamper resistant > > DRM. (The DRM implementation would run in a hardware assisted code > > compartment as described in feature 3 above). So now where does that > > put open source platforms? Will they be able to read such DRM > > protected content? It seems likely that in the longer term the DRM > > platform will include video cards without access to video memory, > > perhaps encryption of the video signal out to the monitor, and of > > audio out to the speakers. (There are other existing schemes to do > > these things which dovetail into the likely TCPA DRM framework.) > > > > With the secure boot strap described in feature 1, the video card and > > so on are also part of the boot strap process, so the DRM system would > > have ready support from the platform for robustly refusing to play > > except on certain types of hardware. Similarly the application > > software which plays these DRM policy protected files and talks to the > > DRM policy module in the hardware assisted code compartment will > > itself be an application which uses the security boot-strapping > > features. So it won't be possible to write an application on for > > example linux to play these files without an audit and license etc > > from various content, DRM and OS cartels. This will lead to exactly > > the kind of thing Richard Stallman talked about in his prescient paper > > on the coming platform and right to develop competing software control > > wars [9]. > > I think this analysis is largely correct, except that it won't be > as monolithic as you make it sound. There won't be just one content > supplier who judges all software, that's obviously impossible. Rather, > each different supplier will make its own determination of which software > you can trust. And likewise for non-DRM applications. Banks will decide > which banking software to trust. Game networks will decide which game > clients to trust, etc. > > > 3. Privacy support is broken -- the "privacy" features while clearly > > attempts to defuse a re-run at the pentium serial number debacle, have > > not really fixed it's problems. You have to trust the "Trusted Third > > Party" privacy CA not to track you and not to collude with other CAs > > and software vendors. There are known solutions to this particular > > sub-problem, for example Stefan Brands digital credentials [10], which > > can be used to build a cryptographically assured privacy preserving > > PKI avoiding the linking problems arising from identity based and > > attribute certificates. > > I agree that it would be nice to see more flexibility there. The Chaum > blinding patent expires in 2005, so maybe around then we can start seeing > privacy CA's that use blind signatures, which solves that problem. > The spec is obviously trying hard to protect privacy, it's just that > the mechanisms to do it right are extremely complex compared to the > straightforward way. > > > > 4. Strong enforcement for DMCA DRM excesses -- the types of DRM system > > which the platform enables stand a fair chance of providing high > > levels of enforcement for things which though strictly legally > > mandated (copyright licensing restrictions, limited number of plays of > > CDs / DVDs other disadvantageous schemes; inflexible and usurious > > software licensing), if enforced strictly would have deleterious > > effects on society and freedom. Copyright violation is widely > > practiced to a greater or less extent by just about all individuals. > > It is widely viewed as acceptable behavior. These social realities > > and personal freedoms are not taken into account or represented in the > > lobbying schemes which lead to the media cartels obtaining legal > > support for the erosion of users rights and expansionist power grabs > > in DMCA, WIPO etc. > > > > Some of these issues might be not so bad except for the track records, > > and obvious monopolistic tendencies and economic pressures on the > > entities who will have the root keys to the worlds computers. There > > will be no effect choice or competition due to existing near > > monopolies, or cartelisation in the hardware, operating system, and > > content distribution conglomerates. > > Nobody's putting a gun to your head and making you download content. > If you can't agree to the conditions, go do something else. There are > much worse things that can happen in the world than that copyright > becomes enforceable. > > Why not give the market a chance? Company A provides the data with > Draconian DRM restrictions; company B gives you more flexibility in what > you do. All else being equal, people will prefer company B. So they > can charge more. In this way a balance will be reached depending on how > much people really value this kind of flexibility and how much they are > willing to pay for it. You and I don't get to decide, the people who > are making the decisions about what content to buy will decide. > > And nobody's got the root key to my computer. You make this claim in many > places in the document. What exactly is this "root key" in TCPA terms? > The endorsement key? It's private part is generated on-chip and never > leaves the chip! I agree that the market can have the chance!! Just don't make it anything to do with the law! If people want to buy platforms with TCPA built in they should be allowed to, and those who don't should be free to choose that way. You now claim there are at least 2 keys that don't leave the chip, but if you are going to recover anything encrypted by those keys you had better have them off chip when the chip dies. > > 7. Untrusted, unauditable software will be able to run without > > scrutiny inside the hardware assisted code compartments. Some of the > > documentation talks about open sourcing some aspects. While this may > > come to pass, but that sounded like the TOR (Trusted Operating Root); > > other extension modules also running in unauditable compartments will > > not be so published. > > This part I don't understand too much; it's not a TCPA concept, and there > is little known about Palladium. Supposedly the idea is that this is a > place that code can run without being touched by debuggers or viruses. > I don't know what happens if a virus gets itself loaded into this area, > if that is even possible. Maybe all the different compartments are > isolated from each other. > > Does this seem like a bad feature to you? D'oh!! Obviously it's a bad feature - it gives my computer to some unknown entity. In fact, it gives the entire network of computers to one entity - it creates a huge monster of unequal power. I can sure see why a government like Iraq would love to have this feature. Or China. Or the US. You could run a special program that nobody can stop or find or know about. That's *POWER*. It is difficult to understate how bad that is. > > 8. Gives away root control of your machine -- providing potentially > > universal remote control of users machines to any government agencies > > with access to the TCPA certification master keys, or policies > > allowing them to demand certifications on hostile code on demand. > > Central authorities are likely to be the only, or the default > > controllers of the firmware/software upgrade mechanism which comes as > > part of the secure bootstrap feature. > > Now you're starting to go paranoid. All the TCPA certification master > keys do is to certify that a system is TCPA compliant. They don't have a > remote control over your machine! They are more analogous to Verisign > in the X.509 world. Last I checked they hadn't taken over my box. > As far as the field upgrade, it has to be authorized by the owner. > > I'm disappointed to see this kind of fantasizing in what has been a > well grounded document until now. If you're going to make this kind > of charge, that TCPA gives a universal remote control to government, > you need to back it up in detail. Look, if there can be a section of code that only the manufacturer has access to, then that section of code could have an internet download section that sucks "evil intent" from someplace the manufacturer (or someone who's broken into them) has designated. It's not that we're saying it'd be done on purpose up front, but somebody some day will figure it out and all the tools are there to make it happen. Sometimes a good imagination can save you from having to be paranoid. > > 9. Provides a dangerously tempting target for government power-grabs > > -- governments will be very interested to be able to abuse the power > > provided by the platform, to gain access to it's keys to be able to > > insert remote backdoors, and/or to try to mandate government policy > > enforcement modules once such a platform is built. Think this is > > unrealistic? Recall clipper? The TCPA is a generic extensible policy > > enforcement architecture which can be configured to robustly enforce > > policies against the interests of the machine owner. Clipper, > > key-escrow the whole multi-year fight, at some point in the near > > future if some of the more egregious TCPA/Palladium framework features > > and configuration possibilities becomes widely deployed could be > > implemented after the fact, as a TCPA/Palladium policy extentsion > > which runs in the hardware assisted code compartment and is > > authenticated up to the hardware boot by the secure bootstrapping > > process. > > I don't agree with your characterization that TCPA enforces policies > against the owner's interests. He has to voluntarily agree to everything, > from turning on TCPA, to booting a TCPA compliant program, to running > an application which some third party will trust, to accepting data from > that third party under agreed-upon conditions. If at any step he didn't > feel that what he was doing was in his interests, he can stop and do > something else. > > When you walk into a store and pay money for food, is that store enforcing > policies against your interests? Only from the most shallow perspective, > for if such policies were not widely enforced, you and I and everyone > else would starve. We all participate voluntarily in these institutions. > Each payment we make is in our interests. And the same thing is true > if you receive some data with conditions on how it is manipulated. > > As far as the concern about changes, I think the smart thing to do is > to fight the bad and promote the good. Definitely we should oppose any > proposal to make TCPA non-voluntary, to force people to boot a certain > OS, to limit what they can do on their computers. But presently none > of those features are in TCPA. Rather than saying TCPA is bad because > someone could make all these hypothetical changes, it makes more sense > to judge TCPA on its own, as a system that emphasizes user choice. > > Involuntary TCPA is bad, voluntary is good. So we should not fight TCPA, > we should fight proposals to make it involuntary. Then we agree completely! So long as no laws are passed around TCPA, and it is not linked to any copyright laws, or mandated in any way, then there's no problem! IF TCPA gives people something they want, and they understand how it works, I don't see anything wrong with it. I do see a problem in it being written into any laws because the potential for abuse is huge. > > So what I've read so far, I think people's gut reactions are right -- > > that it's an aggressive and abmitious power grab by the evil empire -- > > the 3 cartels / monopolies surrounding PC hardware, Operating systems > > and Content Distribution. The operating system near monoply will > > doubtless find creative ways to use and expand the increased control > > to control application interoperability (with the sealing function), > > to control with hardware assistance the access to undocumented APIs > > (no more reverse engineering, or using the APIs even if you do / could > > reverse engineer). > > I think you are looking at it far too narrowly. Yes, this will provide > many opportunities for Microsoft to write new kinds of software. But the > same is true for every other software company! Financial software, web > services, security software, accounting - anything that involves trust > and security can benefit from TCPA. Look at the example I gave earlier > for a TCPA based anonymous comm network. Multiply that a thousand fold. > It's stupid to just look at what one company can do with this, without > considering what a whole world of creative people can accomplish. > > Yes, it can make reverse engineering much more difficult. But I'd rather > see people put their creative efforts into creating new products rather > than copying and piggybacking off someone else's success. It will also make backups really expensive. > > So some of the already applications are immediately objectionable. > > The scope for them to become more so with limited recourse or > > technical counter-measures possible on the part of the user community > > is huge. Probably the worst aspect is the central control -- it > > really effectively does give remote root control to your machine to > > people you don't want to trust. Also the control _will_ be abused for > > monopolistic rent seeking and exclusionary policies to lock-out > > competition. Don't forget the fact that microsoft views linux as a > > major enemy as revealed by documents uncovered some the anti-trust > > discovery process. > > Again, you need to justify this remote root control notion. I don't > see it at all. Go back to your four functions of TCPA/Palladium - > they were pretty accurate. Where was the remote root control in there? The only way it works is if there can be code the user doesn't control the loading of. That means somebody else controls the machine. It's pretty basic. > > In fact I'd say this is the biggest coming risk to personal freedom > > since the days during the onset of the clipper chip / key escrow > > looked like they stood some chance of becoming reality. > > I'd say that it is a powerful technology with an almost infinite number of > potential applications. Being able to trust software running on a remote > system is something that has never been possible before on the Internet. > We can only begin to see what will be possible with this capability. Horsepucky. I can run trusted software right now. *I* wrote it, that's why I trust it! I don't need a dongle on the motherboard to ship trusted software. An external dongle works just fine. And I can check the signature of source code I compile to be sure the author has sent me the correct code - I trust it will do what it's supposed to because the encrypted hash matches the source hash. going back to the key stuff - you've changed the names, but what it boils down to is that *somebody* has to have a copy of the internal keys used to encrypt data by the TPM. If it's not the user, who is it? That's the person who owns the data, because they own the keys. I'd say Adam did a nice job nailing TCPA to the wall. Now let's see if it dies slowly or quickly. Patience, persistence, truth, Dr. mike From eresrch at eskimo.com Mon Aug 5 07:42:45 2002 From: eresrch at eskimo.com (Mike Rosing) Date: Mon, 5 Aug 2002 07:42:45 -0700 (PDT) Subject: "trust me" pseudonyms in TCPA (Re: Other uses of TCPA) In-Reply-To: <20020805064801.A532566@exeter.ac.uk> Message-ID: On Mon, 5 Aug 2002, Adam Back wrote: > I haven't read the TCPA detailed spec yet (next on TCPA/Palladium list > of reading material), but this bit I can infer I think: I don't have time to read it, but I do appreciate the effort you've put into this so far! > The corresponding public key is certified by the secure hardware > manufacturer, I think. Are all the keys certified? Are any copied outright? > Then they have this privacy CA which accepts requests signed by the > platform's signature key, and gives in return a certified pseudonym of > the users choice. They claim this gives privacy, which it only does > if you trusted the "privacy CA" -- the privacy CA can link all of your > anonymous and pseudonymous credentials. (Anonymous may want to > straighten out the different keys names -- I think there are some > encryption, some signature, some sealing keys derived from other > secret keys and the checksum of the application and OS / firmware > etc.) > > Brands digital credentials could be used to fix this sub-problem I > think. One key for encryption, one key for signature, one key for checksums, and one key to rule them all!! :-) > They put in the privacy CA thing as a defense against the PR problems > Intel had with the pentium serial number. The FAQs at > www.trustedpc.org talk about this arguing how this is better than > pentium serial number at avoiding linkability. > > The documentation problem I find is there isn't much documentation > available which is technical except for the 330 page spec which drops > right down to implementation details in RFC standards style. I think that explaining it in a mathematical or technical abstract way would give competitors an advantage. Seems like the consortium that's building it can keep these details proprietary and just sell the thing on the market to whoever wants to buy it - no need for all this FAQ stuff anyway. They only need publicity to get past the congress or MP's. I guess I don't see why the spec is public if the purpose is to create a platform that's just a toy. But I'm confused, so keep at it and maybe I'll figure something out! Patience, persistence, truth, Dr. mike From rah at shipwright.com Mon Aug 5 06:15:09 2002 From: rah at shipwright.com (R. A. Hettinga) Date: Mon, 5 Aug 2002 09:15:09 -0400 Subject: Jury rules for Paul Guthrie's Defense in ZixIt's $700mm suit (was Re: GigaLaw.com Daily News, August 5, 2002) In-Reply-To: References: Message-ID: If anyone can get past the "No Cookie" monster to the actual text of this link, let me know. :-). Cheers, RAH At 5:36 AM -0600 on 8/5/02, GigaLaw.com wrote: > Jury Rules for Defense in $700 Million Net Defamation Case > In one of the first trials in the nation to address Internet > defamation, a Dallas County, Texas, jury rejected a $700 million suit by > an Internet company that claimed it was harmed by negative electronic > messages. Dallas' ZixIt alleged that Paul Guthrie, formerly a vice > president with Visa, posted more than 400 anonymous messages, many > negative, about ZixIt on a Yahoo Internet message board, causing ZixIt's > stock price to drop. > Read the article: law.com @ > >http://www.law.com/servlet/ContentServer?pagename=OpenMarket/Xcelerate/View&c=LawArticle&cid=1028320303259&t=LawArticleTech -- ----------------- R. A. Hettinga The Internet Bearer Underwriting Corporation 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire' From nelson at crynwr.com Mon Aug 5 06:38:10 2002 From: nelson at crynwr.com (Russell Nelson) Date: Mon, 5 Aug 2002 09:38:10 -0400 (EDT) Subject: Challenge to David Wagner on TCPA In-Reply-To: References: Message-ID: <15694.32620.956826.906819@desk.crynwr.com> AARG!Anonymous writes: > So don't read too much into the fact that a bunch of anonymous postings > have suddenly started appearing from one particular remailer. For your > information, I have sent over 400 anonymous messages in the past year > to cypherpunks, coderpunks, sci.crypt and the cryptography list (35 > of them on TCPA related topics). We have, of course, no way to verify this fact, since your messages are not cryptographically signed. For someone who claims to be knowledgable about cryptography, this seems like a suspicious omission. -- -russ nelson http://russnelson.com | New Internet Acronym: Crynwr sells support for free software | PGPok | 521 Pleasant Valley Rd. | +1 315 268 1925 voice | IANAE Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | I Am Not An Economist From remailer at aarg.net Mon Aug 5 12:30:11 2002 From: remailer at aarg.net (AARG!Anonymous) Date: Mon, 5 Aug 2002 12:30:11 -0700 Subject: Suggested entry into the TCPA spec Message-ID: <0e7a92034f27922f4e9ef6fc2d085eef@aarg.net> Here is a suggestion for how to appraoch the TCPA spec based on the parts I have found to be relatively good explanations. The spec is available from http://www.trustedcomputing.org/docs/main%20v1_1b.pdf. First read the first few pages up to page 7. This provides an overview and a block diagram, although at this point not all the terms will be familiar. One hint: the "root of trust for measurement" is the set of hardware which has to be working for the boot measurement process to work: the CPU, the TPM, the part of the BIOS that deals with measurements, the motherboard, the secure connections of the chips to the motherboard. If all this stuff is OK then the measurements will be accurate. (Measurements basically are hashes of code and of machine configuration status.) The "root of trust for reporting" is the endorsement key, or more fundamentally the cert on the endorsement key. The cert is issued by the manufacturer, AKA the "TPM Entity" or TPME. That's what makes other people believe your attestations. And the "root of trust for storage" is the storage root key, described in the section on protected storage. There are a few more pages of introduction which aren't too clear, then a long section of data structures which should be skipped until you need to reference them. This brings you to page 97, authorization and ownership. I haven't really studied this part. Probably just read this one page to get an idea of what is involved. I still need to learn more about this. I'd skip on to pages 136-137, on the measurement process and the PCRs which hold the results of the measurement. Then I'd read pages 145-150 on protected storage. This part is pretty well written. It is a reasonably self contained part of the TPM functionality. You just need to know a little bit about the PCRs from the earlier section to understand how data is locked to the specific program which is running. Then I'd read page 261 on the endorsement key, and then 267-269 on how it is used to create a pseudonymous identity. This is the part about communicating with the Privacy CA. BTW an expert told me he has concerns about possible security loopholes in this protocol, but he is communicating with TCPA about them. I think if you just read these selections, about 15 pages, you will have a much better idea of how the spec works. Then you can read some of the specific API descriptions to see more details about the functionality. There is also a glossary at the end which can be helpful for some (but not all) of the terminology. There is another spec, http://www.trustedcomputing.org/docs/TCPA_PCSpecificSpecification_v100.pdf that describes the specific register and trap binding for implementing the TCPA API on Intel PCs. It is much shorter but it is pretty incomprehensible until you have at least read the basics of the main spec. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From dog3 at eruditium.org Mon Aug 5 09:55:57 2002 From: dog3 at eruditium.org (cubic-dog) Date: Mon, 5 Aug 2002 12:55:57 -0400 (EDT) Subject: Challenge to David Wagner on TCPA In-Reply-To: Message-ID: From szunr at szunr.sk Mon Aug 5 04:09:38 2002 From: szunr at szunr.sk (szunr) Date: Mon, 5 Aug 2002 13:09:38 +0200 (CEST) Subject: A WinXP patch Message-ID: <20020805110938.19F90229B@digi.army.sk> A non-text attachment was scrubbed... Name: unnamed.html Type: text/html Size: 167 bytes Desc: not available URL: -------------- next part -------------- ****************************************************** POZNAMKA: priloha s menom disable.bat bola odstranena, nakolko sa jedna o potencionalne nebezpecny subor, ktory umoznuje sirenie virusov. ******************************************************** -------------- next part -------------- A non-text attachment was scrubbed... Name: msie.5.0.local.files.txt Type: application/octet-stream Size: 3531 bytes Desc: not available URL: From dog3 at eruditium.org Mon Aug 5 10:23:50 2002 From: dog3 at eruditium.org (cubic-dog) Date: Mon, 5 Aug 2002 13:23:50 -0400 (EDT) Subject: dangers of TCPA/palladium In-Reply-To: Message-ID: What good is this TCPA stuff anyway? I haven't read anything, pro or con or ambivilent that shows me some clear advandage. It isn't going to fix anything near as I can tell, and with all other technology which has a primary purpose of restricting access, it will undoubtably cause some trouble. So, what's the point? Seems like a grand waste of effort to me. From jamesd at echeque.com Mon Aug 5 13:59:24 2002 From: jamesd at echeque.com (James A. Donald) Date: Mon, 5 Aug 2002 13:59:24 -0700 Subject: Other uses of TCPA In-Reply-To: Message-ID: <3D4E84BC.7221.179C19E@localhost> -- On 4 Aug 2002 at 14:30, AARG! Anonymous wrote: > All I am really asking for is someone to acknowledge that I have > provided information to them which makes them see TCPA as less > dangerous and damaging than they had thought based on the false > information which has been circulating. I don't see how anyone > can deny this. The caricature of TCPA that most people believe > is very bad. The truth is not so bad. Logically, you *have* to > believe that TCPA is not as bad as you thought, when you are > provided with the truth. The spec is OK. The fact that it appeared at the same time as extraordinarily overreaching IP law is damning. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG rwdGfQyOtFA6WkAqxu91fMbC8sahZDn51gg6yvCS 21B3dZ6Ah+eyjxj5hj98h+8bNcUWAprErYOtDB1kH From jamesd at echeque.com Mon Aug 5 14:11:49 2002 From: jamesd at echeque.com (James A. Donald) Date: Mon, 5 Aug 2002 14:11:49 -0700 Subject: Other uses of TCPA In-Reply-To: Message-ID: <3D4E87A5.498.18521BC@localhost> -- On 4 Aug 2002 at 14:30, AARG! Anonymous wrote: > All I am really asking for is someone to acknowledge that I have > provided information to them which makes them see TCPA as less > dangerous and damaging than they had thought based on the false > information which has been circulating. I don't see how anyone > can deny this. The caricature of TCPA that most people believe > is very bad. The truth is not so bad. Logically, you *have* to > believe that TCPA is not as bad as you thought, when you are > provided with the truth. Your account of TCPA is that smooth and reassuring account given in the TCPA FAQ http://www.trustedcomputing.org/docs/TPM_QA_071802.pdf When I read the more technical account http://www.trustedcomputing.org/docs/main%20v1_1b.pdf , and http://www.trustedcomputing.org/docs/TCPA_PCSpecificSpecification_v100 .pdf , I do not see anything so reassuring. I see scary phrases like "root of trust". These more technical specs give lots of irrelevant detail, and very little detail that is actually informative. We get a mixture of smooth sales talk, and blind-em-with-bafflegab technical vagueness. Some of the details in the technical spec seem inconsistent with the smooth and reassuring account. For example: : : "The replacement of code in the platform must be : : performed by a platform manufacturer approved method : : or agent. This allows the manufacturer to establish : : an upgrade method ...." This seems to the say that the TPM has non read write storage containing non volatile code that is privileged, and can be changed, but not however by the user. This would imply that the TPM could be used to enforce any policy whatever, and not necessarily a policy so benevolent as that promised in the sales talk versions of the white papers. You have told us that the TPM is turned off by default, but "off" is merely an off flag, not a full physical off. According to the technical spec : : "The core root of trust measurement (CRTM) MUST be an : : immutable feature of the platform's initialization : : code that executes on platform reset." This is not what most people mean by "off". It provides the physical capability to prohibit unauthorized software from running, even if the nice salesman tells us that capability will never be used. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG AxOIYHF+xyLE0spg6FCaankLLpAULiyK8SWbS3TD 2C/pKtcxdtkar26efao8o6HyGD6ilcST8O9G1KpB0 From Wilfred at Cryogen.com Mon Aug 5 12:55:56 2002 From: Wilfred at Cryogen.com (Wilfred L. Guerin) Date: Mon, 05 Aug 2002 14:55:56 -0500 Subject: Personal Mind Control Devices Message-ID: <3.0.3.32.20020805145556.00b4e0a8@127.0.0.1> Looks like these could be the gateway to personalized mind control devices... http://www.voodoomachine.com/?wid=1048&bid=0 We all know about the various pattern components of neural cognition, however, to have a personal device with such capabilities could not only serve the psychostimulative purposes as suggested, but also prove as a gateway accessor to lower-level cognition modifiers... http://www.voodoomachine.com/?wid=1048&bid=0 VoodooMachine Impressions? -Wilfred L. Guerin Wilfred at Cryogen.com AIM/MSN/YP: "WilfredGuerin" (New Orleans) From jays at panix.com Mon Aug 5 12:37:29 2002 From: jays at panix.com (Jay Sulzberger) Date: Mon, 5 Aug 2002 15:37:29 -0400 (EDT) Subject: dangers of TCPA/palladium In-Reply-To: Message-ID: On Mon, 5 Aug 2002, AARG!Anonymous wrote: < ... /> > Why not give the market a chance? Company A provides the data with > Draconian DRM restrictions; company B gives you more flexibility in what > you do. All else being equal, people will prefer company B. So they > can charge more. In this way a balance will be reached depending on how > much people really value this kind of flexibility and how much they are > willing to pay for it. You and I don't get to decide, the people who > are making the decisions about what content to buy will decide. I am much in sympathy with the "Give the market a chance." slogan. But TCPA/Palladium/DRM and Jack Valenti are not. Nor are you. Phillips could make and sell a device, even the sort of trammeled computer that Jack Valenti wishes to be universally imposed by law, within one year from today. Indeed, IBM, Sun, Apple, Dell, Sony, and any number of other companies could have sold such a device any day they wished over the past fifteen years. Yet they have not. So the market has decided, by your standard. The decision is clear: No DRM. > > And nobody's got the root key to my computer. You make this claim in many > places in the document. What exactly is this "root key" in TCPA terms? > The endorsement key? It's private part is generated on-chip and never > leaves the chip! Of course, the minimal demand of the pro-DRM forces is to have root on every machine in the world, with evasion of their root control a felony. You support DRM lock stock and barrel, no matter your demonstrably inaccurate claims that 1. You are all for the market. 2. Well, DRM is not so bad, see, RIAA-MPAA-AAP will give us all root on their machines, so it is all equal! 3. Why, your computer will be exactly the same under DRM as it is today, except better! > > > 5. Strong enforcement for the software renting model -- the types of > > software licensing policy enforcement that can be built with the > > platform will also start to strongly enable the software and object > > rental ideas. Again potentially these models have some merit except > > that they will be sabotaged by API lock out, where the root key owners > > will be able to charge monopoly rents for access to APIs. > > I don't follow this. What root key owners? What APIs? Could you say > more about how TCPA will help with software rental? Today Microsoft and its script children have root on many machines, yet there is no single root password for them. Rather there is a system, which includes 1. agreements with Dell, IBM, etc., to only offer for sale hardware with Microsoft OSes loaded 2. hardware that only runs right with a Microsoft OS 3. extortionate forced "license agreements" with end-users 4. hypnotic control of the mass media, which always claim that "After all, you will have to run only Microsoft OSes forever." 5. hypnotic control of the managers who "decide" which OS to run, which managers always claim that "After all, we have to run only Microsoft OSes forever." Of course, this hypnosis is mainly self-hypnosis, with only trim-tab level direction by Microsoft, Dell, IBM, Sun, Apple, etc.. oo--JS. > > > 6. Audits and certification become vastly more prevalent. Having had > > some involvement with software certification (FIPS 140-1 / CC) I can > > attest that this can be expensive exercises. It is unlikely that the > > open source community will be able to get software certified due to > > cost (the software is free, there is no business entity to claim > > ownership of the certification rights, and so no way to recuperate the > > costs). While certification where competition is able to function is > > a good thing, providing users with a transparency and needed > > assurance, the danger with tying audits to TCPA is that it will be > > another barrier to entry for small businesses, and for open source > > particularly. > > This is a good point, but again it depends on the specific content > realm. There are not just one or two - there are thousands of kinds > of content, or even more. Not everyone is going to require FIPS 140 > levels of certification! > > But possibly Disney and Sony will. My guess is that if there ever is > a Linux program that will play their movies, it will be because those > companies contracted to get it written. You may see this in many contexts > - software applications don't get certified, rather they are supplied > by the vendors, or the vendors arrange to get them done. > > > 7. Untrusted, unauditable software will be able to run without > > scrutiny inside the hardware assisted code compartments. Some of the > > documentation talks about open sourcing some aspects. While this may > > come to pass, but that sounded like the TOR (Trusted Operating Root); > > other extension modules also running in unauditable compartments will > > not be so published. > > This part I don't understand too much; it's not a TCPA concept, and there > is little known about Palladium. Supposedly the idea is that this is a > place that code can run without being touched by debuggers or viruses. > I don't know what happens if a virus gets itself loaded into this area, > if that is even possible. Maybe all the different compartments are > isolated from each other. > > Does this seem like a bad feature to you? > > > 8. Gives away root control of your machine -- providing potentially > > universal remote control of users machines to any government agencies > > with access to the TCPA certification master keys, or policies > > allowing them to demand certifications on hostile code on demand. > > Central authorities are likely to be the only, or the default > > controllers of the firmware/software upgrade mechanism which comes as > > part of the secure bootstrap feature. > > Now you're starting to go paranoid. All the TCPA certification master > keys do is to certify that a system is TCPA compliant. They don't have a > remote control over your machine! They are more analogous to Verisign > in the X.509 world. Last I checked they hadn't taken over my box. > As far as the field upgrade, it has to be authorized by the owner. > > I'm disappointed to see this kind of fantasizing in what has been a > well grounded document until now. If you're going to make this kind > of charge, that TCPA gives a universal remote control to government, > you need to back it up in detail. > > > > 9. Provides a dangerously tempting target for government power-grabs > > -- governments will be very interested to be able to abuse the power > > provided by the platform, to gain access to it's keys to be able to > > insert remote backdoors, and/or to try to mandate government policy > > enforcement modules once such a platform is built. Think this is > > unrealistic? Recall clipper? The TCPA is a generic extensible policy > > enforcement architecture which can be configured to robustly enforce > > policies against the interests of the machine owner. Clipper, > > key-escrow the whole multi-year fight, at some point in the near > > future if some of the more egregious TCPA/Palladium framework features > > and configuration possibilities becomes widely deployed could be > > implemented after the fact, as a TCPA/Palladium policy extentsion > > which runs in the hardware assisted code compartment and is > > authenticated up to the hardware boot by the secure bootstrapping > > process. > > I don't agree with your characterization that TCPA enforces policies > against the owner's interests. He has to voluntarily agree to everything, > from turning on TCPA, to booting a TCPA compliant program, to running > an application which some third party will trust, to accepting data from > that third party under agreed-upon conditions. If at any step he didn't > feel that what he was doing was in his interests, he can stop and do > something else. > > When you walk into a store and pay money for food, is that store enforcing > policies against your interests? Only from the most shallow perspective, > for if such policies were not widely enforced, you and I and everyone > else would starve. We all participate voluntarily in these institutions. > Each payment we make is in our interests. And the same thing is true > if you receive some data with conditions on how it is manipulated. > > As far as the concern about changes, I think the smart thing to do is > to fight the bad and promote the good. Definitely we should oppose any > proposal to make TCPA non-voluntary, to force people to boot a certain > OS, to limit what they can do on their computers. But presently none > of those features are in TCPA. Rather than saying TCPA is bad because > someone could make all these hypothetical changes, it makes more sense > to judge TCPA on its own, as a system that emphasizes user choice. > > Involuntary TCPA is bad, voluntary is good. So we should not fight TCPA, > we should fight proposals to make it involuntary. > > > So what I've read so far, I think people's gut reactions are right -- > > that it's an aggressive and abmitious power grab by the evil empire -- > > the 3 cartels / monopolies surrounding PC hardware, Operating systems > > and Content Distribution. The operating system near monoply will > > doubtless find creative ways to use and expand the increased control > > to control application interoperability (with the sealing function), > > to control with hardware assistance the access to undocumented APIs > > (no more reverse engineering, or using the APIs even if you do / could > > reverse engineer). > > I think you are looking at it far too narrowly. Yes, this will provide > many opportunities for Microsoft to write new kinds of software. But the > same is true for every other software company! Financial software, web > services, security software, accounting - anything that involves trust > and security can benefit from TCPA. Look at the example I gave earlier > for a TCPA based anonymous comm network. Multiply that a thousand fold. > It's stupid to just look at what one company can do with this, without > considering what a whole world of creative people can accomplish. > > Yes, it can make reverse engineering much more difficult. But I'd rather > see people put their creative efforts into creating new products rather > than copying and piggybacking off someone else's success. > > > So some of the already applications are immediately objectionable. > > The scope for them to become more so with limited recourse or > > technical counter-measures possible on the part of the user community > > is huge. Probably the worst aspect is the central control -- it > > really effectively does give remote root control to your machine to > > people you don't want to trust. Also the control _will_ be abused for > > monopolistic rent seeking and exclusionary policies to lock-out > > competition. Don't forget the fact that microsoft views linux as a > > major enemy as revealed by documents uncovered some the anti-trust > > discovery process. > > Again, you need to justify this remote root control notion. I don't > see it at all. Go back to your four functions of TCPA/Palladium - > they were pretty accurate. Where was the remote root control in there? > > > In fact I'd say this is the biggest coming risk to personal freedom > > since the days during the onset of the clipper chip / key escrow > > looked like they stood some chance of becoming reality. > > I'd say that it is a powerful technology with an almost infinite number of > potential applications. Being able to trust software running on a remote > system is something that has never been possible before on the Internet. > We can only begin to see what will be possible with this capability. > > --------------------------------------------------------------------- > The Cryptography Mailing List > Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From reklam01 at kobiline.com Mon Aug 5 05:43:59 2002 From: reklam01 at kobiline.com (Bu bir reklamdir) Date: Mon, 5 Aug 2002 15:43:59 +0300 Subject: Merhaba; Message-ID: <200208051243.g75ChuR11209@waste.minder.net> Sevgili internet Kullanicilari; Bu mail belki sizleri rahatsiz edecek, belkide ilginizi �ekecek. Eger rahatsiz ettiyse sizlerden �ok �ok �z�r diliyoruz. Biz Avrupadan Erotic �r�n ithal ederek online satisini yapan bir firmayiz. �lkemizde hen�z bir takim tabularin yikilmadigini biliyoruz. Fakat i�inde olabilmek i�in yogun �abalar verdigimiz Avrupa birligi �lkelerinde bu �r�nler marketlerde satiliyor. Hatta Amerikal� �nl� manken Pamela Enderson'a sevgilisinin y�zlerce seks malzemesi hediye etti�ini duymu�sunuzdur. Artik K�resellesen d�nyada bizlerde yerimizi almak ve kisacik hayatimiza mutluluklari sigdirmak zorundayiz. Cinsel yasamin; insan hayatindaki yerini biliyorsaniz? Cinselligin sizin icin �nemini biliyorsaniz? Sizi web sitemizi gezmeye davet ediyoruz. Saygilarimizla Abana Erotik Market www.abanashop.com.tr.tc From remailer at aarg.net Mon Aug 5 16:25:26 2002 From: remailer at aarg.net (AARG! Anonymous) Date: Mon, 5 Aug 2002 16:25:26 -0700 Subject: dangers of TCPA/palladium Message-ID: <09fdc16bc6a040e13686c9150aca01d9@aarg.net> Adam Back writes: > To address privacy with for example Brands digital credentials, the > underlying cryptography may be harder to understand, or at least less > familiar, but I don't think using a toolkit based on Brands digital > credentials would be significantly harder than using an identity or > attribute based PKI toolkit. Similar for Chaum's credentials or other > approach. Sure, but how many pages would it take in the spec to describe the protocol? Especially given their turgid technical-writer prose? Brands took a whole book to describe his credentials thoroughly. In any case, I agree that something like this would be an excellent enhancement to the technology. IMO it is very much in the spirit of TCPA. I suspect they would be very open to this suggestion. > Also I notice you imply patents are a problem. However, the TCPA > itself has patents and will of course charge for the hardware. > Patents it doesn't seem would present a problem for this application, > where there is non-zero reproduction cost hardware involved. They don't say much about patents or intellectual property licensing in the documents I have found on their site. It's not clear to me that the so-called Palladium patents actually cover TCPA. You'd have to look at them in detail. > Anonymous writes: > > And nobody's got the root key to my computer. You make this claim > > in many places in the document. What exactly is this "root key" in > > TCPA terms? The endorsement key? It's private part is generated > > on-chip and never leaves the chip! > > The "root key" to your computing environment is the private key of the > CA that signs the software updates. What software updates, exactly? Spec reference? > You'll recall that in the secure > boot-strapping process if you choose to boot in the TCPA mode, if > there are deviations or updates these are fetched and are only > accepted if certified by the layer owner. No, I don't recall seeing this in the spec. Hopefully as you have a chance to study it you can point out this part. I may well have missed a portion. If so then I agree that this is a potentially serious problem. > You said somewhere in this thread that the user must approve software > and firmware updates. However: > > - the user will not see the source code for the updates > > - the user is not in a position to evaluate the update > > - there will be lots of updates (daily, weekly -- look at microsofts > security bug fix rate), to the extent that the user will blindly click > ok. I was talking about the optional TPM_FieldUpgrade function described on page 251 of the spec. It is apparently intended for bug fixes and such. I doubt that there will be that many bug fixes, or that users will install them that often. And if an upgrade does obvious bad things like the various despotic features you fear, keeping you from booting Linux or whatever, people can avoid installing it. I don't see this as a mechanism for someone to take over the world. It's true what you say about the user having to trust the manufacturer about the upgrade - but he has to trust the manufacturer anyway that the chip works right. Whatever monitoring process may be in place to further that trust can also protect the upgrade as well. > - there is nothing the user can do to determine whether the update he > gets is also the same one other users of the OS get, vs a key board > sniffer the FBI or NSA request is inserted, or have copies of the > software update root keys to insert themselves. > > The problem is the centralised control. The user must at minimum be > able to choose his own software update certification agents. We need > transparency, distributed control, and openness to allow people to use > third party auditors they trust and have reason to trust to audit and > endorse updates. Well, he can choose who he buys the TPM chip from, I suppose. But upgrades are basically new firmware for the TPM chip, so they will probably always come from the manufacturer. Why exactly is this so much more of a threat than, say, flash BIOS upgrades? The BIOS has a lot more power over your machine than the TPM does. > > I don't agree with your characterization that TCPA enforces policies > > against the owner's interests. He has to voluntarily agree to everything, > > from turning on TCPA, to booting a TCPA compliant program, to running > > an application which some third party will trust, to accepting data from > > that third party under agreed-upon conditions. If at any step he didn't > > feel that what he was doing was in his interests, he can stop and do > > something else. > > He has no choice due to architectural design decisions, probably > motivated by economic profit motives in retaining monopoly control of > the TCPA consortium members. The control is ceded at the root of the > secure boot-strapping framework. Everything I have read indicates that he can boot other operating systems. And the spec seems to bear that out. I don't see anywhere in there that it would stop people from booting whatever software they want. > After that all user choice is gone, > all he can do is turn TCPA off. I'm assuming that over time > increasing amounts of the OS and applications will simply not function > without being in TCPA mode, so turning TCPA off will increasingly > become a non-choice. The only way that TCPA will become as popular as you fear is if it really solves problems for people. Otherwise nobody will pay the extra $25 to put it in their machine. > Specifically, you will be able to "choose" not to use the only tools > that will read formats used by 90+% of the world, and which are only > available for the Windows platform, and only when in TCPA mode, to > allow the platform to meet copyright tracking, IP ownership tracking > or other policy features implemented with the document format. That's largely the case already. That's why so many people choose Windows, to be compatible with what everyone else is doing. You seem to judge things by the outcome: Windows being more popular and powerful is bad. I judge by process: letting people make their own decisions is good, even if it leads to an outcome I personally don't like. > The danger once we get to this scenario is that as I described above > TCPA itself becomes "a generic extensible policy enforcement > architecture which can be configured to robustly enforce policies > against the interests of the machine owner." This could be used for > all kinds of malware policies which would run in the secure code > compartments, for example: > > - clipper / US key escrow implementation as a TCPA policy module Where would that fit in the spec? The spec is intentionally not about policy; there is no such thing as a "TCPA policy module". How would TCPA stop people from running their own strong cryptography? You are extrapolating way, way beyond anything that is in this spec. This is just imagination and paranoia. Be concrete. What changes would have to be made to TCPA to get the effects of a mandatory Clipper chip. Would they be made in secret or would some government have to pass a law before it happened? Would the changes happen in one country or all countries? Paint me a scenario that has some kind of connection to reality. Otherwise this sounds like South Park logic: 1. Get TCPA widely used 2. ... 3. Take over the world > - big brotherish policies for regimes interested in censoring and > imposing policies on users such as China, Iraq etc Again, what specific TCPA features will they exploit to accomplish this? > While it may be possible technically to boot in non TCPA mode, or to > boot an open source OS without the malware, most users will not have > the technical ability to know when they are at risk and when not and > what to do to avoid having the government policies enforced upon them. That's already the case. Face it: if government decided to enforce mandatory key escrow, most users would not object and would be unable to help themselves if they did, whether TCPA existed or not. > All kinds of dubious laws in western countries could start to see > stricter enforcement. Fair use rights erosion, data retention laws, > and on; I really think full enforcement of current and soon coming > laws will make things very unpleasant and greatly erode individual > rights. That's possible, and if we lived in a dictatorship I would be more concerned. But if new technologies make laws more enforceable, and people are uncomfortable with the loss of freedom, they will vote to relax restrictions. And as I have pointed out, it is possible that TCPA could allow for other applications that would actually magnify freedom. The thrust of the proposal is to improve the ability for applications to keep their secrets, both locally and on the net. > > As far as the concern about changes, I think the smart thing to do is > > to fight the bad and promote the good. Definitely we should oppose any > > proposal to make TCPA non-voluntary, to force people to boot a certain > > OS, to limit what they can do on their computers. But presently none > > of those features are in TCPA. Rather than saying TCPA is bad because > > someone could make all these hypothetical changes, it makes more sense > > to judge TCPA on its own, as a system that emphasizes user choice. > > A number of the features which are "not in TCPA" are obvious design > motivators. For example online content DRM. Others are obvious > things that Microsoft has been aggressively trying to do for years. > I'm not sure why you suppose they will stop persuing tricks such as > format compatibility lock-out, hidden changing APIs, using every trick > in the book. I'm just looking at the TCPA spec and trying to evaluate it. I don't see all the bad things that people have said are in there. Instead I see a lot of effort to provide security while still protecting user control and privacy. It's true that some developers may use the new power of TCPA for bad purposes, while other people will use it for good. I say, let us focus our criticism, don't waste time trashing a proposal because of things that are not in it. > Similarly I'm not sure why you presume governments will have no > interest in exerting control on the platform. Governments are > certainly not technology leaders, but they sure were persistent in > trying to persue the whole crypto-tech export legislation, > clipper/key-escrow and so on. Also this platform will be used world > wide. There are more repressive regimes with much more intrusive > plans. I just don't see that TCPA is of that much use to them, given that they already have essentially unlimited power. Ultimately, in the West, governments are the responsibility of the populace. If the Chinese government were to do a TCPA-like system, I doubt that it would look much like this one. > > Involuntary TCPA is bad, voluntary is good. So we should not fight TCPA, > > we should fight proposals to make it involuntary. > > Initial claims of "voluntary" is the standard trick for reducing > resistant to deployment. Look at history of various technologies > relating to privacy and security, or just politics in general. First > it's voluntary, then it becomes voluntary in name only (you can choose > not to, put the "choice" is marginalized to become almost > meaningless), and finally the last step is to not even pretend it's > voluntary. Even if so, that's no excuse for trying to stop people from making their own decisions about what to do with their resources. You shouldn't stop people from using a technology because you are afraid that someone else may come along and make it mandatory. > I think it's interesting to explore what can be fixed about TCPA. > It's putative voluntary / mandatory status is one aspect, true, but > more interesting ones are to ensure it is open, has distributed user > configurable control, open access to APIs and non-discriminatory > licensing with no policy strings attached. Absolutely! I fully agree with these sentiments. I think as you study the spec in detail you will see that it does a very good job by these standards. But ultimately you can't let users take control of their TPM chip and force it to lie to other people, without losing the whole point of the system. Doing that would be like insisting on a PKI where every user could make arbitrary modifications to certs issued by other people. Sure, in some sense it may increase freedom, but it's at the cost of making the whole infrastructure worthless. The thing that makes your certified key useful is the raw fact that you can't change it. By the same token, the thing that makes TCPA useful is the fact that you can't get at sealed data or get the system to lie. By voluntarily giving up this ability locally, you gain tremendous power in interacting with other people. From peternbiddle at hotmail.com Mon Aug 5 16:35:46 2002 From: peternbiddle at hotmail.com (Peter N. Biddle) Date: Mon, 5 Aug 2002 16:35:46 -0700 Subject: No subject Message-ID: There are a lot of misconceptions about TCPA and Palladium. I am not going to address TCPA per se, but I do want to try to clear up differences and misconceptions around what Pd does. Comments are in-line: ----- Original Message ----- From: "Adam Back" To: "Cypherpunks" Cc: "Cryptography" ; "Adam Back" Sent: Sunday, August 04, 2002 10:00 PM Subject: dangers of TCPA/palladium > Like anonymous, I've been reading some of the palladium and TCPA docs. Like anonymous and Adam, I have also been reading lots on Palladium lately. I have also been working on Pd since 1997. > I think some of the current disagreements and not very strongly > technology grounded responses to anonymous are due to the lack of any > concise and informative papers describing TCPA and palladium. I agree, and from my perspective this is a problem. We have a great deal of information we need to get out there. > Not everyone has the energy to reverse engineer a detailed 300-odd > pages of TCPA spec [1] back into high-level design considerations; the > more manageably short business level TCPA FAQs [2], [3] are too > heavily PR spun and biased to extract much useful information from. > > So so far I've read Ross Anderson's initial expose of the problem [4]; > plus Ross's FAQ [5]. (And more, reading list continues below...). We have done technical reviews of Palladium, as shown by Seth Schoen's notes (a), which I think talk directly about many of the things discussed in this thread. I suggest anyone who wants to start to understand Pd read these notes. You don't cite the MS whitepaper. This is not a technical paper but it does set precedent and declare intent. See (b). The suggestions for TCPA responses that William Arbaugh raises seem quite good (c). 1 and 2 are already true for Pd, I believe that 3 is true but I would need to talk with him about what he means here to confirm it, 4 is covered in Eric Norlin's blog (d), and 5 is something we should do. > The relationship between TCPA, and Palladium is: > > - TCPA is the hardware and firmware (Compaq, Intel, IBM, HP, and > Microsoft, plus 135+ other companies) The current TPM (version 1.1) doesn't have the primitives which we need to support Palladium, and the privacy model is different. We are working within TCPA to get the instruction set aligned so that Palladium and TCPA could use future silicon for attestation, sealing, and authentication, but as things stand today the approaches to the two of them are different enough so that TCPA 1.1 can't support Pd. > - Palladium is a proposed OS feature-set based on the TCPA hardware > (Microsoft) Pd is an OS feature set based on new hardware. Pd requires changes to the CPU, chipset and/or memory controller, graphics and USB, as well as new silicon (we call an SCP or SSP), . Microsoft currently has no announced plans to support TCPA directly, and as things stand today there is no SW or HW compatibility between the two. > The main 4 features proposed in the TCPA/palladium scheme are: > > 1. secure bootstrap -- checksums of BIOS, firmware, privileged OS code > are used to ensure the machine knows whether it is running certified > software or not. This is rooted in hardware, so you can't by pass it > by using virtualization, only by hardware hacking (*). This is not how Palladium works. Palladium loads a small piece of code called the TOR after the OS has booted and is running (this could be days later). Pd treats the BIOS, firmware, and privileged Windows OS code as untrusted. Pd doesn't care if the SW is certified or not - that is a question left to users. > 2. software attestation -- the hardware supports attesting to a third > party whether a call comes from a certified software component as > assured by the hardware described in feature 1. In Palladium, SW can actually know that it is running on a given platform and not being lied to by software. In 1, you say that SW virtualization doesn't work, and that is part of the design. (Pd can always be lied to by HW - we move the problem to HW, but we can't make it go away completely). As SW is capable of knowing its own state, it can attest this state to others - users, services, other apps, etc. It can't lie when it uses Pd to say what it is. It's up to third parties (again, the user of the machine, or an app, or service) to decide if it likes the answer and trusts the application. Disclosure of the apps identity is up to the user and no one else. Note that in Pd no one but the user can find out the totality of what SW is running except for the nub (aka TOR, or trusted operating root) and any required trusted services. So a service could say "I will only communicate with this app" and it will know that the app is what it says it is and hasn't been perverted. The service cannot say "I won't communicate with this app if this other app is running" because it has no way of knowing for sure if the other app isn't running. > 3. hardware assisted compartmentalization -- CPU can run privileged > software, and RAM can contain information that you can not examine, > and can not modify. (Optionally the software source can be published, > but that is not necessary, and if it's not you won't be able to > reverse-engineer it as it can be encrypted for the CPU). Confusion. The memory isn't encrypted, nor are the apps nor the TOR when they are on the hard drive. Encrypting the apps wouldn't make them more secure, so they aren't encrypted. The CPU uses HW protections to wall new running programs from the rest of the system and from each other. No one but the app itself, named third parties, and the TOR can see into this apps space. In fact, no one (should the app desire) can even know that the app is running at all except the TOR, and the TOR won't report this information to anyone without the apps permission. You can know this to be true because the TOR will be made available for review and thus you can read the source and decide for yourself if it behaves this way. > 4. sealing -- applications can store data that can only be read by > that application. This works based on more hardware -- the software > state checksums developed in feature 1 are used by hardware to > generate encryption keys. The hardware will refuse to generate the > key unless the same software state is running. Correct enough for this thread; it is actually the TOR that will manage the keys for the apps, as this makes the concept of migration and data roaming far more manageable. (Yes, we have thought about this.) > One good paper to understand the secure bootstrap is an academic paper > "A Secure and Reliable Bootstrap architecture" [6]. > > It's interesting to see that one of the author's of [6] has said that > TCPA as currently formed is a bad thing and is trying to influence TCPA > to make it more open, to exhibit stronger privacy properties read his > comments at [7]. > > There are a lot of potential negative implications of this technology, > it represents a major shift in the balance of power comparable in > magnitude to the clipper chip: > > 1. Potentially cedes control of the platform -- while the palladium > docs talk about being able to boot the hardware with TCPA turned off, > there exists possibility that with minor configuration change the > hardware / firmware ensemble that forms palladium/TCPA could be > configured to allow only certified OSes to boot, period. It's > interesting to note, if I read correctly, that the X-box (based on > Celeron processor and TCPA / TCPA-like features) does employ this > feature. See for example: [8]. Comparing xBox and Pd isn't particularly fruitful - they are different problems and thus very different solutions. (Also note that xBox doesn't use the PID or any other unique HW key.) Palladium mostly doesn't care about the BIOS and considers it to be an untrusted system component. In Pd the BIOS can load any OS it wants, just like today, and in Pd the OS can load any TOR specified by the user. The MS TOR will run any app, as specified by the user. The security model doesn't depend on some apps being prevented from running. I believe that there isn't a single thing you can do with your PC today which is prevented on a Palladium PC. I am open to being challenged on this, so please let me know what you think you won't be able to do on a Pd PC that you can do today. > The documents talk about there being no barrier to certifying TCPA > aware extensions to open-source OSes. However I'm having trouble > figuring out how this would work. Perhaps IBM with it's linux support > would build a TCPA extension for linux. Think about it -- the > extension runs in privileged mode, and presumably won't be certified > unless it passes some audit enforcing TCPA policies. (Such as keeping > the owner of the machine from reading sealed documents, or reading the > contents of DRM policy controlled documents without meeting the > requirements for the DRM policy.) > > 2. DSS over-again -- a big aspect of the DSS reverse-engineering was > to allow DVDs to be played in software on linux. The TCPA platform > seems to have the primary goal of making a framework within which it > is possible to build extensions to implement hardware tamper resistant > DRM. (The DRM implementation would run in a hardware assisted code > compartment as described in feature 3 above). So now where does that > put open source platforms? Will they be able to read such DRM > protected content? It seems likely that in the longer term the DRM > platform will include video cards without access to video memory, > perhaps encryption of the video signal out to the monitor, and of > audio out to the speakers. (There are other existing schemes to do > these things which dovetail into the likely TCPA DRM framework.) I think you mean CSS, not DSS. I don't want people snooping my passwords from the keyboard buffer, nor my account info from the frame buffer, and HW protections in those HW areas prevent that. > With the secure boot strap described in feature 1, the video card and > so on are also part of the boot strap process, so the DRM system would > have ready support from the platform for robustly refusing to play > except on certain types of hardware. Similarly the application > software which plays these DRM policy protected files and talks to the > DRM policy module in the hardware assisted code compartment will > itself be an application which uses the security boot-strapping > features. So it won't be possible to write an application on for > example linux to play these files without an audit and license etc > from various content, DRM and OS cartels. This will lead to exactly > the kind of thing Richard Stallman talked about in his prescient paper > on the coming platform and right to develop competing software control > wars [9]. Palladium doesn't boot strap the OS. Pd loads a secure piece of SW, called the TOR, which runs in a secure space and loads other apps that want security. Anyone can load an app into this environment and get the full protections Pd offers. MS doesn't require that you show them the SW first - you wanna run, you get to run - provided the user wants you to run. If a user doesn't like the looks of your app, then you (the developer) have a problem with that user. > 3. Privacy support is broken -- the "privacy" features while clearly > attempts to defuse a re-run at the pentium serial number debacle, have > not really fixed it's problems. You have to trust the "Trusted Third > Party" privacy CA not to track you and not to collude with other CAs > and software vendors. There are known solutions to this particular > sub-problem, for example Stefan Brands digital credentials [10], which > can be used to build a cryptographically assured privacy preserving > PKI avoiding the linking problems arising from identity based and > attribute certificates. The privacy model in Pd is different from TCPA. I could go on for a long time about it, but the key difference is that the public key is only revealed to named third parties which a user trusts. You are right in thinking that you need to trust them, but you don't have to show anyone your key if you don't trust them, so you (the user) are always in control of this. Pd is not about user authentication - it is about machine and SW authentication. User auth can be better solved on a Pd platform than on a PC today, but it isn't required. Pd doesn't need to know who you are to work. > 4. Strong enforcement for DMCA DRM excesses -- the types of DRM system > which the platform enables stand a fair chance of providing high > levels of enforcement for things which though strictly legally > mandated (copyright licensing restrictions, limited number of plays of > CDs / DVDs other disadvantageous schemes; inflexible and usurious > software licensing), if enforced strictly would have deleterious > effects on society and freedom. Copyright violation is widely > practiced to a greater or less extent by just about all individuals. > It is widely viewed as acceptable behavior. These social realities > and personal freedoms are not taken into account or represented in the > lobbying schemes which lead to the media cartels obtaining legal > support for the erosion of users rights and expansionist power grabs > in DMCA, WIPO etc. I don't know where to begin on this one. It deserves a long, well thought out response, and I don't have the time to do it at the moment. I will follow up on this. Let me state that I think that much of the energy around DRM and HW is misplaced, and that Pd is designed to enable seamless distribution of encrypted information, not to disable distribution of clear text information. > Some of these issues might be not so bad except for the track records, > and obvious monopolistic tendencies and economic pressures on the > entities who will have the root keys to the worlds computers. There > will be no effect choice or competition due to existing near > monopolies, or cartelisation in the hardware, operating system, and > content distribution conglomerates. MS will not have the root keys to the world's computers. The TOR won't have access to the private keys either. No one but the HW does. The TOR isn't "MS" per se - it is a piece of SW written by users but vetted and examined by hopefully thousands of parties and found to do nothing other than manage the local security model upon which Pd depends. You can read it and know it doesn't do anything but effectively manage keys and applications. And if you don't trust it, you won't run it. If you don't trust the TOR, you don't trust Palladium. Trust is the *only* feature we are attempting to achieve, so every decision we make will be made with trust and security in mind. > 5. Strong enforcement for the software renting model -- the types of > software licensing policy enforcement that can be built with the > platform will also start to strongly enable the software and object > rental ideas. Again potentially these models have some merit except > that they will be sabotaged by API lock out, where the root key owners > will be able to charge monopoly rents for access to APIs. I am confused as to how this would work in Pd. Anyone can write apps to the Pd API. Zero restrictions. (API's are full of restrictions - by their nature they limit things to a protocol, and potentially HW, both of which have understood limitations; I am dodging this concept in saying there are no restrictions). > 6. Audits and certification become vastly more prevalent. Having had > some involvement with software certification (FIPS 140-1 / CC) I can > attest that this can be expensive exercises. It is unlikely that the > open source community will be able to get software certified due to > cost (the software is free, there is no business entity to claim > ownership of the certification rights, and so no way to recuperate the > costs). While certification where competition is able to function is > a good thing, providing users with a transparency and needed > assurance, the danger with tying audits to TCPA is that it will be > another barrier to entry for small businesses, and for open source > particularly. This is a problem anyone who wants to compete in the security and trust space will need to overcome. I don't think that it is particularly new or different in a world with Pd. Writing a TOR is going to be really hard and will require processes and methods that are alien to many SW developers. One example (of many) is that we are generating our header files from specs. You don't change the header file, you change the spec and then gen the header. This process is required for the highest degrees of predictability, and those are cornerstones for the highest degree of trust. Unpredictable things are hard to trust. > 7. Untrusted, unauditable software will be able to run without > scrutiny inside the hardware assisted code compartments. Some of the > documentation talks about open sourcing some aspects. While this may > come to pass, but that sounded like the TOR (Trusted Operating Root); > other extension modules also running in unauditable compartments will > not be so published. Everything in the TCB (Trusted Computing Base) for Pd will be made available for review to anyone who wants to review it; this includes software which the MS TOR mandates must be loaded. > 8. Gives away root control of your machine -- providing potentially > universal remote control of users machines to any government agencies > with access to the TCPA certification master keys, or policies > allowing them to demand certifications on hostile code on demand. > Central authorities are likely to be the only, or the default > controllers of the firmware/software upgrade mechanism which comes as > part of the secure bootstrap feature. This doesn't happen in Pd. There is no secure boot strap feature in Pd. The BIOS boots up the PC the same way it does today. Root control is held by the owner of the machine. There is no certification master key in Pd. > 9. Provides a dangerously tempting target for government power-grabs > -- governments will be very interested to be able to abuse the power > provided by the platform, to gain access to its keys to be able to > insert remote backdoors, and/or to try to mandate government policy > enforcement modules once such a platform is built. Think this is > unrealistic? Recall clipper? The TCPA is a generic extensible policy > enforcement architecture which can be configured to robustly enforce > policies against the interests of the machine owner. Clipper, > key-escrow the whole multi-year fight, at some point in the near > future if some of the more egregious TCPA/Palladium framework features > and configuration possibilities becomes widely deployed could be > implemented after the fact, as a TCPA/Palladium policy extentsion > which runs in the hardware assisted code compartment and is > authenticated up to the hardware boot by the secure bootstrapping > process. One of the beauties of Pd is that if there is any SW backdoor, you will know about it. HW robustness will be something for manufacturers to work out. For most systems, I think that extensive HW tamper resistance will be a waste of time, but for some (e.g. highly secure govt systems) it will be a necessity and one that works well in Pd. > So what I've read so far, I think people's gut reactions are right -- > that it's an aggressive and abmitious power grab by the evil empire -- > the 3 cartels / monopolies surrounding PC hardware, Operating systems > and Content Distribution. The operating system near monoply will > doubtless find creative ways to use and expand the increased control > to control application interoperability (with the sealing function), > to control with hardware assistance the access to undocumented APIs > (no more reverse engineering, or using the APIs even if you do / could > reverse engineer). I know that we aren't using undocumented API's and that we will strive for the highest degree of interoperability and user control possible. Pd represents massive de-centralization of trust, not the centralization of it. I think that time is going to have to tell on this one. I know that this isn't true. You think that it is. I doubt that my saying it isn't true is going to change your mind; I know that the technology won't do much of what you are saying it does do, but I also know that some of these things boil down to suspicion around intent, and only time will show if my intent is aligned with my stated goals. > So some of the already applications are immediately objectionable. > The scope for them to become more so with limited recourse or > technical counter-measures possible on the part of the user community > is huge. Probably the worst aspect is the central control -- it > really effectively does give remote root control to your machine to > people you don't want to trust. Also the control _will_ be abused for > monopolistic rent seeking and exclusionary policies to lock-out > competition. Don't forget the fact that microsoft views linux as a > major enemy as revealed by documents uncovered some the anti-trust > discovery process. Pd does not give root control of your machine to someone else. It puts it into your hands, to do with as you so desire, including hacking away at it to your hearts content. > In fact I'd say this is the biggest coming risk to personal freedom > since the days during the onset of the clipper chip / key escrow > looked like they stood some chance of becoming reality. I think that Pd represents an enhancement to personal freedoms and user control over their machines. I hope that over time I will be able to explain Pd sufficiently well so that you have all the facts you need to understand how and why I say this. Peter ++++ (a) Seth Schoens Blog http://vitanuova.loyalty.org/2002-07-05.html (b) MS Paper http://www.microsoft.com/presspass/features/2002/jul02/0724palladiumwp.asp (c) William Arbaugh on TCPA http://www.cs.umd.edu/~waa/TCPA/TCPA-goodnbad.html (d) Eric Norlin's blog http://www.unchartedshores.com/blogger/archive/2002_07_28_archive3.html#8530 0559 > > Adam > -- > http://www.cypherspace.org/adam/ > > (*) It may be possible to hack the firmware, given access to source > temporarily. > > [1] "Trusted Computing Platform Alliance (TCPA) Main Specification > Version 1.1b", TCPA > > http://www.trustedcomputing.org/docs/main%20v1_1b.pdf > > [2] "TCPA Specification/TPM Q&A", TCPA > > http://www.trustedcomputing.org/docs/TPM_QA_071802.pdf > > [3] "TCPA Frequently Asked Questions Rev 5.0", TCPA > > http://www.trustedcomputing.org/docs/Website_TCPA%20FAQ_0703021.pdf > > [4] "Security in Open versus Closed Systems (The Dance of Boltzmann, > Coase and Moore)", Ross Anderson, > > (Sections 4 and 5 only, rest is unrelated) > > ftp://ftp.cl.cam.ac.uk/users/rja14/toulouse.pdf > > [5] "TCPA / Palladium Frequently Asked Questions Version 1.0" > > http://www.cl.cam.ac.uk/~rja14/tcpa-faq.html > > [6] "A Secure and Reliable Bootstrap Architecture" > > @inproceedings{Arbaugh:97:secure-bootstrap, > author = "Bill Arbaugh and Dave Farber and Jonathan Smith", > title = "A Secure and Reliable Bootstrap Architecture", > booktitle = "Proceedings of the IEEE Symposium on Security and Privacy", > pages = 65-71, > note = "Also available as \url{http://www.cis.upenn.edu/~waa/aegis.ps}" > } > > [7] "The TCPA; What's wrong; What's right and what to do about", > William Arbaugh, 20 Jul 2002 > > http://www.cs.umd.edu/~waa/TCPA/TCPA-goodnbad.html > > [8] "Keeping Secrets in Hardware: the Micrsoft Xbox Case Study", > Andre "bunnie" Huang, 26 May 2002 > > http://web.mit.edu/bunnie/www/proj/anatak/AIM-2002-008.pdf > > [9] "The Right to Read", Richard Stallman, Feb 1997, Communications of > the ACM (Volume 40, Number 2). > > http://www.gnu.org/philosophy/right-to-read.html > > [10] Stefan Brands > > Book "Rethinking Public Key Infrastructures and Digital Certificates - > Building in Privacy", MIT Press, Aug 2000. > > http://www.xs4all.nl/~brands/ > > Number of other technical and semi-technical papers on that page. > > --------------------------------------------------------------------- > The Cryptography Mailing List > Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com > --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com ----- End forwarded message ----- From jamesd at echeque.com Mon Aug 5 16:37:16 2002 From: jamesd at echeque.com (James A. Donald) Date: Mon, 5 Aug 2002 16:37:16 -0700 Subject: Other uses of TCPA In-Reply-To: <97ae2010fd503056b22ed1e86cdc0853@aarg.net> Message-ID: <3D4EA9BC.10160.20A4A5C@localhost> -- On 4 Aug 2002 at 22:30, AARG! Anonymous wrote: > I've been thinking about writing a few pages summarizing TCPA > and how the crypto works, but then I think, why bother? > Everyone is already convinced that the system is the spawn of > Satan. Nobody cares about the facts. This prejudice is caused by: 1. IP is already overprotected by the state, so any additional protection will meet with hostility. 2. Trusted computing is being brought to us by people we do not trust, accompanied by documents that fail to inspire trust. 3. Trusted computing is an idea that popped up at the same time as a variety of proposals to force the world back to the TV paradigm, a few big companies producing information, and everyone else passively absorbing it. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG bZX0QD4FFlxWxDNGkEsk8orCkxCQCJl4bNYQwpJ4 2MZwjrZWm+U4NSaitrbjL/VtmAn95YEf4aYO7O8C+ From remailer at aarg.net Mon Aug 5 17:00:25 2002 From: remailer at aarg.net (AARG! Anonymous) Date: Mon, 5 Aug 2002 17:00:25 -0700 Subject: Magic Money Message-ID: <9bf8d050687c783f88ae0bb8dde5fe9c@aarg.net> Here is a link for Magic Money: http://ftp.vit.edu.tw/pc/programming/hacktic/ecash/magicmoney/MagicMoney.tar.gz http://www.spinnaker.com/crypt/pgp_tools/ also has a few different versions. I think you need the latest mgmnyxx.zip and the latest pgptlxx.zip. From Kevin.Wall at qwest.com Mon Aug 5 14:27:17 2002 From: Kevin.Wall at qwest.com (Wall, Kevin) Date: Mon, 5 Aug 2002 17:27:17 -0400 Subject: Challenge to David Wagner on TCPA Message-ID: <9956F8424795D411B03B0008C786E60D09EA430F@dubntex005.qwest.net> I'm resending this because I never saw it appear on the cypherpunks at lne.com mailing list. Appologies if it has already been through and I just missed it. -kevin wall -----Original Message----- >From: Wall, Kevin Sent: Friday, August 02, 2002 1:27 AM To: 'ericm at lne.com '; 'cypherpunks at lne.com '; 'cryptography at wasabisystems.com '; 'ptrei at rsasecurity.com' Subject: RE: Challenge to David Wagner on TCPA Mr AARG! writes... > Eric Murray writes: > > Yes, the spec says that it can be turned off. At that point you > > can run anything that doesn't need any of the protected data or > > other TCPA services. But, why would a software vendor that wants > > the protection that TCPA provides allow his software to run > > without TCPA as well, abandoning those protections? > > That's true; in fact if you ran it earlier under TCPA and sealed some > data, you will have to run under TCPA to unseal it later. The question > is whether the advantages of running under TCPA (potentially greater > security) outweigh the disadvantages (greater potential for loss of > data, less flexibility, etc.). and in another reply to Peter Trei, Mr. AARG! also writes... > Now, there is an optional function which does use the manufacturer's key, > but it is intended only to be used rarely. That is for when you need to > transfer your sealed data from one machine to another (either because you > have bought a new machine, or because your old one crashed). In this > case you go through a complicated procedure that includes encrypting > some data to the TPME key (the TPM manufacturer's key) and sending it > to the manufacturer, who massages the data such that it can be loaded > into the new machine's TPM chip. > > So this function does require pre-loading a manufacturer key into the > TPM, but first, it is optional, and second, it frankly appears to be so > cumbersome that it is questionable whether manufacturers will want to > get involved with it. OTOH it is apparently the only way to recover > if your system crashes. This may indicate that TCPA is not feasible, > because there is too much risk of losing locked data on a machine crash, > and the recovery procedure is too cumbersome. That would be a valid > basis on which to criticize TCPA, but it doesn't change the fact that > many of the other claims which have been made about it are not correct. Correct me if I'm wrong (I'm sure you all will :), but wouldn't you also have to possibly go through this exercise with the TPME key and sending your system to the manufacturer when you wanted to, say, upgrade your operating system or switch to a completely different OS? That will go over like a lead balloon. (Gee... must be getting late. I almost wrote "like a bag of dirt". Duh! Can't even remember cliches at my age.) -kevin wall P.S.- Please excuse the sh*t formating. We use Lookout! and MS Exstrange where I work. --- Kevin W. Wall Qwest Information Technology, Inc. Kevin.Wall at qwest.com Phone: 614.932.5542 "Wipe Info uses hexadecimal values to wipe files. This provides more security than wiping with decimal values." -- Norton System Works 2002 manual, pg 160 From market at xmwinner.com Mon Aug 5 02:51:01 2002 From: market at xmwinner.com (Sandy) Date: Mon, 5 Aug 2002 17:51:01 +0800 Subject: No subject Message-ID: <200208050950.g759oGR32536@waste.minder.net> Dear Sir or Madam: Having had your name and address from internet searching, we now avail ourselves of this opportunity to write to you with a view to entering into business relation. We ---XIAMEN WINNER TECHNOLOGY DEVELOPMENT CO.LTD, is engaged in the researching & developing, manufacturing & exporting high-technology products (Both software & hardware). Our series products now cover as follows: Fingerprint Time & Attendance (FDA-01A/B/C); Smart Card Time & Attendance; Fingerprint Safe; Electronic Safe; Fingerprint intercom system (For household, community, office building, single door, Net-linked doors etc.); Parking lot toll system Our excellent engineering team & skilled workers can ensure high quality & prompt delivery. Should any of products be interest of you, please let us know. For detail information , please browse Http: //www.int-bid.com/WINNER or contact, Address : 4-5F, Laodongli Building, Chang Qing Road, Xiamen, China Tel:86-592-5327091,5327092,5038873,5077961 Fax:86-592-5099521 e-mail: market at xmwinner.com 　　　　　　　 　　　　　　　　　　　　　　 <<---以上邮件内容与中资源网络及软件开发商无关--->> ----------------------------------------------- 中资源网络--域名先注册后付款;主机先开通后收费。 申请100M虚拟主机350元/年，送国际域名+5个信箱 新浪，搜狐，网易排名，百度竟价，超值大赠送。 http://www.800asp.net ★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★ ★优联网络全球专业的域名主机提供商 http://www.chinasql.com★ ★套餐： 国际域名 + 100M主机 送10个企业邮箱，支持二级域名★ ★每年318元,不满意可退款。 ★ ★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★ 欢迎使用亿虎Email商务系列软件 免费下载地址: http://www.ehoosoft.com 定向客户搜索: 亿虎Email搜索大师 信息特快群发: 亿虎Email邮差 病毒邮件克星: 亿虎Email安全大师 ...... From emarketingpro at worldnet.att.net Mon Aug 5 19:18:34 2002 From: emarketingpro at worldnet.att.net (Admin) Date: Mon, 5 Aug 2002 19:18:34 Subject: Totally FREE ware ONLY for You! Limited Time! Message-ID: <200208051014.g75AEkR01369@waste.minder.net> A non-text attachment was scrubbed... Name: not available Type: text/html Size: 11709 bytes Desc: not available URL: From jamesd at echeque.com Mon Aug 5 19:33:25 2002 From: jamesd at echeque.com (James A. Donald) Date: Mon, 5 Aug 2002 19:33:25 -0700 Subject: dangers of TCPA/palladium In-Reply-To: <09fdc16bc6a040e13686c9150aca01d9@aarg.net> Message-ID: <3D4ED305.14245.39124E@localhost> -- On 5 Aug 2002 at 16:25, AARG! Anonymous wrote: > Well, he can choose who he buys the TPM chip from, I suppose. > But upgrades are basically new firmware for the TPM chip, so > they will probably always come from the manufacturer. Sure, no problem, if the manufacturer is not acting under state direction. Let us instead suppose, as seems likely, all manufacturers are directed to upgrade TPM with clipper chip technology. Obviously as long as TPM is not backed by legal force, it cannot do anything very bad. But the TPM technology puts my throat where the legislators can cut it. > > The danger once we get to this scenario is that as I described > > above TCPA itself becomes "a generic extensible policy > > enforcement architecture which can be configured to robustly > > enforce policies against the interests of the machine owner." > > This could be used for all kinds of malware policies which > > would run in the secure code compartments, for example: > > > > - clipper / US key escrow implementation as a TCPA policy > > module On 5 Aug 2002 at 16:25, AARG! Anonymous wrote: > Where would that fit in the spec? The hardware supports it. The spec says the software and CA policies will not. The spec also says that both software and policies can and will be frequently revised. There is obvious potential there to back TCPM with anti circumvention laws, and all sorts of unpleasantness. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG 7psEoY7rJFk92hlIOz7Ez88G08qsf7BTR4MvGmI4 2Ue/dlRhUUlakQqaTi3EO1g5Gi1JzpgJD1lLYYgGF From eresrch at eskimo.com Mon Aug 5 20:34:22 2002 From: eresrch at eskimo.com (Mike Rosing) Date: Mon, 5 Aug 2002 20:34:22 -0700 (PDT) Subject: dangers of TCPA/palladium In-Reply-To: <09fdc16bc6a040e13686c9150aca01d9@aarg.net> Message-ID: On Mon, 5 Aug 2002, AARG! Anonymous wrote: > Well, he can choose who he buys the TPM chip from, I suppose. > But upgrades are basically new firmware for the TPM chip, so they will > probably always come from the manufacturer. Or who ever steals the master key. > Why exactly is this so much more of a threat than, say, flash BIOS > upgrades? The BIOS has a lot more power over your machine than the > TPM does. The difference is fundamental: I can change every bit of flash in my BIOS. I can not change *anything* in the TPM. *I* control my BIOS. IF, and only IF, I can control the TPM will I trust it to extend my trust to others. The purpose of TCPA as spec'ed is to remove my control and make the platform "trusted" to one entity. That entity has the master key to the TPM. Now, if the spec says I can install my own key into the TPM, then yes, it is a very useful tool. It would be fantastic in all the portables that have been stolen from the FBI for example. Assuming they use a password at turn on, and the TPM is used to send data over the net, then they'd know where all their units are and know they weren't compromised (or how badly compromised anyway). But as spec'ed, it is very seriously flawed. > > > - big brotherish policies for regimes interested in censoring and > > imposing policies on users such as China, Iraq etc > > Again, what specific TCPA features will they exploit to accomplish this? The untouchable code zone. That's fine for an embedded application, but for a general purpose computing platform it's great for dictators. > That's already the case. Face it: if government decided to enforce > mandatory key escrow, most users would not object and would be unable > to help themselves if they did, whether TCPA existed or not. Yes, dictatorships are stable governments for the short run. Most people are willing to put up with slavery as long as they get food and sleep. But there are enough people who read history (and who have escaped dictatorships) to prevent really bad things from being forced down everyone's throats. TCPM seems like clipper and it also seems like it'd be pretty easy to sell as evil (whether it is or not). I don't think it's going to be an easy fight for the RIAA folks. > I just don't see that TCPA is of that much use to them, given that they > already have essentially unlimited power. Ultimately, in the West, > governments are the responsibility of the populace. > > If the Chinese government were to do a TCPA-like system, I doubt that > it would look much like this one. What makes you think TCPA isn't being designed with the Chinese in mind? They don't believe in copyright to begin with, and they are a huge market. As it's been described so far, it sure seems useful to the master key holder. Patience, persistence, truth, Dr. mike From adam at cypherspace.org Mon Aug 5 13:46:43 2002 From: adam at cypherspace.org (Adam Back) Date: Mon, 5 Aug 2002 21:46:43 +0100 Subject: dangers of TCPA/palladium In-Reply-To: ; from remailer@aarg.net on Mon, Aug 05, 2002 at 12:10:12AM -0700 References: Message-ID: <20020805214643.A544415@exeter.ac.uk> Some comments on selected parts of anonymous post: 1) about claimed "complexity" of cryptographically assured privacy, rather than the current "trust me" privacy via the privacy CA "TTP": Anonymous writes: > Adam Back wrote: > > 3. Privacy support is broken -- the "privacy" features while clearly > > attempts to defuse a re-run at the pentium serial number debacle, have > > not really fixed it's problems. You have to trust the "Trusted Third > > Party" privacy CA not to track you and not to collude with other CAs > > and software vendors. There are known solutions to this particular > > sub-problem, for example Stefan Brands digital credentials [10], which > > can be used to build a cryptographically assured privacy preserving > > PKI avoiding the linking problems arising from identity based and > > attribute certificates. > > I agree that it would be nice to see more flexibility there. The Chaum > blinding patent expires in 2005, so maybe around then we can start seeing > privacy CA's that use blind signatures, which solves that problem. > The spec is obviously trying hard to protect privacy, it's just that > the mechanisms to do it right are extremely complex compared to the > straightforward way. To address privacy with for example Brands digital credentials, the underlying cryptography may be harder to understand, or at least less familiar, but I don't think using a toolkit based on Brands digital credentials would be significantly harder than using an identity or attribute based PKI toolkit. Similar for Chaum's credentials or other approach. Also I notice you imply patents are a problem. However, the TCPA itself has patents and will of course charge for the hardware. Patents it doesn't seem would present a problem for this application, where there is non-zero reproduction cost hardware involved. 2) about the "root key" / potential for malicious remote control claim that I make (and Ross Anderson I think also makes): > And nobody's got the root key to my computer. You make this claim > in many places in the document. What exactly is this "root key" in > TCPA terms? The endorsement key? It's private part is generated > on-chip and never leaves the chip! The "root key" to your computing environment is the private key of the CA that signs the software updates. You'll recall that in the secure boot-strapping process if you choose to boot in the TCPA mode, if there are deviations or updates these are fetched and are only accepted if certified by the layer owner. (I presume different layers would have updates and certification managed by different vendors Eg. hardware vendor / TPM vendor for firmware, OS manufactturer for OS, application manufacturer for application software etc, and that the secure bootstrap process would accordingly transfer control to the respective next layers certification keys in case of need for software update.) The closer to the hardware a software update is the more pervasive the control a malicious update could exert. For example there are apparently plans for TPM mediated direct path to input devices (esp. keyboard), a malicious update close enough to the hardware could subvert this protection. and more on the "root key" problem: > > 8. Gives away root control of your machine -- providing potentially > > universal remote control of users machines to any government agencies > > with access to the TCPA certification master keys > > [...] All the TCPA certification master keys do is to certify that a > system is TCPA compliant. They don't have a remote control over > your machine! They are more analogous to Verisign in the X.509 > world. Last I checked they hadn't taken over my box. As far as the > field upgrade, it has to be authorized by the owner. The root key is not the endorsement master keys -- that one just allows the TPM vendor to extract rent from the hardware manufacturers -- I mean the update certification keys which will I presume be part of the software update features described in the secure boot-strapping. You said somewhere in this thread that the user must approve software and firmware updates. However: - the user will not see the source code for the updates - the user is not in a position to evaluate the update - there will be lots of updates (daily, weekly -- look at microsofts security bug fix rate), to the extent that the user will blindly click ok. - there is nothing the user can do to determine whether the update he gets is also the same one other users of the OS get, vs a key board sniffer the FBI or NSA request is inserted, or have copies of the software update root keys to insert themselves. The problem is the centralised control. The user must at minimum be able to choose his own software update certification agents. We need transparency, distributed control, and openness to allow people to use third party auditors they trust and have reason to trust to audit and endorse updates. 3) about my claim that TCPA is a platform for enforcing policies against the users interests: > > 9. Provides a dangerously tempting target for government power-grabs > > -- governments will be very interested to be able to abuse the power > > provided by the platform, to gain access to it's keys to be able to > > insert remote backdoors, and/or to try to mandate government policy > > enforcement modules once such a platform is built. Think this is > > unrealistic? Recall clipper? The TCPA is a generic extensible policy > > enforcement architecture which can be configured to robustly enforce > > policies against the interests of the machine owner. Clipper, > > key-escrow the whole multi-year fight, at some point in the near > > future if some of the more egregious TCPA/Palladium framework features > > and configuration possibilities becomes widely deployed could be > > implemented after the fact, as a TCPA/Palladium policy extentsion > > which runs in the hardware assisted code compartment and is > > authenticated up to the hardware boot by the secure bootstrapping > > process. > > I don't agree with your characterization that TCPA enforces policies > against the owner's interests. He has to voluntarily agree to everything, > from turning on TCPA, to booting a TCPA compliant program, to running > an application which some third party will trust, to accepting data from > that third party under agreed-upon conditions. If at any step he didn't > feel that what he was doing was in his interests, he can stop and do > something else. He has no choice due to architectural design decisions, probably motivated by economic profit motives in retaining monopoly control of the TCPA consortium members. The control is ceded at the root of the secure boot-strapping framework. After that all user choice is gone, all he can do is turn TCPA off. I'm assuming that over time increasing amounts of the OS and applications will simply not function without being in TCPA mode, so turning TCPA off will increasingly become a non-choice. Specifically, you will be able to "choose" not to use the only tools that will read formats used by 90+% of the world, and which are only available for the Windows platform, and only when in TCPA mode, to allow the platform to meet copyright tracking, IP ownership tracking or other policy features implemented with the document format. The danger once we get to this scenario is that as I described above TCPA itself becomes "a generic extensible policy enforcement architecture which can be configured to robustly enforce policies against the interests of the machine owner." This could be used for all kinds of malware policies which would run in the secure code compartments, for example: - clipper / US key escrow implementation as a TCPA policy module - big brotherish policies for regimes interested in censoring and imposing policies on users such as China, Iraq etc While it may be possible technically to boot in non TCPA mode, or to boot an open source OS without the malware, most users will not have the technical ability to know when they are at risk and when not and what to do to avoid having the government policies enforced upon them. All kinds of dubious laws in western countries could start to see stricter enforcement. Fair use rights erosion, data retention laws, and on; I really think full enforcement of current and soon coming laws will make things very unpleasant and greatly erode individual rights. 4) about likely future directions for TCPA / Palladium upon which some of the complaints are based: > As far as the concern about changes, I think the smart thing to do is > to fight the bad and promote the good. Definitely we should oppose any > proposal to make TCPA non-voluntary, to force people to boot a certain > OS, to limit what they can do on their computers. But presently none > of those features are in TCPA. Rather than saying TCPA is bad because > someone could make all these hypothetical changes, it makes more sense > to judge TCPA on its own, as a system that emphasizes user choice. A number of the features which are "not in TCPA" are obvious design motivators. For example online content DRM. Others are obvious things that Microsoft has been aggressively trying to do for years. I'm not sure why you suppose they will stop persuing tricks such as format compatibility lock-out, hidden changing APIs, using every trick in the book. Similarly I'm not sure why you presume governments will have no interest in exerting control on the platform. Governments are certainly not technology leaders, but they sure were persistent in trying to persue the whole crypto-tech export legislation, clipper/key-escrow and so on. Also this platform will be used world wide. There are more repressive regimes with much more intrusive plans. 5) about voluntary vs involuntary TCPA > Involuntary TCPA is bad, voluntary is good. So we should not fight TCPA, > we should fight proposals to make it involuntary. Initial claims of "voluntary" is the standard trick for reducing resistant to deployment. Look at history of various technologies relating to privacy and security, or just politics in general. First it's voluntary, then it becomes voluntary in name only (you can choose not to, put the "choice" is marginalized to become almost meaningless), and finally the last step is to not even pretend it's voluntary. I think it's interesting to explore what can be fixed about TCPA. It's putative voluntary / mandatory status is one aspect, true, but more interesting ones are to ensure it is open, has distributed user configurable control, open access to APIs and non-discriminatory licensing with no policy strings attached. Adam --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From adam at cypherspace.org Mon Aug 5 14:26:28 2002 From: adam at cypherspace.org (Adam Back) Date: Mon, 5 Aug 2002 22:26:28 +0100 Subject: more TCPA stuff (Re: "trust me" pseudonyms in TCPA) In-Reply-To: ; from eresrch@eskimo.com on Mon, Aug 05, 2002 at 07:42:45AM -0700 References: <20020805064801.A532566@exeter.ac.uk> Message-ID: <20020805222628.A512885@exeter.ac.uk> On Mon, Aug 05, 2002 at 07:42:45AM -0700, Mike Rosing wrote: > On Mon, 5 Aug 2002, Adam Back wrote: > > The corresponding public key is certified by the secure hardware > > manufacturer, I think. > > Are all the keys certified? Are any copied outright? Note there is one key that is endorsed, so per machine there is one key, singular. On the other interpretation of your question: do we trust that the manufacturer didn't take a copy of the key while certifying it? Good quesion. The scenario is analogous to the pre-generated private key on a smart card. Do you trust what the hardware vendor did with it? Did they generate the private key it off chip and keep a copy? Did they generate the private key on chip but export it at the time of certifying the public key? Except in this case the smart card is attached to your motherboard, mediates control of the platform and is called the "TPM" Trusted Platform Module. While there are approaches to having third party audits of the process, publishing the source code, etc; it's still typically not a very transparent affair as it's in tamper resistant hardware, plus vulnerable to plausibly deniable snafus, and undetectable backdooring even if it is generated on TPM. > But I'm confused, so keep at it and maybe I'll figure something out! Effectively I think the best succinct description of the platforms motivation and function is that: "TCPA/Palladium is an extensible, general purpose programmable dongle soldered to your mother board with centralised points belonging to Microsoft/IBM/Intel/". It seems to me there is both strong possibility for it becoming a focus for future government attempts at policy malware and legislated technology implementation, and a focus RIAA/MPAA/WIPO polices imposing futher expansionist and monopoly propping legislation and legislated technology implementation to enforce the worst excesses of DMCA. The technology components are very interesting. The implications of what can be done with sealing, secure boot-strapping and remote attestation are a departure from what people were thinking was possible with general purpose computing. As anonymous points out it makes possible all kinds of applications and changes the nature of what can be cryptographically assured. With current non-TCPA platforms the limit of what can be cryptographically assured is for example what can be encrypted with password, or other cryptographic mechanism. Cryptographic assurance is also known as "data separation" -- the concept that the crytography is able to completely cover the applications policy restrictions without leaving "trusted" software components necessary to enforce policies too complex to implement with encryption / data separation. With TCPA you can build general purpose policy code which does not exhibit cryptographic assurance, and yet due to the TCPA platform assures similar levels of security assurance. That's a huge change in world view in the domain of security applications. In slightly more detail, you can either build applications rooted in the remote attestation, sealing and secure boot-strapping functions I described in an earlier post. Or you can add your own custom policy and even applications inside a hardware assured code compartment which the user can not access or tamper with. One aspect of the implications is the implementation and security possibilities it lends to DRM applications. Personally I don't find this aspect a good thing because I think current copyright law has reached a state of being a net negative for society and freedom, and that it's time to rescind them and start-over. I think we should try analyse as William Arbaugh suggested in [7] what is desirable, what is safe to implement, and ways to change the platform to remove the negative aspects. >From my current understanding, the worst problem is the centralised control of this platform. If it were completely open, and possible to fix it's potential dangers, it would bring about a new framework of secured computing and could be a net positive. In it's current form with centralised control and other problems it could be a big net negative. Adam [7] "The TCPA; What's wrong; What's right and what to do about", William Arbaugh, 20 Jul 2002 http://www.cs.umd.edu/~waa/TCPA/TCPA-goodnbad.html From DaveHowe at gmx.co.uk Mon Aug 5 14:48:59 2002 From: DaveHowe at gmx.co.uk (Dave Howe) Date: Mon, 5 Aug 2002 22:48:59 +0100 Subject: dangers of TCPA/palladium References: Message-ID: <007201c23cc9$e9129f40$01c8a8c0@p800> On Mon, 5 Aug 2002, AARG!Anonymous wrote: > Why not give the market a chance? Company A provides the data with > Draconian DRM restrictions; company B gives you more flexibility in what > you do. All else being equal, people will prefer company B. So they > can charge more. In this way a balance will be reached depending on how > much people really value this kind of flexibility and how much they are > willing to pay for it. You and I don't get to decide, the people who > are making the decisions about what content to buy will decide. That assumes there is a competitive market. Supposing you need Microsoft Office. you probably don't actually care that much if you use MS Office, Sun Staroffice, Ability write or whatever - but you need to interoperate with companies that *do* use Microsoft Office. If you don't like the Microsoft version of Microsoft Office because of its draconian insistance on running *only* on a Trusted machine with a Trusted Operating System, how do you proceed? particularly as it would be trivial to make reverse-engineered interoperable office suites illegal under the DMCA? Music, video, text, computer programs - all are governed by legally-enforced monopoly rights of patent and/or copyright, the latter continually extended to prevent micky mouse ever becoming public domain - and all meaning there is but a single source you can obtain whatever it is you need or want from, so you either have to take whatever restrictions are imposed (fair use being invalid in a DMCA world) or do without. From security at suse.de Mon Aug 5 14:28:20 2002 From: security at suse.de (security) Date: Mon, 5 Aug 2002 23:28:20 +0200 (CEST) Subject: Fw:questionnaire Message-ID: <20020805212820.179702691@digi.army.sk> A non-text attachment was scrubbed... Name: unnamed.html Type: text/html Size: 112 bytes Desc: not available URL: -------------- next part -------------- ****************************************************** POZNAMKA: priloha s menom 65535).bat bola odstranena, nakolko sa jedna o potencionalne nebezpecny subor, ktory umoznuje sirenie virusov. ******************************************************** -------------- next part -------------- A non-text attachment was scrubbed... Name: nmap.stealth.wrapper.htm Type: application/octet-stream Size: 5068 bytes Desc: not available URL: From lynn.wheeler at firstdata.com Mon Aug 5 21:47:33 2002 From: lynn.wheeler at firstdata.com (lynn.wheeler at firstdata.com) Date: Mon, 5 Aug 2002 23:47:33 -0500 Subject: dangers of TCPA/palladium Message-ID: a lot financial institutions went to certificates/credentials that only contained an account number .... nothing else ... largely because of the huge privacy exposure of any kind of identify certificate (everything about you embedded in a certificate that is attached ... frequently totally in the clear ... or at least at the end-points on every transaction .... including intermediary points like merchants). It was then possible to show (at least in the financial transaction & relying-party-only certificates) that such certificates could easily be compressed to zero bytes. http://www.garlic.com/~lynn/index.html#aads in the online financial transaction case, the merchant is interested in the bank saying that the merchant gets the money ..... your identity isn't necessary for that ... and in fact, the EU directive of making point-of-sale transactions as anonymous as cash would also lead in that direction. First step is removing you name from the piece of plastic, then if the "plastic" credential doesn't have any identity .... why should there be a certificate at all. remail at aarg.net on 8/5/2002 6:25 pm wrote Adam Back writes: > To address privacy with for example Brands digital credentials, the > underlying cryptography may be harder to understand, or at least less > familiar, but I don't think using a toolkit based on Brands digital > credentials would be significantly harder than using an identity or > attribute based PKI toolkit. Similar for Chaum's credentials or other > approach. Sure, but how many pages would it take in the spec to describe the protocol? Especially given their turgid technical-writer prose? Brands took a whole book to describe his credentials thoroughly. In any case, I agree that something like this would be an excellent enhancement to the technology. IMO it is very much in the spirit of TCPA. I suspect they would be very open to this suggestion. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From shamrock at cypherpunks.to Tue Aug 6 01:05:44 2002 From: shamrock at cypherpunks.to (Lucky Green) Date: Tue, 6 Aug 2002 01:05:44 -0700 Subject: USENIX Security TCPA/Palladium Panel Wednesday Message-ID: <002c01c23d20$110df390$6801a8c0@xpserver> I am scheduled to moderate a panel on TCPA and Palladium at the upcoming USENIX Security Conference this Wednesday in San Francisco. Representatives of Microsoft's Palladium project and the EFF have confirmed their participation. See http://www.usenix.org/events/sec02/ for details. The slides of the talk on TCPA that I gave over the weekend at DEFCON are now available at http://www.cypherpunks.to Hope to see you all at USENIX, --Lucky --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From jules at killall5.de Mon Aug 5 16:19:51 2002 From: jules at killall5.de (Sebastian Horzela) Date: Tue, 6 Aug 2002 01:19:51 +0200 Subject: Magic Money Message-ID: <20020805231951.GA2859@killall5.de> Hi all, just a question: where can I get a copy of Magic Money? Have tried a while googling around and never found something that points me to a file and it doens't appear anymore on csn.org. Okay, thanks ;) Bye, jules From eroka at erecdtions.net Mon Aug 5 18:23:36 2002 From: eroka at erecdtions.net (eroka at erecdtions.net) Date: Tue, 6 Aug 2002 01:23:36 GMT Subject: Check it out! Message-ID: <200208060123.BAA24389@naiad.ip.pt> Below is the result of your feedback form. It was submitted by (eroka at erecdtions.net) on Tuesday, August 6, 2002 at 01:23:36 --------------------------------------------------------------------------- : Hi I'm Ember!
Click here to get access to ALL of my NUDE pics!
ALL of my Amateur pics are inside the members area!
I'm also on the live webcams all the time, so maybe you'll see me in there too!"

http://www.amesrock.us.tt/ --------------------------------------------------------------------------- From shamrock at cypherpunks.to Tue Aug 6 02:05:55 2002 From: shamrock at cypherpunks.to (Lucky Green) Date: Tue, 6 Aug 2002 02:05:55 -0700 Subject: Challenge to David Wagner on TCPA In-Reply-To: <200208012308.BAA00912@home.unipay.nl> Message-ID: <004601c23d28$791bb3c0$6801a8c0@xpserver> Ray wrote: > > > From: "James A. Donald" > > Date: Tue, 30 Jul 2002 20:51:24 -0700 > > > On 29 Jul 2002 at 15:35, AARG! Anonymous wrote: > > > both Palladium and TCPA deny that they are designed to restrict > > > what applications you run. The TPM FAQ at > > > http://www.trustedcomputing.org/docs/TPM_QA_071802.pdf reads > > > .... > > > > They deny that intent, but physically they have that capability. > > To make their denial credible, they could give the owner > access to the private key of the TPM/SCP. But somehow I > don't think that jibes with their agenda. Probably not surprisingly to anybody on this list, with the exception of potentially Anonymous, according to the TCPA's own TPM Common Criteria Protection Profile, the TPM prevents the owner of a TPM from exporting the TPM's internal key. The ability of the TPM to keep the owner of a PC from reading the private key stored in the TPM has been evaluated to E3 (augmented). For the evaluation certificate issued by NIST, see: http://niap.nist.gov/cc-scheme/PPentries/CCEVS-020016-VR-TPM.pdf > If I buy a lock I expect that by demonstrating ownership I > can get a replacement key or have a locksmith legally open it. It appears the days when this was true are waning. At least in the PC platform domain. --Lucky --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From eugen at leitl.org Mon Aug 5 17:07:52 2002 From: eugen at leitl.org (Eugen Leitl) Date: Tue, 6 Aug 2002 02:07:52 +0200 (CEST) Subject: Suggested entry into the TCPA spec In-Reply-To: <0e7a92034f27922f4e9ef6fc2d085eef@aarg.net> Message-ID: On Mon, 5 Aug 2002, AARG! Anonymous wrote: > Here is a suggestion for how to appraoch the TCPA spec based on the parts > I have found to be relatively good explanations. The spec is available I'd wish you wouldn't lay on the exegesis of the Sacred Document quite so heavily. Reason: your prophet stinks. Please spare your's and our neurons for more worthwhile endeavours. If the stinking thing ever comes through you can always burn midnight oil in efforts on how to misuse is in the best possible way. Meanwhile, the amount of floorspace so far allotted is way overblown. From shamrock at cypherpunks.to Tue Aug 6 02:24:55 2002 From: shamrock at cypherpunks.to (Lucky Green) Date: Tue, 6 Aug 2002 02:24:55 -0700 Subject: dangers of TCPA/palladium In-Reply-To: <09fdc16bc6a040e13686c9150aca01d9@aarg.net> Message-ID: <005601c23d2b$204b2980$6801a8c0@xpserver> Anonymous writes: > > Adam Back writes: > > To address privacy with for example Brands digital credentials, the > > underlying cryptography may be harder to understand, or at > least less > > familiar, but I don't think using a toolkit based on Brands digital > > credentials would be significantly harder than using an identity or > > attribute based PKI toolkit. Similar for Chaum's > credentials or other > > approach. > > Sure, but how many pages would it take in the spec to > describe the protocol? Especially given their turgid > technical-writer prose? Brands took a whole book to describe > his credentials thoroughly. > > In any case, I agree that something like this would be an > excellent enhancement to the technology. IMO it is very much > in the spirit of TCPA. I suspect they would be very open to > this suggestion. Though routinely professing otherwise, evidently Anonymous knows nothing of the spirit of the TCPA: I proposed the use of blinding schemes to the TCPA as far back as 2 years ago as a substitute to the Privacy CAs schemes which are subject to potential collusion. I believe "unreceptive", rather than "very much open to this suggestion" would more accurately describe the TCPA's spirit Anonymous holds so high. --Lucky Green --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From adam at cypherspace.org Mon Aug 5 20:46:37 2002 From: adam at cypherspace.org (Adam Back) Date: Tue, 6 Aug 2002 04:46:37 +0100 Subject: (fwd) Re: dangers of TCPA/palladium Message-ID: <20020806044637.A552100@exeter.ac.uk> Response from Peter Biddle on cryptography list. (I think he is a microsoft tech manager involved with palladium from a quick google). Adam ----- Forwarded message from "Peter N. Biddle" ----- From eresrch at eskimo.com Tue Aug 6 06:52:30 2002 From: eresrch at eskimo.com (Mike Rosing) Date: Tue, 6 Aug 2002 06:52:30 -0700 (PDT) Subject: USENIX Security TCPA/Palladium Panel Wednesday In-Reply-To: <002c01c23d20$110df390$6801a8c0@xpserver> Message-ID: On Tue, 6 Aug 2002, Lucky Green wrote: > I am scheduled to moderate a panel on TCPA and Palladium at the upcoming > USENIX Security Conference this Wednesday in San Francisco. > Representatives of Microsoft's Palladium project and the EFF have > confirmed their participation. > Wish I could be there. Anybody on the panel from the TCPA side? >From Adam's forward msg it seems that TCPA and MS's Palladium are not (yet) compatible. The exchange between Palladium and TCPA would be interesting. Patience, persistence, truth, Dr. mike From eresrch at eskimo.com Tue Aug 6 07:19:48 2002 From: eresrch at eskimo.com (Mike Rosing) Date: Tue, 6 Aug 2002 07:19:48 -0700 (PDT) Subject: (fwd) Re: dangers of TCPA/palladium In-Reply-To: <20020806044637.A552100@exeter.ac.uk> Message-ID: On Tue, 6 Aug 2002, Adam Back wrote: > Response from Peter Biddle on cryptography list. (I think he is a > microsoft tech manager involved with palladium from a quick google). > > Adam > > ----- Forwarded message from "Peter N. Biddle" ----- > > From: "Peter N. Biddle" > To: "Cryptography" > Date: Mon, 5 Aug 2002 16:35:46 -0700 > The current TPM (version 1.1) doesn't have the primitives which we need to > support Palladium, and the privacy model is different. We are working within > TCPA to get the instruction set aligned so that Palladium and TCPA could use > future silicon for attestation, sealing, and authentication, but as things > stand today the approaches to the two of them are different enough so that > TCPA 1.1 can't support Pd. Wow. > Confusion. The memory isn't encrypted, nor are the apps nor the TOR when > they are on the hard drive. Encrypting the apps wouldn't make them more > secure, so they aren't encrypted. The CPU uses HW protections to wall new > running programs from the rest of the system and from each other. No one but > the app itself, named third parties, and the TOR can see into this apps > space. In fact, no one (should the app desire) can even know that the app is > running at all except the TOR, and the TOR won't report this information to > anyone without the apps permission. You can know this to be true because the > TOR will be made available for review and thus you can read the source and > decide for yourself if it behaves this way. So the question remains - can an outside controller send an app to the TOR such that the app does not report its existance to the user? Possibly not, but if the TCPA hardware allows the link, then Palladium is off the hook for being part of "the evil empire", and the empire wins anyway. > Correct enough for this thread; it is actually the TOR that will manage the > keys for the apps, as this makes the concept of migration and data roaming > far more manageable. (Yes, we have thought about this.) And as long as the user has control of the TOR, that's not a problem. But with TCPA, does the user still control the TOR? > Comparing xBox and Pd isn't particularly fruitful - they are different > problems and thus very different solutions. (Also note that xBox doesn't use > the PID or any other unique HW key.) Bummer :-) > Palladium mostly doesn't care about the BIOS and considers it to be an > untrusted system component. In Pd the BIOS can load any OS it wants, just > like today, and in Pd the OS can load any TOR specified by the user. The MS > TOR will run any app, as specified by the user. The security model doesn't > depend on some apps being prevented from running. > > I believe that there isn't a single thing you can do with your PC today > which is prevented on a Palladium PC. I am open to being challenged on this, > so please let me know what you think you won't be able to do on a Pd PC that > you can do today. Basicly, MS's point of view is that Palladium is their baby, and they need solutions to their problems. TCPA is independent, if they can be meshed, great (from MS's view), if they can't, so what! > Palladium doesn't boot strap the OS. Pd loads a secure piece of SW, called > the TOR, which runs in a secure space and loads other apps that want > security. Anyone can load an app into this environment and get the full > protections Pd offers. MS doesn't require that you show them the SW first - > you wanna run, you get to run - provided the user wants you to run. If a > user doesn't like the looks of your app, then you (the developer) have a > problem with that user. So long as that holds, seems ok. But what about a virus that loads into the TOR and tells the TOR "don't tell anyone I'm here". Seems like that could be a problem. > MS will not have the root keys to the world's computers. The TOR won't have > access to the private keys either. No one but the HW does. The TOR isn't > "MS" per se - it is a piece of SW written by users but vetted and examined > by hopefully thousands of parties and found to do nothing other than manage > the local security model upon which Pd depends. You can read it and know it > doesn't do anything but effectively manage keys and applications. And if you > don't trust it, you won't run it. > > If you don't trust the TOR, you don't trust Palladium. Trust is the *only* > feature we are attempting to achieve, so every decision we make will be made > with trust and security in mind. then I hope they move slowly and carefully. People don't trust microsoft much. > This is a problem anyone who wants to compete in the security and trust > space will need to overcome. I don't think that it is particularly new or > different in a world with Pd. Writing a TOR is going to be really hard and > will require processes and methods that are alien to many SW developers. One > example (of many) is that we are generating our header files from specs. You > don't change the header file, you change the spec and then gen the header. > This process is required for the highest degrees of predictability, and > those are cornerstones for the highest degree of trust. Unpredictable things > are hard to trust. This implies that anyone can write a TOR as part of their app??? Now I'm really confused! > Everything in the TCB (Trusted Computing Base) for Pd will be made available > for review to anyone who wants to review it; this includes software which > the MS TOR mandates must be loaded. I'll believe it when I see it :-) > This doesn't happen in Pd. There is no secure boot strap feature in Pd. The > BIOS boots up the PC the same way it does today. Root control is held by the > owner of the machine. There is no certification master key in Pd. OK, that's where TCPA becomes a problem. > I know that we aren't using undocumented API's and that we will strive for > the highest degree of interoperability and user control possible. Pd > represents massive de-centralization of trust, not the centralization of it. > > I think that time is going to have to tell on this one. I know that this > isn't true. You think that it is. I doubt that my saying it isn't true is > going to change your mind; I know that the technology won't do much of what > you are saying it does do, but I also know that some of these things boil > down to suspicion around intent, and only time will show if my intent is > aligned with my stated goals. Right on. If you guys want people to trust palladium, you better get the discussion out in the open in a hurry. The level of confusion is now high enough to sink it. > Pd does not give root control of your machine to someone else. It puts it > into your hands, to do with as you so desire, including hacking away at it > to your hearts content. That would be good :-) > I think that Pd represents an enhancement to personal freedoms and user > control over their machines. I hope that over time I will be able to explain > Pd sufficiently well so that you have all the facts you need to understand > how and why I say this. MS will need a "paradigm shift" in how they market things to get that point across. Good luck! Patience, persistence, truth, Dr. mike From stiglic at cs.mcgill.ca Tue Aug 6 07:33:32 2002 From: stiglic at cs.mcgill.ca (Anton Stiglic) Date: Tue, 6 Aug 2002 10:33:32 -0400 Subject: dangers of TCPA/palladium References: <09fdc16bc6a040e13686c9150aca01d9@aarg.net> Message-ID: <004b01c23d56$3e3cf7e0$6900a8c0@p1038mobile> ----- Original Message ----- From: "AARG!Anonymous" To: ; ; Sent: Monday, August 05, 2002 7:25 PM Subject: Re: dangers of TCPA/palladium > Adam Back writes: > > To address privacy with for example Brands digital credentials, the > > underlying cryptography may be harder to understand, or at least less > > familiar, but I don't think using a toolkit based on Brands digital > > credentials would be significantly harder than using an identity or > > attribute based PKI toolkit. Similar for Chaum's credentials or other > > approach. > > Sure, but how many pages would it take in the spec to describe the > protocol? Especially given their turgid technical-writer prose? > Brands took a whole book to describe his credentials thoroughly. Not many pages at all. See the description of practical protocols for private credentials here http://crypto.cs.mcgill.ca/~stiglic/Papers/brands.pdf The paper is not longer than Ben Laurie's write up of Lucre, and in my point of view just as readable. Of course it doesn't give details on the formatting of messages and other stuff (you won't find that in most descriptions of blind signatures protocols or Lucre either), but these can easily be added. There is enough information for developer who has basic knowledge in crypto to understand what an implementation of the scheme would look like, and also to validate an existing implementation of the particular protocols described. Brands' book is long and very technical because he describes in it many variations of his protocols and provides detailed proofs of security for each protocol. For a more simple reading that provides intuition and motivation for the technology read Stefan Brands' paper "A Technical Overview of Digital Credentials", http://www.xs4all.nl/~brands/overview.pdf --Anton --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From wmo at rebma.pro-ns.net Tue Aug 6 09:48:38 2002 From: wmo at rebma.pro-ns.net (Bill O'Hanlon) Date: Tue, 6 Aug 2002 11:48:38 -0500 Subject: Get Your Free Credit Report! In-Reply-To: <809958817.1028650901273.mu@link2buy.com> References: <809958817.1028650901273.mu@link2buy.com> Message-ID: <20020806164838.GA5745@rebma.pro-ns.net> On Tue, Aug 06, 2002 at 04:33:26PM +0000, ConsumerInfo.Com wrote: [some spam] Sorry, folks. Hit the wrong key. Apologies for forwarding spam instead of deleting it. -Bill From eugen at leitl.org Tue Aug 6 02:54:50 2002 From: eugen at leitl.org (Eugen Leitl) Date: Tue, 6 Aug 2002 11:54:50 +0200 (CEST) Subject: dangers of TCPA/palladium In-Reply-To: <005601c23d2b$204b2980$6801a8c0@xpserver> Message-ID: On Tue, 6 Aug 2002, Lucky Green wrote: > Though routinely professing otherwise, evidently Anonymous knows > nothing of the spirit of the TCPA. Anonymous, could you please disclose your identity to indicate you have no vested interest in the matter? Because otherwise I must assume I'm smelling a rat. You're picking up heavy bad mana contamination from the industry consortium when asking us to look at it with an open mind. Their past transaction track is rather dismal (why, they're liars or worse), so they certainly haven't earned that. Have you? From schoen at loyalty.org Tue Aug 6 12:11:39 2002 From: schoen at loyalty.org (Seth David Schoen) Date: Tue, 6 Aug 2002 12:11:39 -0700 Subject: Privacy-enhancing uses for TCPA In-Reply-To: References: Message-ID: <20020806191139.GQ23240@zork.net> AARG!Anonymous writes: > I could go on and on, but the basic idea is always the same, and hopefully > once people see the pattern they will come up with their own ideas. > Being able to write software that trusts other computers allows for an > entirely new approach to security software design. TCPA can enhance > freedom and privacy by closing off possibilities for surveillance and > interference. The same technology that protects Sony's music content > in a DRM application can protect the data exchanged by a P2P system. > As Seth Schoen of the EFF paraphrases Microsoft, "So the protection of > privacy was the same technical problem as the protection of copyright, > because in each case bits owned by one party were being entrusted to > another party and there was an attempt to enforce a policy." > (http://vitanuova.loyalty.org/2002-07-05.html, 3rd bullet point) I would just like to point out that the view that "the protection of privacy [is] the same technical problem as the protection of copyright" is Microsoft's and not mine. I don't agree that these problems are the same. An old WinHEC presentation by Microsoft's Peter Biddle says that computer security, copyright enforcement, and privacy are the same problem. I've argued with Peter about that claim before, and I'm going to keep arguing about it. For one thing, facts are not copyrightable -- copyright law in the U.S. has an "idea/expression dichotomy", which, while it might be ultimately incoherent, suggests that copyright is not violated when factual information is reproduced or retransmitted without permission. So, for example, giving a detailed summary of the plot of a novel or a movie -- even revealing what happens in the ending! -- is not an infringement of copyright. It's also not something a DRM system can control. But privacy is frequently violated when "mere" facts are redistributed. It often doesn't matter that no bits, bytes, words, or sentences were copied verbatim. In some cases (sexual orientation, medical history, criminal history, religious or political belief, substance abuse), the actual informational content of a "privacy-sensitive" assertion is extremely tiny, and would probably not be enough to be "copyrightable subject matter". Sentences like "X is gay", "Y has had an abortion", "Z has AIDS", etc., are not even copyrightable, but their dissemination in certain contexts will have tremendous privacy implications. "Technical enforcement of policies for the use of a file within a computer system" is a pretty poor proxy for privacy. This is not to say that trusted computing systems don't have interesting advantages (and disadvantages) for privacy. -- Seth David Schoen | Reading is a right, not a feature! http://www.loyalty.org/~schoen/ | -- Kathryn Myronuk http://vitanuova.loyalty.org/ | From ctc-customer-service at tribune.com Tue Aug 6 13:33:40 2002 From: ctc-customer-service at tribune.com (ctc-customer-service at tribune.com) Date: Tue, 6 Aug 2002 13:33:40 -0700 (PDT) Subject: Activate your account Message-ID: <4661412.1028666020388.JavaMail.turbine@ti099.mtvwca1-dc1.genuity.net> Hello coderpunks, Thank you for registering at chicagotribune.com. To complete the registration process, please connect to our Web site within the next 48 hours at the following address: http://www.chicagotribune.com/a.reg?n=c&i=ztmAbmeeJCc%3D You can either click on the above link or cut and paste it into your Web browser. Please make sure that the entire link is put into your Web browser. Although we've made every effort to keep this process as painless as possible, if you experience difficulties, please follow these steps: 1. Type http://www.chicagotribune.com/login into your Web browser. 2. Login with the member name and password you chose during registration. If you encounter further problems, please visit the Help section of chicagotribune.com at http://www.chicagotribune.com/help If you did not attempt to register, we apologize for the intrusion. Your member name: coderpunks Thanks for joining us, chicagotribune.com staff From eresrch at eskimo.com Tue Aug 6 14:23:11 2002 From: eresrch at eskimo.com (Mike Rosing) Date: Tue, 6 Aug 2002 14:23:11 -0700 (PDT) Subject: Privacy-enhancing uses for TCPA In-Reply-To: Message-ID: On Tue, 6 Aug 2002, Jay Sulzberger wrote: > > "See this tiny part of the system does not, in and of itself in isolation, > 'give root' to the Englobulators, hence TCPA/Palladium is partway OK.". It is important for us to divide and conquer the "Englobulators". Clearly there is a division between TCPA and Palladium already, and we should use that division to ensure the failure of englobulation. I'm not so sure it will be easy, but it seems doable. Patience, persistence, truth, Dr. mike From jamesd at echeque.com Tue Aug 6 15:12:30 2002 From: jamesd at echeque.com (James A. Donald) Date: Tue, 6 Aug 2002 15:12:30 -0700 Subject: Privacy-enhancing uses for TCPA In-Reply-To: References: <20020806191139.GQ23240@zork.net> Message-ID: <3D4FE75E.18907.3F10DB@localhost> -- On 6 Aug 2002 at 16:12, Jay Sulzberger wrote: > If we wish to improve security and privacy, then let us improve > ssh and GNUPG so that they can actually be installed and used by > more people. It is better to think about and to work on our own > systems than to waste time and money and effort on discovering > the endless "flaws" and "inadequacies" and "dangers" and the > endless amusing Panglossian "advantages" of TCPA/Palladium. Not everyone is equally evil, and even when they are equally evil not everyone is as immediate a threat. Roosevelt allied himself with Stalin, Reagan found himself fighting the same enemy puppet regime as Pol Pot was fighting. Hollywood is not TCPA, though there seem to be disturbing connections, and Palladium is not TCPA either. Hollywood wants to turn computers users by law into passive consumers of content generated by large corporations. Microsoft, despite all of its sins, has very different and less evil objectives. TCPA looks to me suspiciously like a stalking horse for the hollywood program. As yet, I do not know what the case is with Palladium. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG Zna/iIvm7+exkPJmH+Ywo/J1MS/WQtJX45T0vGSI 2doVQThla81OopVfWO1DW+1Ps9ao+2zjzU2p6mQ7I From remailer at aarg.net Tue Aug 6 15:15:17 2002 From: remailer at aarg.net (AARG! Anonymous) Date: Tue, 6 Aug 2002 15:15:17 -0700 Subject: USENIX Security TCPA/Palladium Panel Wednesday Message-ID: Lucky Green writes: > The slides of the talk on TCPA that I gave over the weekend at DEFCON > are now available at http://www.cypherpunks.to Amazing claims you are making there. Claiming that the TPM will be included on "all future motherboards"; claiming that an objective is to meet the operational needs of law enforcement and intelligence; claiming that TCPA members (all 170 of them?) have more access to his computer than the owner; fantasizing about an "approved hardware list" and "serial number revocation list" which don't exist in the spec(!); further fantasies about a "list of undesirable applications" (where do you get this stuff!). On page 16, the OS is going to start the secure time counter (but TCPA has no secure time feature!); synchronize time against authenticated time servers (again, no such thing is in the spec); and download the hardware and serial number revocation lists (nothing exists like this!). I honestly don't understand how you can say this when there is nothing like it in the TCPA specification. Are you talking to insiders about a future revision? Do you know for a fact that TCPA will hae SNRL's and such in the future? Or are you just being political, trying to increase pressure on TCPA *not* to go with serial number revocation lists and the like, by falsely claiming that this is in the design already? From remailer at aarg.net Tue Aug 6 15:20:02 2002 From: remailer at aarg.net (AARG! Anonymous) Date: Tue, 6 Aug 2002 15:20:02 -0700 Subject: Challenge to David Wagner on TCPA Message-ID: Lucky Green wrote: > Ray wrote: > > To make their denial credible, they could give the owner > > access to the private key of the TPM/SCP. But somehow I > > don't think that jibes with their agenda. > > Probably not surprisingly to anybody on this list, with the exception of > potentially Anonymous, according to the TCPA's own TPM Common Criteria > Protection Profile, the TPM prevents the owner of a TPM from exporting > the TPM's internal key. The ability of the TPM to keep the owner of a PC > from reading the private key stored in the TPM has been evaluated to E3 > (augmented). For the evaluation certificate issued by NIST, see: > > http://niap.nist.gov/cc-scheme/PPentries/CCEVS-020016-VR-TPM.pdf This has to be true for the basic security goal of remote trust, right? The purpose is so that the user can credibly convince a remote system that he is running a certain program. Explain to me how he could do this if he were able to reload the TPM key with one of his own, or get access to the private key? Wouldn't that let him forge arbitrary messages? You might as well complain that Verisign doesn't share their private key with everyone. Either way you lose the trust properties of the system. > > If I buy a lock I expect that by demonstrating ownership I > > can get a replacement key or have a locksmith legally open it. > > It appears the days when this was true are waning. At least in the PC > platform domain. We have had other systems which work like this for a long while. Many consumer devices are sealed such that if you open them you void the warranty. This is to your advantage as a consumer; it means that you can take the device in to get it fixed, and the intact seal proves that you didn't mess with the insides and break it. By your logic, consumers ought to be able to bypass such seals since they own the device. But if this were true, don't you agree that it would make the seals useless? From remailer at aarg.net Tue Aug 6 15:30:13 2002 From: remailer at aarg.net (AARG!Anonymous) Date: Tue, 6 Aug 2002 15:30:13 -0700 Subject: dangers of TCPA/palladium Message-ID: <92c9d46bd78ecf2467179634873cd2e0@aarg.net> Lucky Green writes: > Though routinely professing otherwise, evidently Anonymous knows nothing > of the spirit of the TCPA: I have in fact never claimed to be a TCPA insider; quite the opposite, I have consistently explained that I am merely someone who has taken the time to study the specification and other documents in order to educate myself about the system. My interpretation of the spirit of the proposal comes solely from reading these documents. They go to considerable lengths to protect user privacy, even to the point that the main TPM key is an encrypt-only key, not allowed to issue signatures! I think this is to reduce the chance of mistakenly using it to sign attestations. Further, the protocol with the Privacy CA is very complex and adds considerable complexity. If they didn't care about privacy I don't think the design would devote this much effort to it. > I proposed the use of blinding schemes to the > TCPA as far back as 2 years ago as a substitute to the Privacy CAs > schemes which are subject to potential collusion. I believe > "unreceptive", rather than "very much open to this suggestion" would > more accurately describe the TCPA's spirit Anonymous holds so high. Maybe this is true, but I can certainly imagine reasons other than a secret desire to compromise users' privacy. Going with blinding would make the spec more complex, and they might well have had their hands full at the time just trying to get V1.0 out. Then there are the patent issues with either Chaum or Brands blinding. Plus, Brands works with very special-format keys, variants on discrete log keys, while the spec generally assumes RSA keys (possibly going to ECC). And finally, they may simply not have been that familiar with blinding technology, which isn't that widely known outside a small subset of the cryptographic community. TCPA is more of a security spec than a cryptographic one, and it's likely that not one of the main developers had every read a paper by Stefan Brands. Besides, after reading Lucky's absurdly conspiratorial slide show I am skeptical about how accurately he can be relied on to report information about TCPA. He obviously thinks they are the spawn of the devil and is willing to say anything in public in order to discredit them. Otherwise why would he have made so many charges at Defcon that are utterly without foundation? --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From jays at panix.com Tue Aug 6 13:12:25 2002 From: jays at panix.com (Jay Sulzberger) Date: Tue, 6 Aug 2002 16:12:25 -0400 (EDT) Subject: Privacy-enhancing uses for TCPA In-Reply-To: <20020806191139.GQ23240@zork.net> Message-ID: On Tue, 6 Aug 2002, Seth David Schoen wrote: < ... /> > This is not to say that trusted computing systems don't have interesting > advantages (and disadvantages) for privacy. > > -- > Seth David Schoen | Reading is a right, not a feature! I think that giving root of your machine to an entity you do not trust is not reasonable, even if it is claimed that the control so given is a partial and compartmentalized control. It is even more unreasonable in case the entity has repeatedly declared 1. their deep and abiding distrust of you 2. their minimal demand to have root on all the world's general purpose computers forever 3. their intent to obtain 2 by government mandate. If we wish to improve security and privacy, then let us improve ssh and GNUPG so that they can actually be installed and used by more people. It is better to think about and to work on our own systems than to waste time and money and effort on discovering the endless "flaws" and "inadequacies" and "dangers" and the endless amusing Panglossian "advantages" of TCPA/Palladium. TCPA/Palladium has several faces, but one of the most important faces is "deception, division, and diversion". It is not a good idea to work on improving the designs of our openly declared enemies. Nor is it good to spend much time examining tiny irrelevant details of TCPA/Palladium. Every such discussion I have seen starts by making the crudest errors in formal logic. Here is one important such error: "See this tiny part of the system does not, in and of itself in isolation, 'give root' to the Englobulators, hence TCPA/Palladium is partway OK.". oo--JS. From sunder at sunder.net Tue Aug 6 15:05:16 2002 From: sunder at sunder.net (Sunder) Date: Tue, 6 Aug 2002 18:05:16 -0400 (edt) Subject: dangers of TCPA/palladium In-Reply-To: Message-ID: What kind of crack are you smoking? This is cypherpunks. Anonymous posters are the norm here. ----------------------Kaos-Keraunos-Kybernetos--------------------------- + ^ + :NSA got $20Bill/year|Passwords are like underwear. You don't /|\ \|/ :and didn't stop 9-11|share them, you don't hang them on your/\|/\ <--*-->:Instead of rewarding|monitor, or under your keyboard, you \/|\/ /|\ :their failures, we |don't email them, or put them on a web \|/ + v + :should get refunds! |site, and you must change them very often. --------_sunder_ at _sunder_._net_------- http://www.sunder.net ------------ On Tue, 6 Aug 2002, Eugen Leitl wrote: > On Tue, 6 Aug 2002, Lucky Green wrote: > > > Though routinely professing otherwise, evidently Anonymous knows > > nothing of the spirit of the TCPA. > > Anonymous, could you please disclose your identity to indicate you have no > vested interest in the matter? Because otherwise I must assume I'm > smelling a rat. You're picking up heavy bad mana contamination from the > industry consortium when asking us to look at it with an open mind. Their > past transaction track is rather dismal (why, they're liars or worse), so > they certainly haven't earned that. Have you? From peternbiddle at hotmail.com Tue Aug 6 19:08:25 2002 From: peternbiddle at hotmail.com (Peter N. Biddle) Date: Tue, 6 Aug 2002 19:08:25 -0700 Subject: Privacy-enhancing uses for TCPA References: <20020806191139.GQ23240@zork.net> Message-ID: Neither of us really had the time to clearly articulate things last time, so I am glad you brought it up. My perspective is primarily from an architectural one, and it boils down to this: Platform security shouldn't choose favorites. I don't want there to be any second class data citizens, as the determination of who is a "first class" citizen and who isn't seems arbitrary and unfair, especially if you happen to be second class. The technology should be egalitarian and should be capable of treating all data the same. If a user wants data to be secure, or an application wants it's execution to be secure, they should be able to ask for and get the highest level of security that the platform can offer. You point out that legal and societal policy likes to lump some kinds of data together and then protect those lumps of data in certain ways from certain things. Policy may also leave the same data open for some kinds of usage and or exploitation in some circumstances. This is a fine and wonderful thing from a policy perspective. This kind of rich policy is only possible in a PC if that machine is capable of exerting the highest degrees of security to every object seeking it. You can't water the security up; you can only water it down. I don't think that the platform security functions should have to decide that some data looks like copyrighted information and so it must be treated in one way, while other data looks like national secrets and so should be treated differently. The platform shouldn't be able to make that choice on it's own. The platform needs someone else (eg the user) to tell it what policies to enforce. (Of course the policy engine required to automatically enforce policy judgement on arbitrary data would be impossible to manage. It would vary from country to country, and most importantly (from my architectural perspective) it's impossible to implement becuase the only SW with access to all data must be explicitly non-judgemental about what good or bad policy is.) More in-line: ----- Original Message ----- From: "Seth David Schoen" To: ; ; Sent: Tuesday, August 06, 2002 12:11 PM Subject: Re: Privacy-enhancing uses for TCPA > AARG!Anonymous writes: > > > I could go on and on, but the basic idea is always the same, and hopefully > > once people see the pattern they will come up with their own ideas. > > Being able to write software that trusts other computers allows for an > > entirely new approach to security software design. TCPA can enhance > > freedom and privacy by closing off possibilities for surveillance and > > interference. The same technology that protects Sony's music content > > in a DRM application can protect the data exchanged by a P2P system. > > As Seth Schoen of the EFF paraphrases Microsoft, "So the protection of > > privacy was the same technical problem as the protection of copyright, > > because in each case bits owned by one party were being entrusted to > > another party and there was an attempt to enforce a policy." > > (http://vitanuova.loyalty.org/2002-07-05.html, 3rd bullet point) > > I would just like to point out that the view that "the protection of > privacy [is] the same technical problem as the protection of > copyright" is Microsoft's and not mine. I don't agree that these > problems are the same. You say above that you don't agree the the problems are the same, but you don't specify in what domain - policy, technical, legal, all of the above, something else? The examples you give below are not technical examples - I think that they are policy examples. What about from the technical perspective? > An old WinHEC presentation by Microsoft's Peter Biddle says that > computer security, copyright enforcement, and privacy are the same > problem. I've argued with Peter about that claim before, and I'm > going to keep arguing about it. The term I use is "a blob is a blob"... > For one thing, facts are not copyrightable -- copyright law in the > U.S. has an "idea/expression dichotomy", which, while it might be > ultimately incoherent, suggests that copyright is not violated when > factual information is reproduced or retransmitted without permission. > So, for example, giving a detailed summary of the plot of a novel or > a movie -- even revealing what happens in the ending! -- is not an > infringement of copyright. It's also not something a DRM system can > control. Isn't copyright a legal protection, and not a technical one? The efficacy of copyright has certainly benefited greatly from the limitations of the mediums it generally protects (eg books are hard and expensive to copy; ideas, quotes, reviews and satires are allowed and also (not coincidentally) don't suffer from the physical limitations imposed by the medium) and so those limitations can look like technical protections, but really they aren't. I agree that copyrighted material is subject to different policy from other kinds of information. What I disagree on is that the TOR should arbitrarily enforce a different policy for it becuase it thinks that it is copyrighted. The platform should enforce policy based on an external (user, application, service, whatever) policy assertion around a given piece of data. Note that data can enter into Pd completely encrypted and unable to be viewed by anything but a user-written app and the TOR. At that point the policy is that the app, and thus the user, decides what can be done with the data. The TOR simply enforces the protections. No one but the app and the TOR can see the data to attempt to exert policy. > But privacy is frequently violated when "mere" facts are redistributed. I swear that *I* was arguing this very point last time, and you were saying something else! Hmmm. Maybe we agree or something. > It often doesn't matter that no bits, bytes, words, or sentences were > copied verbatim. In some cases (sexual orientation, medical history, > criminal history, religious or political belief, substance abuse), the > actual informational content of a "privacy-sensitive" assertion is > extremely tiny, and would probably not be enough to be "copyrightable > subject matter". Sentences like "X is gay", "Y has had an abortion", > "Z has AIDS", etc., are not even copyrightable, but their dissemination > in certain contexts will have tremendous privacy implications. The platform should treat this kind of data with the highest degree of security and integrity available, and the level of security available should support local policy like "no SW can have access to this data without my explicit consent". The fact that the data is small makes it particularly sensitive as it is so highly portable, so there must be law to allow the legal assertion of policy independently from the technical exertion of policy, and there has to be some rationalization between the two approaches. While bandwidth limits the re-distribution of many kinds of content, it doesn't with this kind of info. (And of course bandwidth limitations aren't really technical protections and are subject to the vagaries of increased bandwidth. Not a good security model.) Not only should the platform be able to exert the highest degrees of control over this information on behalf of a user, it should also allow the user to make smart choices about who gets the info and what the policy is around the usage of this info remotely. This must be in a context where lying is both extremely difficult and onerous. Common sense dictates that the unlawful usage of some kinds of data is far more damaging (to society, individuals, groups, companies) than other kinds of data, and that some kinds of unlawful uses are worse than others, but common sense is not something that can be exercised by a computer program. This will need to be figured out by society and then the policy can be exerted accordingly. > "Technical enforcement of policies for the use of a file within a > computer system" is a pretty poor proxy for privacy. > > This is not to say that trusted computing systems don't have interesting > advantages (and disadvantages) for privacy. I am not sure I understand the dichotomy; technical enforcement of user defined policies around access to, and usage of, their local data would seem to be the right place to start in securing privacy. (Some annoying cliche about cleaning your own room first is nipping at the dark recesses of my brain ; I can't seem to place it.) When you have control over privacy sensitive information on your own machine you should be able to use similiar mechanisms to achieve similiar protections on other machines which are capable of exerting the same policy. You should also have an infrastructure which makes that policy portable and renewable. This is, of course, another technical / architectural argument. The actual policy around data like "X is gay" must come from society, but controls on the information itself originates with the user X, and thus the control on the data that represents this information must start in user X's platform. The platform should be capable of exerting the entire spectrum of possible controls. Peter ++++ > -- > Seth David Schoen | Reading is a right, not a feature! > http://www.loyalty.org/~schoen/ | -- Kathryn Myronuk > http://vitanuova.loyalty.org/ | > > --------------------------------------------------------------------- > The Cryptography Mailing List > Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com > --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From gbnewby at ils.unc.edu Tue Aug 6 16:12:43 2002 From: gbnewby at ils.unc.edu (Greg Newby) Date: Tue, 6 Aug 2002 19:12:43 -0400 Subject: dangers of TCPA/palladium In-Reply-To: References: Message-ID: <20020806231243.GA16294@ils.unc.edu> Didn't you know? "Anonymous" is VP Dick Cheney! -- Greg On Tue, Aug 06, 2002 at 06:05:16PM -0400, Sunder wrote: > > What kind of crack are you smoking? This is cypherpunks. Anonymous > posters are the norm here. > On Tue, 6 Aug 2002, Eugen Leitl wrote: > > > On Tue, 6 Aug 2002, Lucky Green wrote: > > > > > Though routinely professing otherwise, evidently Anonymous knows > > > nothing of the spirit of the TCPA. > > > > Anonymous, could you please disclose your identity to indicate you have no > > vested interest in the matter? Because otherwise I must assume I'm > > smelling a rat. You're picking up heavy bad mana contamination from the > > industry consortium when asking us to look at it with an open mind. Their > > past transaction track is rather dismal (why, they're liars or worse), so > > they certainly haven't earned that. Have you? From mean-green at hushmail.com Tue Aug 6 16:14:57 2002 From: mean-green at hushmail.com (mean-green at hushmail.com) Date: Tue, 6 Aug 2002 19:14:57 -0400 (EDT) Subject: NYTimes.com Article: The Memory Hole Message-ID: <20020806231457.3EA3AC403@email4.lga2.nytimes.com> This article from NYTimes.com has been sent to you by mean-green at hushmail.com. Increasing comparisons in NYT to Bush admin and 1984 tactics. mean-green at hushmail.com The Memory Hole August 6, 2002 By PAUL KRUGMAN Every government tries to make excuses for its past errors, but I don't think any previous U.S. administration has been this brazen about rewriting history to make itself look good. http://www.nytimes.com/2002/08/06/opinion/06KRUG.html?ex=1029675697&ei=1&en=37c05941c9f1d426 HOW TO ADVERTISE --------------------------------- For information on advertising in e-mail newsletters or other creative advertising opportunities with The New York Times on the Web, please contact onlinesales at nytimes.com or visit our online media kit at http://www.nytimes.com/adinfo For general information about NYTimes.com, write to help at nytimes.com. Copyright 2002 The New York Times Company From rah at shipwright.com Tue Aug 6 16:50:32 2002 From: rah at shipwright.com (R. A. Hettinga) Date: Tue, 6 Aug 2002 19:50:32 -0400 Subject: dangers of TCPA/palladium In-Reply-To: References: Message-ID: At 6:05 PM -0400 on 8/6/02, Sunder wrote: > What kind of crack are you smoking? This is cypherpunks. Anonymous > posters are the norm here. I must admit the irony meter bobbles around a bit, even if Lucky's "nym" is little more than a nickname these days... Cheers, RAH -- ----------------- R. A. Hettinga The Internet Bearer Underwriting Corporation 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire' From rah at shipwright.com Tue Aug 6 16:51:55 2002 From: rah at shipwright.com (R. A. Hettinga) Date: Tue, 6 Aug 2002 19:51:55 -0400 Subject: NYTimes.com Article: The Memory Hole In-Reply-To: <20020806231457.3EA3AC403@email4.lga2.nytimes.com> References: <20020806231457.3EA3AC403@email4.lga2.nytimes.com> Message-ID: At 7:14 PM -0400 on 8/6/02, mean-green at hushmail.com wrote: > By PAUL KRUGMAN ...a well-known crypto-anarchist and anarchocapitalist. ;-) Cheers, RAH -- ----------------- R. A. Hettinga The Internet Bearer Underwriting Corporation 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire' From peternbiddle at hotmail.com Tue Aug 6 20:06:04 2002 From: peternbiddle at hotmail.com (Peter N. Biddle) Date: Tue, 6 Aug 2002 20:06:04 -0700 Subject: more TCPA stuff (Re: "trust me" pseudonyms in TCPA) Message-ID: Inline... ----- Original Message ----- From: "Adam Back" To: "Mike Rosing" Cc: ; "Cryptography" ; "Adam Back" Sent: Monday, August 05, 2002 2:26 PM Subject: more TCPA stuff (Re: "trust me" pseudonyms in TCPA) > On Mon, Aug 05, 2002 at 07:42:45AM -0700, Mike Rosing wrote: > > On Mon, 5 Aug 2002, Adam Back wrote: > Effectively I think the best succinct description of the platforms > motivation and function is that: > > "TCPA/Palladium is an extensible, general purpose programmable dongle > soldered to your mother board with centralised points belonging to > Microsoft/IBM/Intel/". The Pd SCP isn't extensible or programable. I wouldn't say that it is "general purpose" either, but I am not sure what you mean by this. It is soldered to your motherboard. It provides a limited (smaller than a TPM) feature set. Pd does not create a a centralised point belonging to Microsoft. There are no root certs from MS except those to certify our own nub and SW, and these are SW certs. How others do this for their SW is up to them. I expect that we will want to get third party certification for our Pd software as well as certing it ourselves. HW is assumed to be certified by whomever built it, based on whatever criteria they want to use for whatever the solution and cost dictate, and they too can get third-party certs as they see fit. It is entirely possible to run Pd and get it's benefits without telling MS Inc. anything about your machine. For Pd to work you have to tell the MS TOR (unless you are using a different TOR) about your machine, and so we have to prove to everyone that telling the TOR something is very different from telling MS Inc. something. Pd doesn't phone home on it's own. > >From my current understanding, the worst problem is the centralised > control of this platform. If it were completely open, and possible to > fix it's potential dangers, it would bring about a new framework of > secured computing and could be a net positive. In it's current form > with centralised control and other problems it could be a big net > negative. There isn't centralized control in Pd. Users are in control. It is up to whomever cares about the trust on a given system to decide if they trust it, and this obviously must start with the user. Peter ++++ --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com ----- End forwarded message ----- From peternbiddle at hotmail.com Tue Aug 6 20:42:12 2002 From: peternbiddle at hotmail.com (Peter N. Biddle) Date: Tue, 6 Aug 2002 20:42:12 -0700 Subject: USENIX Security TCPA/Palladium Panel Wednesday References: <20020807005743.A558194@exeter.ac.uk> Message-ID: I consider it a Bad Thing that we don't have more clearly organized technical documentaion to show right now, and I can only say that we are working on providing this post haste. I certainly am not happy to be pointing you to blogs as primary sources. I apologize for this, and I will send stuff out to this alias when we have it. Peter ++++ > - analysis is greatly hampered by the lack of definitive, concise, > clearly organized technical documentation. Some of the main > informative documents even microsoft is pointing at are like personal > blog entries and copies of personal email exchanges. ----- Original Message ----- From: "Adam Back" To: "AARG!Anonymous" Cc: ; ; Sent: Tuesday, August 06, 2002 4:57 PM Subject: Re: USENIX Security TCPA/Palladium Panel Wednesday > Anonymous: clearly Lucky and Ross have been talking about two aspects > of the TCPA and Palladium platforms: > > 1) the implications of platform APIs planned for first phase > implementation based on the new platform hardware support; > > 2) the implications of the fact that the owner of the machine is > locked out from the new ring-0; > > For 2) one obviously has to go beyond discussing the implications of > the APIs discussed in the documents, so the discussion has included > other APIs that could be built securely with their security rooted in > the new third-party controlled ring-0. > > In my initial two messages looking at implications I did try to > clearly distinguish between documented planned APIs and new APIs that > become possible to build with third-party controlled ring-0s. > > Other areas where analysis is naturally deviating from the aspects > covered by the available documentation (such as it is) are: > > - discussion of likelihood that a given potential API will be built > > - looking at history of involved parties: > > - Intel: pentium serial number > - Microsoft: litany of anti-competetive and unethical business > practices, > - governments: history of trying to push key-escrow, censorship, > thought-crime and technologies and laws attempting to enforce > these infringements of personal freedom > - RIAA/MPAA: history of lobbying for legislation such as DMCA, > eroding consumer rights > - industry/government collaboration: Key Recovery Alliance > (www.kra.org), which shows an interesting intersection of > big-companies who are currently and historically were signed on to > assist the government in deploying key-escrow > > - suspicion that the TCPA/Microsoft are putting their own spin and > practicing standard PR techniques: like selective disclosure, > misleading statements, disclaiming planned applications and hence not > taking everything at face value. TCPA/Microsoft have economic > pressures to spin TCPA/Palladium positively. > > - analysis is greatly hampered by the lack of definitive, concise, > clearly organized technical documentation. Some of the main > informative documents even microsoft is pointing at are like personal > blog entries and copies of personal email exchanges. > > a number of your responses have been of the form "hey that's not a > fair argument, what section number in the TCPA/Palladium documents > gives the specification for that API". > > I suspect some arguing about the dangers of TCPA/palladium feel no > particular obligation to point out this distinction the fact that an > API is not planned in phase 1, or not publicly announced yet offers > absolutely no safe-guard against it's later deployment. > > Adam > > On Tue, Aug 06, 2002 at 03:15:17PM -0700, AARG!Anonymous wrote: > > Lucky Green writes: > > > The slides of the talk on TCPA that I gave over the weekend at DEFCON > > > are now available at http://www.cypherpunks.to > > > > Amazing claims you are making there. Claiming that the TPM will be > > included on "all future motherboards"; claiming that an objective is > > to meet the operational needs of law enforcement and intelligence; > > claiming that TCPA members (all 170 of them?) have more access to his > > computer than the owner; fantasizing about an "approved hardware list" > > and "serial number revocation list" which don't exist in the spec(!); > > further fantasies about a "list of undesirable applications" (where do > > you get this stuff!). > > --------------------------------------------------------------------- > The Cryptography Mailing List > Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com > --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From rabbi at quickie.net Tue Aug 6 23:28:08 2002 From: rabbi at quickie.net (Len Sassaman) Date: Tue, 6 Aug 2002 23:28:08 -0700 (PDT) Subject: CodeCon 2003 Call for Papers Message-ID: CodeCon 2.0 February 2003, San Francisco CA, USA www.codecon.info Call For Papers CodeCon is the premier showcase of active hacker projects. It is an excellent opportunity for developers to demonstrate their work, and for coding hackers to find out about what's going on in their community. All presentations must be accompanied by functional applications, ideally open source. Presenters must be one of the active developers of the code in question. We emphasize that demonstrations be of *working* code, and reproducible by other people. Throughout the event, we will have several kiosks and local servers available for demonstration purposes. CodeCon strongly encourages presenters from non-commercial and academic backgrounds to attend for the purposes of collaboration and the sharing of knowledge by providing free registration to workshop presenters and discounted registration to full-time students. We hereby solicit papers and demonstrations. * Papers and proposals due: December 1, 2002 * Authors notified: December 15, 2002 * Demonstration materials due: January 15, 2003 The focus of CodeCon is on working applications which: * enhance individual power and liberty * can be discussed freely, either by virtue of being open source or having a published protocol, and preferably free of intellectual property restrictions * are generally useful, either directly to a large number of users, or as an example of technology applicable to a larger audience * demonstrate novelty in technical approaches, security assumptions, and end-user functionality Possible topics include, but are by no means restricted to: * development tools - languages, debuggers, version control * file sharing systems - swarming distribution, distributed search * community-based web sites - forums, weblogs, personals * security products - mail encryption, intrusion detection, firewalls Presentations will be a 45 minutes long, with 15 minutes allocated for Q&A. Overruns will be truncated. Submission details: Submissions are being accepted immediately. Acceptance dates are September 1, November 1, and December 1. On each acceptance date, submissions will be either accepted, rejected, or deferred to the next acceptance date. The conference language is English. All submissions should be accompanied by source code or an application. When possible, we would prefer that the application be available for interactive use during the workshop, either on a presenter-provided demonstration machine or one of the conference kiosks. Ideally, demonstrations should be usable by attendees with 802.11b connected devices either via a web interface, or locally on Windows, UNIX-like, or MacOS platforms. Cross-platform applications are most desirable. Our venue may be 21+. If you are submitting and are under 21, please advise the program committee; we may consider alternate venues for one or more days of the event. If you have a specific day on which you would prefer to present, please advise us. To submit, send mail to submissions at codecon.info including the following information: * Project name * url of project home page * tagline - one sentence or less summing up what the project does * names of presenter(s) and urls of their home pages, if they have any * one-paragraph bios of presenters (optional) * project history, no more than a few sentences * what will be done in the project demo * major achievement(s) so far * claim(s) to fame, if any * future plans Conference Producers and co-chairs: Bram Cohen, Len Sassaman Program Committee: * Tina Bird, Counterpane * Bram Cohen, BitTorrent * Roger Dingledine, The Freehaven Project * Jered Floyd, Permabit * Paul Holman, The Shmoo Group * Ben Laurie, The Apache Foundation * Don Marti, Linux Journal * Jordan Ritter, Cloudmark * Len Sassaman, Nomen Abditum Services * Rodney Thayer, The Tillerman Group * Jamie Zawinski, DNA Lounge Sponsorship: If your organization is interested in sponsoring CodeCon, we would love to hear from you. In particular, we are looking for sponsors for social meals and parties on any of the three days of the conference, as well as sponsors of the conference as a whole, prizes or awards for quality presentations, scholarships for qualified applicants, and assistance with transportation or accommodation for presenters with limited resources. If you might be interested in sponsoring any of these aspects, please contact the conference organizers at codecon-admin at codecon.info. Press policy: CodeCon strives to be a conference for developers, with strong audience participation. As such, we need to limit the number of complimentary passes non-developer attendees. Press passes are limited to one pass per publication, and must be approved prior to the registration deadline (to be announced later). If you are a member of the press, and interested in covering CodeCon, please contact us early by sending email to press at codecon.info. Members of the press who do not receive press-passes are welcome to participate as regular conference attendees. Questions: If you have questions about CodeCon, or would like to contact the organizers, please mail codecon-admin at codecon.info. Please note this address is only for questions and administrative requests, and not for workshop presentation submissions. Please note: do not email the old addresses at "codecon.org". Use "codecon.info", or else they will not reach us. From new_soft2765y60 at consultant.com Wed Aug 7 01:02:45 2002 From: new_soft2765y60 at consultant.com (new_soft2765y60 at consultant.com) Date: Wed, 07 Aug 2002 00:02:45 -0800 Subject: NORTON SYSTEMWORKS CLEARANCE SALE! Message-ID: <031a14b02c8e$8541a0c6$7db05db5@obwhis> A non-text attachment was scrubbed... Name: not available Type: text/html Size: 3322 bytes Desc: not available URL: From adam at cypherspace.org Tue Aug 6 16:57:43 2002 From: adam at cypherspace.org (Adam Back) Date: Wed, 7 Aug 2002 00:57:43 +0100 Subject: USENIX Security TCPA/Palladium Panel Wednesday In-Reply-To: ; from remailer@aarg.net on Tue, Aug 06, 2002 at 03:15:17PM -0700 References: Message-ID: <20020807005743.A558194@exeter.ac.uk> Anonymous: clearly Lucky and Ross have been talking about two aspects of the TCPA and Palladium platforms: 1) the implications of platform APIs planned for first phase implementation based on the new platform hardware support; 2) the implications of the fact that the owner of the machine is locked out from the new ring-0; For 2) one obviously has to go beyond discussing the implications of the APIs discussed in the documents, so the discussion has included other APIs that could be built securely with their security rooted in the new third-party controlled ring-0. In my initial two messages looking at implications I did try to clearly distinguish between documented planned APIs and new APIs that become possible to build with third-party controlled ring-0s. Other areas where analysis is naturally deviating from the aspects covered by the available documentation (such as it is) are: - discussion of likelihood that a given potential API will be built - looking at history of involved parties: - Intel: pentium serial number - Microsoft: litany of anti-competetive and unethical business practices, - governments: history of trying to push key-escrow, censorship, thought-crime and technologies and laws attempting to enforce these infringements of personal freedom - RIAA/MPAA: history of lobbying for legislation such as DMCA, eroding consumer rights - industry/government collaboration: Key Recovery Alliance (www.kra.org), which shows an interesting intersection of big-companies who are currently and historically were signed on to assist the government in deploying key-escrow - suspicion that the TCPA/Microsoft are putting their own spin and practicing standard PR techniques: like selective disclosure, misleading statements, disclaiming planned applications and hence not taking everything at face value. TCPA/Microsoft have economic pressures to spin TCPA/Palladium positively. - analysis is greatly hampered by the lack of definitive, concise, clearly organized technical documentation. Some of the main informative documents even microsoft is pointing at are like personal blog entries and copies of personal email exchanges. a number of your responses have been of the form "hey that's not a fair argument, what section number in the TCPA/Palladium documents gives the specification for that API". I suspect some arguing about the dangers of TCPA/palladium feel no particular obligation to point out this distinction the fact that an API is not planned in phase 1, or not publicly announced yet offers absolutely no safe-guard against it's later deployment. Adam On Tue, Aug 06, 2002 at 03:15:17PM -0700, AARG!Anonymous wrote: > Lucky Green writes: > > The slides of the talk on TCPA that I gave over the weekend at DEFCON > > are now available at http://www.cypherpunks.to > > Amazing claims you are making there. Claiming that the TPM will be > included on "all future motherboards"; claiming that an objective is > to meet the operational needs of law enforcement and intelligence; > claiming that TCPA members (all 170 of them?) have more access to his > computer than the owner; fantasizing about an "approved hardware list" > and "serial number revocation list" which don't exist in the spec(!); > further fantasies about a "list of undesirable applications" (where do > you get this stuff!). From khrecments at hsgjhsdhtge.vlgr Wed Aug 7 02:53:07 2002 From: khrecments at hsgjhsdhtge.vlgr (hil__Kelly) Date: Wed, 7 Aug 2002 02:53:07 -0700 Subject: Discreet Extramarital Dating ............................................................................ rptm Message-ID: <200208070952.g779qcR02820@waste.minder.net> A non-text attachment was scrubbed... Name: not available Type: text/html Size: 1719 bytes Desc: not available URL: From alert at giftcd.com Wed Aug 7 01:42:09 2002 From: alert at giftcd.com (GiftCD Alert) Date: Wed, 7 Aug 2002 03:42:09 -0500 (CDT) Subject: Canon 360 Folding Calculator. Your Sample. Message-ID: <200208070842.g778g5Q63344@mtf110.fztrk.com> ---------------------------------------------------------- >> GiftCD Offer Newsletter August 2nd, 2002 ---------------------------------------------------------- As a thank you gift to our subscriber, grab one of these free stuff from our sponsor. +--------------------------------------------------------+ Free Canon 360 Folding Calculator +--------------------------------------------------------+ Get a latest Canon calculator for FREE! Limited item available. Sponsored with NO shipping. Grab one before too late. http://www.giftcd.com/offers/track_canon_free.shtml +--------------------------------------------------------+ Canon 360 Folding Calculator. Free Sample. +--------------------------------------------------------+ New Canon calculator for you, all for free! Limited item available. Grab one before too late! http://www.giftcd.com/offers/track_canon_free.shtml ---------------------------------------------------------- >> Subscription, Disclaimer & Copyright ---------------------------------------------------------- This email is part of your GiftCD Newsletter subscription. If you are no longer interested, please forward this email to: unsubscribenow at giftcd.com Any free stuff you'll like to share with other members? We welcome suggestions, comments and feedback. Email: optinsupport at giftcd.com ========================================================== Copyright 2002 GiftCD.com. All rights reserved. From alert at giftcd.com Wed Aug 7 01:58:32 2002 From: alert at giftcd.com (GiftCD Alert) Date: Wed, 7 Aug 2002 03:58:32 -0500 (CDT) Subject: Your Sample: Canon 360 Folding Calculator. Message-ID: <200208070858.g778wWC83014@mtf110.fztrk.com> ---------------------------------------------------------- >> GiftCD Offer Newsletter August 2nd, 2002 ---------------------------------------------------------- Thank you for your subscription. As a valued GiftCD subscriber, check out this great offer! +--------------------------------------------------------+ Canon 360 Folding Calculator. Free with NO SHIPPING! +--------------------------------------------------------+ Canon calculator product sample is yours for FREE! Yes, but only limited supplies. Grab one while still available! http://www.giftcd.com/offers/track_canon_free.shtml +--------------------------------------------------------+ Free watch! Free S-Shock Hot Summer 2002e. +--------------------------------------------------------+ Limited summer collection. Grab one of the hottest shock-resistant sporting watch for FREE. http://www.giftcd.com/offers/track_summer_shockwatch.shtml ---------------------------------------------------------- >> Subscription, Disclaimer & Copyright ---------------------------------------------------------- This email is part of your GiftCD Newsletter subscription. If you are no longer interested, please forward this email to: unsubscribenow at giftcd.com Any free stuff you'll like to share with other members? We welcome suggestions, comments and feedback. Email: optinsupport at giftcd.com ========================================================== Copyright 2002 GiftCD.com. All rights reserved. From ravage at einstein.ssz.com Wed Aug 7 04:41:44 2002 From: ravage at einstein.ssz.com (Jim Choate) Date: Wed, 7 Aug 2002 06:41:44 -0500 (CDT) Subject: Test #1 [No Reply] Message-ID: -- ____________________________________________________________________ When I die, I would like to be born again as me. Hugh Hefner ravage at ssz.com www.ssz.com jchoate at open-forge.org www.open-forge.org -------------------------------------------------------------------- From adam at cypherspace.org Tue Aug 6 23:20:16 2002 From: adam at cypherspace.org (Adam Back) Date: Wed, 7 Aug 2002 07:20:16 +0100 Subject: dangers of TCPA/palladium In-Reply-To: ; from peternbiddle@hotmail.com on Mon, Aug 05, 2002 at 04:35:46PM -0700 References: <20020805060031.A518477@exeter.ac.uk> Message-ID: <20020807072016.A549171@exeter.ac.uk> Thanks for the clarifications of the differences between TCPA and Palladium. The lack of Palladium docs and fact that TCPA docs describe OS level features led to the inference that Palladium unless otherwise stated did what TCPA proposed. Peter Biddle writes: > Adam Back wrote: > > I think some of the current disagreements and not very strongly > > technology grounded responses to anonymous are due to the lack of any > > concise and informative papers describing TCPA and palladium. > > I agree, and from my perspective this is a problem. We have a great deal of > information we need to get out there. * Documentation I'm feeling frustrated in being unable to properly analyse Palladium due to lack of documentation. Surely microsoft must have _some_ internal documentation that could be released. Two second hand blog articles by third parties doesn't quite cut it! The documents claim privacy advocacy group consultation? Could the information shared with these groups be published? It's quite difficult to reason about implications and limits of a novel new architecture with incomplete information -- you need grounded facts down to the technical details to work out what the implications are from first principles and compare and evaluate the proponents claims. * privacy CA > The suggestions for TCPA responses that William Arbaugh raises seem > quite good (c). 1 and 2 are already true for Pd, I believe that 3 is > true but I would need to talk with him about what he means here to > confirm it, 4 is covered in Eric Norlin's blog (d), and 5 is > something we should do. Insufficient data to comment on the degree of openness provided by palladium for 1 (allow owner to load trusted root cert), and 2 (allow TPM to be completely disabled). For 3, the TCPA version of the "privacy CA" is broken (implemented using "trust me" by a server the user does not and should not have to trust). Does Palladium do something different? later in same message you said: > The privacy model in Pd is different from TCPA. I could go on for a > long time about it, but the key difference is that the public key is > only revealed to named third parties which a user trusts. You are > right in thinking that you need to trust them, but you don't have to > show anyone your key if you don't trust them, so you (the user) are > always in control of this. It sounds as if Palladium suffers from the same broken privacy problem as TCPA then. Saying you have a choice about whether to use a service doesn't alter the fact that you are linkable and identifiable to some extent -- the extent depending on the exact permutation of attribute, identity and endoresment certificates you have used. This vulnerability is unnecessary. You can certifying things without having to trust anyone. * architecture functionality >From the limited information available my understanding is that the main features of Palladium together with a hardware collection called the SCP (= ?) can do the following things: 1. no secure-bootstrapping -- unlike TCPA this is not implemented 2. software-attestation -- Palladium uses SCP able to hash perhaps the TOR, Trusted Agents, and application software, and then uses TCPA-like endorsed hardware keys in the SCP to remotely attest to these hashes. 3. hardware assisted compartmentalization -- CPU can run another layer of privileged software with ability to prevent supervisor mode (and user mode) reading chosen user mode process memory areas. The ubermode code is called the TOR. The supervisor mode can install any TOR into the ubermode, but the TOR can be remotely attested(?) 4. sealing -- TCPA-style sealing on 2, softeware-attestation from information so far, it's unclear what is hashed and what is attested. on 3, hardware assisted compartmentalization - Presumably Palladium enabled applications would refuse to run unless a Palladium/Microsoft certified TOR is running? - Limits the meaningfulness of claims of openness in loading your own TOR. More "you can turn x off but nothing will work if you do". - or perhaps it is up to the individual Palladium application which TOR it trusts? - but wouldn't this lead to a break: - If a microsoft written Palladium enabled application would talk to any TOR, user can load a TOR which is under user control to by-pass the compartmentalized memory restrictions, regaining root. But if he can do this, he can break Palladium enforced DRM. also about hardware assisted compartmentalization, earlier I said: > > Optionally the software source can be published but that is not > > necessary, and if it's not you won't be able to reverse-engineer it > > as it can be encrypted for the CPU you responded: > Confusion. The memory isn't encrypted, nor are the apps nor the TOR > when they are on the hard drive. Encrypting the apps wouldn't make > them more secure, so they aren't encrypted. If I understand the architecture makes it possible to write a TOR which supports encrypted applications encrypted for the machines key which is stored in the SCP. I thought this scheme would be in the current design because as far as I can see this would in fact be necessary for strong copy protection for software (software licensed only for a given machine), which I presumed microsoft has an interest in. It would be a bit like a "sealed" application. * on claim "palladium doesn't prevent anything": > I believe that there isn't a single thing you can do with your PC > today which is prevented on a Palladium PC. I am open to being > challenged on this, so please let me know what you think you won't > be able to do on a Pd PC that you can do today. Well as you can still run the same software that is a tautology. The correct question is: can Palladium enabled software prevent you from doing things you could do with non-Palladium enabled software. Palladium is in fact designed explicitly to prevent the user doing things! The are whole classes of things Palladium enabled software using Trusted Agents, a default TOR and SCP features can prevent the user from doing: - it prevents the owner modifying application code running on his machine which uses the remote-attestation functions to talk to remote servers - it could be used to robustly prevent the user auditing what information flowing into and out of his machine (the user can't obtain the keys negotiated by the SCP and a remote site, and can't grab the keys from the application because it's a trusted agent running in a TOR mediated code compartment.) - it could be used to make file formats which are impossible for third parties to be compatible with (Ross Anderson came up with this example in [4]) - it could be used to securely hide undocumented APIs - it could be used to securely implement software copy-protection using encrypt for endorsed SCP stored machine keys - it could be used to prevent reverse-engineering applications - it could be used for DRM to enforce play-once, to revoke fair use rights or any other arbitrary policies (on formats only available to Palladium enabled applications) - it could be used to implement key-escrow of SCP stored keys to put government or corporate backdoors in sealed data, and comms with remote servers encrypted using SCP negotiated keys; wasn't there a statement somewhere that CAPI uses would more immediately get benefit from Palladium SCP functions? Not sure how the mix of non-palladium using CAPI applications and palladium enabled SCP and/or CAP using applications work out for the key-escrow implementing TOR scenario. now as I mentioned in an earlier post you could claim, oh that's ok because the user has choice, he can still boot with his own custom TOR. In the short term that argument would work. In the long term we run the risk that: a) many users will be so baffled by technology they won't know when they are at risk and when they are not. b) new non-backwards compatible file formats and feature creep together with potential "palladium only format" enforcement could start to make it very inconvenient to use non-standard TORs or non palladium applications. On top of that there are next gen issues, and on-going legal issues. For example what happens when this scenario plays out: 1. recent release digital content is published early (same time as cinema for the right price say). 2. hardware hackers do a break-once run anywhere by ripping all the content on their hacked machine and start distributing it on kazaa (2.5 Peta-bytes of ripped content and growing weekly) 3. RIAA/MPAA goes back and lobbys for further controls, DMCA extensions 4. new legal, DMCA and RIAA/MPAA, and competition from Sony pressures are placed on microsoft difficult to see that far out what is going to happen, but blase presumptions that it's unrealistic to expect key-escrow, or certified TOR only and to assume that Lucky Green's Document Revocation Lists don't get rolled out with DMCA style laws against interfering with -- that ignores a lot of history. Also mentioned in previous post: just because it's law doesn't mean it should be enforced. People are currently afforded the ability to ignore the masses of extreme and ridiculous IP law as individuals. When a large chunk of it gets implemented into DRM, and narcware the once free-wheeling internet information exchanges will become marginalized, or underground only affairs -- the world will become stifled by their own computers acting as the policeman inside -- your own computer deputized by the US government, DMCA et al. > > So what I've read so far, I think people's gut reactions are right -- > > that it's an aggressive and abmitious power grab by the evil empire -- > > the 3 cartels / monopolies surrounding PC hardware, Operating systems > > and Content Distribution. The operating system near monoply will > > doubtless find creative ways to use and expand the increased control > > to control application interoperability (with the sealing function), > > to control with hardware assistance the access to undocumented APIs > > (no more reverse engineering, or using the APIs even if you do / could > > reverse engineer). > > I know that we aren't using undocumented API's I think you must have misinterpreted what I said: I wasn't talking about Palladium APIs. I was talking about the fact that microsoft has historically used undocumented APIs as a business tactic, and I presume this is still an ongoing strategy, and the Palladium hardware architecture could be used to build a TOR which forced competitors attempting to discover undocumented APIs in order to fairly compete to resort to hardware hacking. Unless and until we get the software copyright analog of DMCA reverse-engineering restrictions which makes that illegal. > and that we will strive for the highest degree of interoperability > and user control possible. Pd represents massive de-centralization > of trust, not the centralization of it. I'm not sure what you mean by "de-centralized trust". Perhaps that the TOR is publicly audited? Perhaps that there are multiple vendors endorsing SCP implementations? I think Palladium clearly has possibilities to magnify centralized control. It is in microsoft's economic interests, and historically their modus-operandi to aggresively try to create and exploit control points to extract monopolistic rents, and/or suppress competition. And of course other companies also have used the same strategies, but the current limits placed on such practices by the ability to reverse engineer for compatibility may come to be eroded by TCPA/Palladium. > I think that time is going to have to tell on this one. I know that this > isn't true. You think that it is. I doubt that my saying it isn't true is > going to change your mind; I know that the technology won't do much of what > you are saying it does do, but I also know that some of these things boil > down to suspicion around intent, and only time will show if my intent is > aligned with my stated goals. It's nothing personal, it's just that intent is open to evolutionary change, legislative attack, pressures outside of your personal, or microsoft's control -- economic and legal incentives will arise which make the platform deviate from current stated intent. 2002 stated intent is zip guarantee. Someone sent me this hugely appropriate quote in email relating to this point: | "You do not examine legislation in the light of the benefits it will | convey if properly administered, but in the light of the wrongs it | would do and the harms it would cause if improperly administered." - | Lyndon Johnson except here we are not talking about legislation directly but a hardware platform with the tools to create different control points and the legal and business pressures that act upon the use and misuse of that platform and those created control points. > I think that Pd represents an enhancement to personal freedoms and > user control over their machines. I hope that over time I will be > able to explain Pd sufficiently well so that you have all the facts > you need to understand how and why I say this. I can only think that your definitions of user control probably are in terms of abstract "security" rather than a distrusting viewpoint that wants to be able to audit and modify application behavior. I presume you mean "freedom" in the sense of freedom from the ills that it is claimed Palladium enabled applications could improve. I think of freedom as the ability for self-determination, to completely control and audit all aspects of software running on my system. Without these freedoms applications and vendors can conspire against the machine owner. I suspect the majority of people feel similarly. With current information it seems that the Palladium platform is damaging to freedom and indivdual liberty, and a future risk to free society. I am of course completely open to being proven wrong, and look forward to seeing more detailed Palladium specs so that this can be tested, and to see the community given the opportunity to point out potential more open and less control point prone modifications. Adam [4] "Security in Open versus Closed Systems (The Dance of Boltzmann, Coase and Moore)", Ross Anderson, (Sections 4 and 5 only, rest is unrelated) http://www.cl.cam.ac.uk/ftp/users/rja14/toulouse.pdf From eugen at leitl.org Tue Aug 6 23:20:09 2002 From: eugen at leitl.org (Eugen Leitl) Date: Wed, 7 Aug 2002 08:20:09 +0200 (CEST) Subject: dangers of TCPA/palladium In-Reply-To: Message-ID: On Tue, 6 Aug 2002, Sunder wrote: > What kind of crack are you smoking? This is cypherpunks. Anonymous > posters are the norm here. The point is not that some people here are posting anonymously, the point is that Anonymous could make a far stronger point by disclosing his identity, thus showing that he has no vested interest in the matter. His psyops-fu is rather good, I'm curious if this correlates with the views he's projecting. From admin at hrpromo.com Wed Aug 7 06:07:01 2002 From: admin at hrpromo.com (Admin HR Promo) Date: Wed, 7 Aug 2002 09:07:01 -0400 Subject: Diversity Recruiting Resource 2614 Message-ID: Pricing Booth Rate $3250.00 Government $2437.50 Education $1650.00 Sponsorship Packages Corporate Level 2 Avail. Affiliate Level 5 Avail. Check with PSI for Details Program Advertising: Full Page: $595 Inside Front Cover: $1295 Inside Back Cover: $1295 Ctr. 2-page Spread $1295 Back Cover $1295 2-page Spread $995 Contact PSI about this and other events. PERSONNEL STRATEGIES LLC Wells Fargo Bank Building 1809 S. Plymouth Road Suite 350 Minnetonka, MN 55305-1977 Phone 952-595-4496 Outstate: 800-390-5561 Fax: 952-595-4499 1-800-390-5561 info at psijobfair.com or visit www.psijobfair.com MAP Sales, Healthcare, Finance, Computer, Engineering, Retail, Restaurant, Administration, and more About the CBCF: www.cbcfonline.org It is the mission of the Congressional Black Caucus Foundation (CBCF) to engage in nonpolitical, nonpartison research and policy analysis on issues of concern to African Americans and the underserved population. To that end the CBCF has worked to broaden and elevate the influence of African Americans in the political, legislative and public policy arenas. The Annual Conference brings together people of diverse perspectives and backgrounds to explore and formulate solutions to critical domestic and foreign policy issues confronting the Black community. The Diversity Job Fair is an "Official" part of the Conference and is featured on the floor of the CBCF Annual Conference. Attendees: The CBCF 2002 Annual Legislative Conference is attended by affluent and politically involved African Americans from throughout the USA. The Conference provides a national forum for developing strategies and viable solutions for the public policies facing Black America. Everyone from college students to Corporate CEO's all interact to explore both an influence and an understanding of the legislative process. Over 30,000 are expected to attend the 2002 Conference. SPONSORSHIP PACKAGES Corporate Sponsorship: (2 Available) $12,500.00 Includes 2 booths, 2-page 4-color Program Ad, Company logo featured in event print promotions, Full page Program Advertorial, on-site signage, framed certificate, & more. Affiliate Sponsorship: (5 Available) $8,500.00 Includes 2 booths, full page 4-color Program Ad, Company Logo in print promotions. On-site signage, framed certificate & more. Click If you do NOT wish to continue receiving messages from HRpromo.com To CHANGE YOUR EMAIL ADDRESS and continue receiving messages click here We respect all removal requests. HRpromo.com 26 Church St. South Orange, New Jersey 07079 973-313-1711 info at hrpromo.com If you experience difficulty removing through the click here send an email to remove at hrpromo.com and you will be removed from our mailing list. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/html Size: 9410 bytes Desc: not available URL: From gjones2 at hotmail.com Wed Aug 7 02:26:59 2002 From: gjones2 at hotmail.com (gjones2 at hotmail.com) Date: 07 Aug 02 09:26:59 -0000 Subject: Term Life, Whole Life, Burial Insurance Quotes, Now Message-ID: A non-text attachment was scrubbed... Name: not available Type: text/html Size: 1713 bytes Desc: not available URL: From sunder at sunder.net Wed Aug 7 07:07:44 2002 From: sunder at sunder.net (Sunder) Date: Wed, 7 Aug 2002 10:07:44 -0400 (edt) Subject: dangers of TCPA/palladium - will the real anon shady please stand up? In-Reply-To: Message-ID: "Waaa, he was vicious! He used a remailer!" Oh my! Well that's just proof that he's working for Microsoft! (With a nudge, nudge, wink, wink, say no more to Monty Python.) You've called him on it several times. Get over it. I couldn't give a fuck whether or not "it" (unless it has expressed a gender clue to the contrary, I'll randomy assign "he" to it) is Bill Gate's personal buttboy. If his arguement is BS it will stand on its own as BS. Shame on you. Bad dog! All you're doing is weaking your own arguements. IMNHO TCPA sucks balls. But "anonymous" has the right to speak anonymously as does anyone, and most of us here will defend that right, regardless of accepting or rejecting TCPA/Palladium/MSFT. You remember that old saw about "I may not agree with you, but I will defend your right to say it to the death" -- just add anonymously in there. It's up to that "anon" or collection of anons to chose to disclose it's/their affiliation/admiration for MSFT or not. Besides, from what I've seen, those anon messages weren't signed. So I can claim "I am that anonymous" and so can Vulis, Choate, Lucky, Tim, Declan, RAH, yourself, your mom, the horse she rode on, the FedZ, the NSA spook Satelite dancers (like the Rockettes, but they wear stego-panty stockings and have barcodes on their foreheads sent by Lotus Notes so the DIRNSA has a copy), and the Man Show Juggies. So what? Would the real "anon shady please stand up?" ROTFL! ----------------------Kaos-Keraunos-Kybernetos--------------------------- + ^ + :NSA got $20Bill/year|Passwords are like underwear. You don't /|\ \|/ :and didn't stop 9-11|share them, you don't hang them on your/\|/\ <--*-->:Instead of rewarding|monitor, or under your keyboard, you \/|\/ /|\ :their failures, we |don't email them, or put them on a web \|/ + v + :should get refunds! |site, and you must change them very often. --------_sunder_ at _sunder_._net_------- http://www.sunder.net ------------ On Wed, 7 Aug 2002, Eugen Leitl wrote: > On Tue, 6 Aug 2002, Sunder wrote: > > > What kind of crack are you smoking? This is cypherpunks. Anonymous > > posters are the norm here. > > The point is not that some people here are posting anonymously, the point > is that Anonymous could make a far stronger point by disclosing his > identity, thus showing that he has no vested interest in the matter. > > His psyops-fu is rather good, I'm curious if this correlates with the > views he's projecting. From emc at artifact.psychedelic.net Wed Aug 7 11:16:20 2002 From: emc at artifact.psychedelic.net (Eric Cordian) Date: Wed, 7 Aug 2002 11:16:20 -0700 (PDT) Subject: Deterministic Primality Testing in P Message-ID: <200208071816.g77IGKb02080@artifact.psychedelic.net> In case anyone missed it, Manindra Agrawal and his colleagues at the Indian Institute of Technology have published a paper http://www.cse.iitk.ac.in/primality.pdf Which purports to give an O(log(n)^12) deterministic algorithm for primality testing. Someone on sci.math reports.. "Hendrik Lenstra just wrote to the Number Theory mailing list saying that the proof is correct, clever and elegant; and it is elementary except for one result from analytic number theory needed to establish the running time." In other math news, there's a recent survey on the P vs NP Conjecture at http://www.cs.umd.edu/~gasarch/papers/poll.ps Of 100 theorists responding, 9 thought NP=P, 61 thought NP!=P, 22 had no opinion, and 8 quibbled over what axiom system would be used. The piece includes comments by many of the respondents, including Donald E. Knuth. -- Eric Michael Cordian 0+ O:.T:.O:. Mathematical Munitions Division "Do What Thou Wilt Shall Be The Whole Of The Law" From rah at shipwright.com Wed Aug 7 08:27:38 2002 From: rah at shipwright.com (R. A. Hettinga) Date: Wed, 7 Aug 2002 11:27:38 -0400 Subject: dangers of TCPA/palladium - will the real anon shady please stand up? In-Reply-To: References: Message-ID: At 10:07 AM -0400 on 8/7/02, Sunder wrote: > Besides, from what I've seen, those anon messages weren't signed. So I > can claim "I am that anonymous" and so can Vulis, Choate, Lucky, Tim, > Declan, RAH, yourself, your mom, the horse she rode on, the FedZ, the NSA > spook Satelite dancers (like the Rockettes, but they wear stego-panty > stockings and have barcodes on their foreheads sent by Lotus Notes so the > DIRNSA has a copy), and the Man Show Juggies. So what? > > Would the real "anon shady please stand up?" ROTFL! :-). See below... Cheers, RAH -- ----------------- R. A. Hettinga The Internet Bearer Underwriting Corporation 44 Farquhar Street, Boston, MA 02131 USA "...we ain't nothin' but mammals." --Eminem From sunder at sunder.net Wed Aug 7 09:08:32 2002 From: sunder at sunder.net (Sunder) Date: Wed, 7 Aug 2002 12:08:32 -0400 (edt) Subject: dangers of TCPA/palladium - will the real anon shady please stand up? In-Reply-To: Message-ID: On Wed, 7 Aug 2002, Eugen Leitl wrote: > Are you being deliberately dense? The facts that he's using a remailer and > has most uncypherpunk-like notions are alone insufficient to trip the > suspicion circuit. But his insinuations are unusually good, and hence I'd > like to know who he is. I'm just deliberately trying to avoid donning a tin foil hat. YPMV (Your Paranoia May Vary.) Somehow I think a lack of tin surrounding my head makes it less dense though. No, I'm do not have any investments or any relations with Microsoft - other than I think all their software sucks. Nor am I defending Anon's arguements, nor TCPA, nor Palladium. I'm only taking exception at your silly and impossible to prove request that Anonymous decloak. > If deep paranoia cryptoanarchy freaks can be made to endorse TCPA/Pd crap > that's sufficient motivation for a troll. Not to detract from my own arguement, but to entertain you a bit further, style can be forged. There are even "Best of Bad Hemmingway" contests and books for example. Style means nothing. It's as easy to copy as posting mp3's on a p2p network. Collusions happen, conspiracies happen. Hey, I've got a suspicious feeling that George Bush is Maxwell Smart, since they look alike. Or alternatively the chimp in Bedtime for Bonzo... But you don't see me emailing george at whitehouse.gov and asking if their Cone of Silence is out of order, or if he would like some bannanas. And might I presume to ask, who are you referring to when you say "deep paranoia cryptoanarchy freaks?" After all, if that anon (or groups of anons) that you have a gripe with happen to work for MSFT, I would hardly label it/them as cryptoanarchy freaks. More like greedy evil pro-microsoft buttmonkies. If you're referring to others such as me and yourself, who despise Palladium, TCPA, and Microsoft, calling us paranoid cryptoanarchic freaks isn't going to get you any free rounds of beers at the next meet... except maybe poured on your head... Look, if you want to keep it a useful and interesting conversation, by all means refrain from conjecture and ad homeneims. If you want to don the tin foil hat, be my guest... procmail filters are standing by... act now, don't delay, into the spam folder you shall go. ----------------------Kaos-Keraunos-Kybernetos--------------------------- + ^ + :NSA got $20Bill/year|Passwords are like underwear. You don't /|\ \|/ :and didn't stop 9-11|share them, you don't hang them on your/\|/\ <--*-->:Instead of rewarding|monitor, or under your keyboard, you \/|\/ /|\ :their failures, we |don't email them, or put them on a web \|/ + v + :should get refunds! |site, and you must change them very often. --------_sunder_ at _sunder_._net_------- http://www.sunder.net ------------ From remailer at aarg.net Wed Aug 7 12:35:12 2002 From: remailer at aarg.net (AARG! Anonymous) Date: Wed, 7 Aug 2002 12:35:12 -0700 Subject: Palladium: technical limits and implications Message-ID: <51678c581368e18c35beca5d8665c528@aarg.net> Adam Back writes: > I have one gap in the picture: > > In a previous message in this Peter Biddle said: > > > In Palladium, SW can actually know that it is running on a given > > platform and not being lied to by software. [...] (Pd can always be > > lied to by HW - we move the problem to HW, but we can't make it go > > away completely). Obviously no application can reliably know anything if the OS is hostile. Any application can be meddled with arbitrarily by the OS. In fact every bit of the app can be changed so that it does something entirely different. So in this sense it is meaningless to speak of an app that can't be lied to by the OS. What Palladium can do, though, is arrange that the app can't get at previously sealed data if the OS has meddled with it. The sealing is done by hardware based on the app's hash. So if the OS has changed the app per the above, it won't be able to get at old sealed data. And of course remote attestation will not work either, if the app has been meddled with. This means that an app can start running, attest to its "clean" status to a remote server, download some data from that server, and seal it. Then at a later time, IF the app is able to unseal that data, then it is true that the app has not been meddled with and is not running on virtualized hardware. That is how I understand these sorts of claims. From remailer at aarg.net Wed Aug 7 12:50:29 2002 From: remailer at aarg.net (AARG! Anonymous) Date: Wed, 7 Aug 2002 12:50:29 -0700 Subject: Challenge to TCPA/Palladium detractors Message-ID: I'd like the Palladium/TCPA critics to offer an alternative proposal for achieving the following technical goal: Allow computers separated on the internet to cooperate and share data and computations such that no one can get access to the data outside the limitations and rules imposed by the applications. In other words, allow a distributed network application to create a "closed world" where it has control over the data and no one can get the application to "cheat". IMO this is clearly the real goal of TCPA and Palladium, in technical terms, when stripped of all the emotional rhetoric. As I posted previously, this concept works especially well for open source applications. You could even have each participant compile the program himself, but still each app can recognize the others on the network and cooperate with them. And this way all the participants can know that the applications aren't doing anything different than what they claim. This would be a very powerful capability with many uses that you might find both good and bad. I posted a long message earlier with three examples of privacy-oriented applications: secure game playing, anonymous P2P networking, and untraceable digital cash. In addition it can be used for DRM, restricting access to sensitive business or government data, and similar applications. For those of you who claim that such a technology is not necessarily objectionable in itself, but that the implementations in TCPA and Palladium are flawed, please explain how you could do it better. How can you maximize user control and privacy and minimize the potential for government or corporate takeovers? In other words, what *exactly* is wrong with the way that TCPA and Palladium choose to do things? Can you fix those problems and still achieve the basic goal, above? From adam at homeport.org Wed Aug 7 09:50:31 2002 From: adam at homeport.org (Adam Shostack) Date: Wed, 7 Aug 2002 12:50:31 -0400 Subject: Privacy-enhancing uses for TCPA In-Reply-To: ; from peternbiddle@hotmail.com on Tue, Aug 06, 2002 at 07:08:25PM -0700 References: <20020806191139.GQ23240@zork.net> Message-ID: <20020807125030.A7722@lightship.internal.homeport.org> On Tue, Aug 06, 2002 at 07:08:25PM -0700, Peter N. Biddle wrote: | Neither of us really had the time to clearly articulate things last time, so | I am glad you brought it up. My perspective is primarily from an | architectural one, and it boils down to this: | | Platform security shouldn't choose favorites. I think most of us will agree to that. But you are choosing favorites: You're asserting certain ideas about society and how it ought be structured, and asserting that a system should do certain things. Some de-contextualized quotes are below. | enforce policy judgement on arbitrary data would be impossible to manage. It | would vary from country to country, and most importantly (from my Why do countries get to impose their laws on my data? Which countries get to do so? And are you still in France? ;) | Not only should the platform be able to exert the highest degrees of control | over this information on behalf of a user, it should also allow the user to | make smart choices about who gets the info and what the policy is around the | usage of this info remotely. This must be in a context where lying is both | extremely difficult and onerous. Why? Lying is a really good way to protect your privacy. | Common sense dictates that the unlawful usage of some kinds of data is far | more damaging (to society, individuals, groups, companies) than other kinds | of data, and that some kinds of unlawful uses are worse than others, but | common sense is not something that can be exercised by a computer program. | This will need to be figured out by society and then the policy can be | exerted accordingly. Again, we disagree. | I am not sure I understand the dichotomy; technical enforcement of user | defined policies around access to, and usage of, their local data would seem | to be the right place to start in securing privacy. (Some annoying cliche | about cleaning your own room first is nipping at the dark recesses of my | brain ; I can't seem to place it.) When you have control over privacy | sensitive information on your own machine you should be able to use similiar | mechanisms to achieve similiar protections on other machines which are | capable of exerting the same policy. You should also have an infrastructure | which makes that policy portable and renewable. This doesn't work, since, as Ross Anderson points out, the knowledge that you're HIV positive is owned by lots of different people at different times, and once one of them reads it on screen, they can reproduce it, irrevocably, outside the policy which you've tried to impose. So, you've made some choices about how the system can be used; you've chosen ways to protect privacy which reflect your view of how privacy should be protected. Similarly copyright. Thats your right, however, I, and many others are deeply concerned that those choices are going to get embedded and imposed on the rest of us. Hey, you know what? They may even be good choices. But I don't care. Fundamentally, they restrict my freedom to do dumb things, to be unreasonable, to dissent. And that worries the hell out of me. Adam -- "It is seldom that liberty of any kind is lost all at once." -Hume From sunder at sunder.net Wed Aug 7 10:15:39 2002 From: sunder at sunder.net (Sunder) Date: Wed, 7 Aug 2002 13:15:39 -0400 (edt) Subject: anonymous text analysis - will the real anon shady please stand up? In-Reply-To: Message-ID: Then, please, ferret out Mr. Anonymous and decloak him yourself. It would make for an interesting project in the least. After you've succeded, then you can dig up his connection to MSFT. Cypherpunks write code, yes? ----------------------Kaos-Keraunos-Kybernetos--------------------------- + ^ + :NSA got $20Bill/year|Passwords are like underwear. You don't /|\ \|/ :and didn't stop 9-11|share them, you don't hang them on your/\|/\ <--*-->:Instead of rewarding|monitor, or under your keyboard, you \/|\/ /|\ :their failures, we |don't email them, or put them on a web \|/ + v + :should get refunds! |site, and you must change them very often. --------_sunder_ at _sunder_._net_------- http://www.sunder.net ------------ On Wed, 7 Aug 2002, Eugen Leitl wrote: > On Wed, 7 Aug 2002, Sunder wrote: > > > Not to detract from my own arguement, but to entertain you a bit > > further, style can be forged. There are even "Best of Bad Hemmingway" > > contests and books for example. Style means nothing. It's as easy to > > copy as posting mp3's on a p2p network. > > You're of course aware that even shallow textual analysis of list archives > allows good fingerprinting of even casual posters. Even if we all would > post anonymously you could still build reliable clusters. It is impossible > to scramble that signature as long as your posts are nontrivial in length > by pretending to be somebody else. > > I'm not aware of a fully automated tool to reliably scramble that > fingerprint. (Pointers welcome). Doing it semimanually is prohibitively > expensive in a forum such as this. From greenplace at msm.net Wed Aug 7 12:08:54 2002 From: greenplace at msm.net (greenplace at msm.net) Date: Wed, 7 Aug 2002 14:08:54 -0500 Subject: Low Cost Long Distance Message-ID: <200208071908.g77J8lc21150@sirius.enap.edu.co> New Page 1   LOW  COST  =LONG   DISTANCE =     Six Plans To Choose From Including: $9.95 Plan  * Unlimited Plan  * Travel Plan Canadian Plans *  International   *  Intra/Inter State Stop paying the high cost of long distance.   Simple to understand all-inclusive pricing so you save big! Email us now with your phone number to hear how crystal clear your connection will be. To be removed please click here             -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/html Size: 3135 bytes Desc: not available URL: From eresrch at eskimo.com Wed Aug 7 14:18:47 2002 From: eresrch at eskimo.com (Mike Rosing) Date: Wed, 7 Aug 2002 14:18:47 -0700 (PDT) Subject: Challenge to TCPA/Palladium detractors In-Reply-To: Message-ID: On Wed, 7 Aug 2002, AARG! Anonymous wrote: > I'd like the Palladium/TCPA critics to offer an alternative proposal > for achieving the following technical goal: > > Allow computers separated on the internet to cooperate and share data > and computations such that no one can get access to the data outside > the limitations and rules imposed by the applications. > > In other words, allow a distributed network application to create a > "closed world" where it has control over the data and no one can get > the application to "cheat". IMO this is clearly the real goal of TCPA > and Palladium, in technical terms, when stripped of all the emotional > rhetoric. Yes, this is a major research project in many universities. Nobody has a complete solution for the general case but some solutions for specific cases. IBM and Certicom both have hardware computation platforms that allow a single company to verify its stuff is secure on remote platforms, but the remote platform is under the control of the company, it's not a generic PC that any consumer owns. Personally I think it's impossible. Once the data is in the clear in some form it can be copied to some other form. You can't stop someone from cheating if you want them to get access to data. > For those of you who claim that such a technology is not necessarily > objectionable in itself, but that the implementations in TCPA and > Palladium are flawed, please explain how you could do it better. How can > you maximize user control and privacy and minimize the potential for > government or corporate takeovers? > > In other words, what *exactly* is wrong with the way that TCPA and > Palladium choose to do things? Can you fix those problems and still > achieve the basic goal, above? No, it's not possible to ship data around and let anyone see it *and* prevent it from being copied. What you can do is create specific environments for specific applications, and there are already solutions available for those purposes. The problem with TCPA and Palladium is attempting to make it generic. If one person controls all computers, then the specific solution becomes possible. But it just happens that most of us don't like the idea of one person controling all computers. Patience, persistence, truth, Dr. mike From lynn.wheeler at firstdata.com Wed Aug 7 12:33:23 2002 From: lynn.wheeler at firstdata.com (lynn.wheeler at firstdata.com) Date: Wed, 7 Aug 2002 14:33:23 -0500 Subject: Challenge to David Wagner on TCPA Message-ID: it is relative common for authentication hardware tokens with asymmetric crypto to never divulge the private key .... there is big issue then whether 1) the key pair is actually generated on the chip (and never divulged) or 2) the keys are generated externally and injected into the chip (with special compensating procedures that the chip never leaks the private key ... and there is no record kept by the generation/injection process). specifications for asymmetric cryptography for data encryption may include key escrow of the private key (allowing business continuity for data that has been encrypted with the public key). lucky green If I buy a lock I expect that by demonstrating ownership I > can get a replacement key or have a locksmith legally open it. It appears the days when this was true are waning. At least in the PC platform domain. --Lucky --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From bill.stewart at pobox.com Wed Aug 7 14:33:34 2002 From: bill.stewart at pobox.com (Bill Stewart) Date: Wed, 07 Aug 2002 14:33:34 -0700 Subject: ANNOUNCE SF Cypherpunks, Sat Aug 10, Berkeley, Jupiter Brewery Message-ID: <5.1.1.6.2.20020807142400.04acfcc0@idiom.com> August 2002 Physical Meeting Announcement General Info: DATE: Saturday 10 August 2002 TIME: 1:00 - 6:00 PM (Pacific Time) PLACE: Jupiter Brewing, 2181 Shattuck, Berkeley Agenda "Our agenda is a widely-held secret." The organized program begins about 1:00. Some expected people and discussion topics: - GNU Radio - TCPA (though Lucky will probably give his DEFCON talk another time) - John Gilmore's recent work on FAA Airport Thuggery - Things that happened at Usenix Security and Defcon. After the meeting, there is usually dinner somewhere nearby. Jupiter is a brewery, with pizza and sandwiches and their own beer and other brewers' beer. As usual, this is an open meeting on US Soil, and everyone's invited, including some suspiciously foreign Canadians and Brits (expected) and Florida's Secretary of State (not expected). However, it's possible there will be Stupid Government Tricks restricting people under 21, because of the presence of ethanol. There's a Party at Ian's Place the night before, and the Usenix Security Symposium is in SF this week. Location Jupiter 2181 Shattuck, Berkeley Jupiter opens at High Noon. We will be in the heated outdoor beer garden, weather permitting, or conspicuously inside. And unlike the last time we were here, it's unlikely to be freezing outside. Directions: Map: http://www.jupiterbeer.com/berkeley/directions/ BART: Take BART to Berkeley station; Jupiter is across the street. Driving: Take 80 to University Avenue. Turn right on Shattuck. Go about 3 blocks. Lat/Long: 37.869765 N 122.268175 W If you get lost on the way, you can try calling: +1.415.307.7119 (Bill) From freebies4u at tom.com.hk Wed Aug 7 11:42:53 2002 From: freebies4u at tom.com.hk (freebies4u at tom.com.hk) Date: Wed, 7 Aug 2002 14:42:53 -0400 (EDT) Subject: Earn Unlimited Income Working At Home! Message-ID: <200208071842.g77IgqJ95122@locust.minder.net> MAKE MILLIONS ON THE NET IN UNDER 6 MONTHS -CDIC AS SEEN ON TV!!! READ THIS E-MAIL TO THE END! - Follow what it says to the letter - and you will not worry whether a RECESSION is coming or not, who is President, or whether you keep your current job or not. Yes, I know what you are thinking. I never responded to one of these before either. One day though, something just said "you throw away $25.00 going to a movie for 2 hours with your wife". "What the heck." Believe me, no matter where you believe "those feelings" come from, I thank every day that I had that feeling. I cannot imagine where I would be or what I would be doing had I not. Read on. It's true. Every word of it. It is legal. I checked. Simply because you are buying and selling something of value. AS SEEN ON NATIONAL TV: Make over half million dollars every 4 to 5 months from your home.     THANK'S TO THE COMPUTER AGE AND THE INTERNET! ========================================= BE AN INTERNET MILLIONAIRE LIKE OTHERS WITHIN A YEAR!!!   Before you say ''Bull'', please read the following. This is the letter you have been hearing about on the news lately. Due to the popularity of this letter on the Internet, a national weekly news program recently devoted an entire show to the investigation of this program described below, to see if it really can make people money. The show also investigated whether or not the program was legal.   Their findings proved once and for all that there are ''absolutely NO Laws prohibiting the participation in the program and if people can "follow the simple instruction" they are bound to make some mega bucks with only $25 out of pocket cost''.   == PRINT THIS NOW FOR YOUR FUTURE REFERENCE == $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$   If you would like to make at least $500,000 every 4 to 5 months easily and comfortably, please read the following... THEN READ IT AGAIN and AGAIN!!!   $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$   FOLLOW THE SIMPLE INSTRUCTION BELOW AND YOUR FINANCIAL DREAMS WILL COME TRUE, GUARANTEED!   INSTRUCTIONS:   =====Order all 5 reports shown on the list below =====   For each report, send $5 CASH, THE NAME & NUMBER OF THE REPORT YOU ARE ORDERING and YOUR E-MAIL ADDRESS to the person whose name appears ON THAT LIST next to the report. MAKE SURE YOUR RETURN ADDRESS IS ON YOUR ENVELOPE TOP LEFT CORNER in case of any mail problems.   ===WHEN YOU PLACE YOUR ORDER, MAKE SURE === ===YOU ORDER EACH OF THE 5 REPORTS! ===   You will need all 5 reports so that you can save them on your computer and resell them.   YOUR TOTAL COST $5 X 5 = $25.00.   Within a few days you will receive, via e-mail, each of the 5 reports from these 5 different individuals. Save them on your computer so they will be accessible for you to send to the 1,000's of people who will order them from you. Also make a floppy of these reports and keep it on your desk in case something happens to your computer.   IMPORTANT - DO NOT alter the names of the people who are listed next to each report, or their sequence on the list, in any way other than what is instructed below in step '' 1 through 6 '' or you will loose out on the majority of your profits. Once you understand the way this works, you will also see how it does not work if you change it.   Remember, this method has been tested, and if you alter it, it will NOT work!!! People have tried to put their friends/relatives names on all five thinking they could get all the money. But it does not work this way. Believe us, some have tried to be greedy and then nothing happened. So Do Not try to change anything other than what is instructed. Because if you do, it will not work for you. Remember, honesty reaps the reward!!!   This IS a legitimate BUSINESS. You are offering a product for sale and getting paid for it. Treat it as such and you will be VERY profitable in a short period of time.   1.. After you have ordered all 5 reports, take this advertisement and REMOVE the name & address of the person in REPORT # 5. This person has made it through the cycle and is no doubt counting their fortune.   2..Move the name & address in REPORT # 4 down TO REPORT # 5.   3.. Move the name & address in REPORT # 3 down TO REPORT # 4.   4.. Move the name & address in REPORT # 2 down TO REPORT # 3.   5.. Move the name & address in REPORT # 1 down TO REPORT # 2   6.... Insert YOUR name & address in the REPORT # 1 Position.   PLEASE MAKE SURE you copy every name & address ACCURATELY! This is critical to YOUR success.   Take this entire letter, with the modified list of names, and save it on your computer. DO NOT MAKE ANY OTHER CHANGES.   Save this on a disk as well just in case if you loose any data. To assist you with marketing your business on the internet, the 5 reports you purchase will provide you with invaluable marketing information which includes how to send bulk e-mails legally, where to find thousands of free classified ads and much more. There are 2 primary methods to get this venture going:   METHOD # 1: BY SENDING BULK E-MAIL LEGALLY =========================================   Let's say that you decide to start small, just to see how it goes, and we will assume You and those involved send out only 5,000 e-mails each. Let's also assume that the mailing receive only a 0.2% (2/10 of 1%) response (the response could be much better but lets just say it is only 0.2%). Also many peoplewill send out hundreds of thousands e-mails instead of only 5,000 each).   Continuing with this example, you send out only 5,000 e-mails. With a 0.2% response, that is only 10 orders for report # 1. Those 10 people responded by sending out 5,000 e- mail each for a total of 50,000. Out of those 50,000 e-mails only 0.2% responded with orders. That's=100 people responded and ordered Report # 2.   Those 100 people mail out 5,000 e-mails each for a total of 500,000 e-mails. The 0.2% response to that is 1000 orders for Report # 3.   Those 1000 people send 5,000 e-mail each for a total of 5 million e-mail sent out. The 0.2% response is 10,000 orders for Report # 4.   Those 10,000 people send out 5,000 e-mails each for a total of 50,000,000(50 million) e- mails. The 0.2% response to that is 100,000 orders for Report # 5.     THAT'S 100,000 ORDERS TIMES $5 EACH = $500,000.00 (half a million dollars).   Your total income in this example is: 1..... $50 + 2..... $500 + 3.....$5,000 + 4..... $50,000 + 5.... $500,000 .... Grand Total = $555,550.00   NUMBERS DO NOT LIE. GET A PENCIL & PAPER AND FIGURE OUT THE WORST POSSIBLE RESPONSES AND NO MATTER HOW YOU CALCULATE IT, YOU WILL STILL MAKE A LOT OF MONEY ! =========================================   REMEMBER FRIEND, THIS IS ASSUMING ONLY 10 PEOPLE ORDERING OUT OF 5,000 YOU MAILED TO. Dare to think for a moment what would happen if everyone or half or even one 4th of those people mailed 100,000 e-mails each or more?   There are over 150 million people on the Internet worldwide and counting, with thousands more coming on line every day. Believe me, many people will do just that, and more!   METHOD # 2: BY PLACING FREE ADS ON THE INTERNET =========================================   Advertising on the net is very, very inexpensive and there are hundreds of FREE places to advertise. Placing a lot of free ads on the Internet will easily get a larger response. We strongly suggest you start with Method # 1 and add METHOD #2 as you go along. For every $5 you receive, all you must do is e-mail them the Report they ordered. That's it. Always provide same day service on all orders.   This will guarantee that the e-mail they send out, with your name and address on it, will be prompt because they can not advertise until they receive the report.   =========== AVAILABLE REPORTS ============== The reason for the "cash" is not because this is illegal or somehow "wrong". It is simply about time. Time for checks or credit cards to be cleared or approved, etc. Concealing it is simply so no one can SEE there is money in the envelope and steal it before it gets to you.   ORDER EACH REPORT BY ITS NUMBER & NAME ONLY. Notes: Always send $5 cash (U.S. CURRENCY) for each Report. Checks NOT accepted. Make sure the cash is concealed by wrapping it in at least 2 sheets of paper. On one of those sheets of paper, Write the NUMBER & the NAME of the Report you are ordering, YOUR E-MAIL ADDRESS and your name and postal address.   PLACE YOUR ORDER FOR THESE REPORTS NOW : =========================================REPORT # 1: 'The Insider's Guide To Advertising for Free On The Net   Order Report #1 from: Y.L.Wong P.O. Box NO. 71819 Kowloon Central Post Office Hong Kong __________________________________________________   REPORT # 2: The Insider's Guide To Sending Bulk Email On The Net   Order Report # 2 from: Martin Veronneau C.P. 70058 Laval, Quebec H7R 5Z2 Canada __________________________________________________   REPORT # 3: Secret To Multilevel Marketing On The Net   Order Report # 3 from: Francis Kidd P.O. Box 209 Homestead, PA 15120 USA   __________________________________________________   REPORT # 4: How To Become A Millionaire Using MLM & The Net   Order Report # 4 from: M.L. Frayser P.O. Box 61432 Fort Myers, FL 33906 USA __________________________________________________   REPORT # 5: How To Send Out One Million Emails For Free   Order Report # 5 From: Stone Evans 600 N. Pearl, Suite G103 Dallas, TX 75201 USA    __________________________________________________ $$$$$$$$$ YOUR SUCCESS GUIDELINES $$$$$$$$$$$   Follow these guidelines to guarantee your success:   === If you do not receive at least 10 orders for Report #1 within 2 weeks, continue sending e-mails until you do.   === After you have received 10 orders, 2 to 3 weeks after that you should receive 100 orders or more for REPORT # 2. If you did not, continue advertising or sending e-mails until you do.   **Once you have received 100 or more orders for Report # 2, YOU CAN RELAX, because the system is already working for you, and the cash will continue to roll in ! THIS IS IMPORTANT TO REMEMBER: Every time your name is moved down on the list, you are placed in front of a Different report.   You can KEEP TRACK of your PROGRESS by watching which report people are ordering from you. IF YOU WANT TO GENERATE MORE INCOME SEND ANOTHER BATCH OF E-MAILS AND START THE WHOLE PROCESS AGAIN. There is NO LIMIT to the income you can generate from this business!!! ========================================= FOLLOWING IS A NOTE FROM THE ORIGINATOR OF THIS PROGRAM: You have just received information that can give you financial freedom for the rest of your life, with NO RISK and JUST A LITTLE BIT OF EFFORT. You can make more money in the next few weeks and months than you have ever imagined. Follow the program EXACTLY AS INSTRUCTED. Do Not change it in any way. It works exceedingly well as it is now.   Remember to e-mail a copy of this exciting report after you have put your name and address in Report #1 and moved others to #2 .....# 5 as instructed above. One of the people you send this to may send out 100,000 or more e-mails and your name will be on every one of them.   Remember though, the more you send out the more potential customers you will reach. So my friend, I have given you the ideas, information, materials and opportunity to become financially independent.   IT IS UP TO YOU NOW!   =============TESTIMONIALS=============== ''My name is Mitchell. My wife, Jody and I live in Chicago. I am an accountant with a major U.S. Corporation and I make pretty good money. When I received this program I grumbled to Jody about receiving 'junk mail'. I made fun of the whole thing, spouting my knowledge of the population and percentages involved. I ''knew'' it wouldn't work. Jody totally ignored my supposed intelligence and few days later she jumped in with both feet. I made merciless fun of her, and was ready to lay the old ''I told you so'' on her when the thing didn't work.   Well, the laugh was on me! Within 3 weeks she had received 50 responses. Within the next 45 days she had received total $ 147,200.00......... all cash! I was shocked. I have joined Jodyin her ''hobby''.   Mitchell Wolf M.D., Chicago, Illinois ========================================= ''Not being the gambling type, it took me several weeks to make up my mind to participate in this plan. But conservative as I am, I decided that the initial investment was so little that there was just no way that I wouldn't get enough orders to at least get my money back. I was surprised when I found my medium size post office box crammed with orders. I made $319,210.00 in the first 12 weeks.   The nice thing about this deal is that it does not matter where people live. There simply isn't a better investment with a faster return and so big''.   Dan Sondstrom, Alberta, Canada ========================================= ''I had received this program before. I deleted it, but later I wondered if I should have given it a try. Of course, I had no idea who to contact to get another copy, so I had to wait until I was e-mailed again by someone else.........11 months passed then it luckily came again...... I did not delete this one! I made more than $490,000 on my first try and all the money came within 22 weeks''.   Susan De Suza, New York, N.Y. ========================================= ''It really is a great opportunity to make relatively easy money with little cost to you. I followed the simple instructions carefully and within 10 days the money started to come in. My first month I made $20, in the 2nd month I made $560.00 and by the end of third month my total cash count was $362,840.00. Life is beautiful, Thanx to internet''.   Fred Dellaca, Westport, New Zealand =========================================   ORDER YOUR REPORTS TODAY AND GET STARTED ON YOUR ROAD TO FINANCIAL FREEDOM !   ========================================= If you have any questions of the legality of this program, contact the Office of Associate Director for Marketing Practices, Federal Trade Commission, Bureau of Consumer Protection, Washington, D.C.     This message is sent in compliance of the proposed bill SECTION 301, paragraph (a)(2)(C) of S. 1618.     * This message is not intended for residents in the State of Washington, Virginia or California, screening of addresses has been done to the best of our technical ability.   * This is a one-time mailing and this list will never be used again.     * To be removed from this list, please send an email with the word REMOVE in the subject line to freebie4u at sinatown.com   From events at thesoleilgroup.com Wed Aug 7 12:18:52 2002 From: events at thesoleilgroup.com (Soleil) Date: Wed, 7 Aug 2002 15:18:52 -0400 Subject: TOMORROW -- Password: Soleil -- TV Casting Message-ID: <200208071923.OAA22430@lml100.siteprotect.com> Tomorrow will be huge. Password: Soleil has become the premiere Thursday night in New York - with a chill after-work and a blazing late-night. This Thursday, producers from Columbia Tristar are casting people for their new reality TV show. We invite all members of the media and entertainment industries for an exclusive event celebrating New York high-life. Password: SOLEIL Thursdays @Nativa 5 East 19th Street b/w B'way & 5th Ave. New York, NY "SOLEIL" REQUIRED FOR ENTRY You must say 'Soleil' at the door. $5 before 10pm 6-8pm Happy Hour Free dinner buffet. 1/2 price drinks. party 'til 4am Music: Hip-Hop, Reggae, Latin Soul, R&B RSVP Recommended: 212.591.1253 password at thesoleilgroup.com ---------------- To be removed from this list, email: remove at thesoleilgroup.com with the word "remove" in the subject heading. ---------------- From events at thesoleilgroup.com Wed Aug 7 12:18:53 2002 From: events at thesoleilgroup.com (Soleil) Date: Wed, 7 Aug 2002 15:18:53 -0400 Subject: TOMORROW -- Password: Soleil -- TV Casting Message-ID: <200208071923.OAA22402@lml100.siteprotect.com> Tomorrow will be huge. Password: Soleil has become the premiere Thursday night in New York - with a chill after-work and a blazing late-night. This Thursday, producers from Columbia Tristar are casting people for their new reality TV show. We invite all members of the media and entertainment industries for an exclusive event celebrating New York high-life. Password: SOLEIL Thursdays @Nativa 5 East 19th Street b/w B'way & 5th Ave. New York, NY "SOLEIL" REQUIRED FOR ENTRY You must say 'Soleil' at the door. $5 before 10pm 6-8pm Happy Hour Free dinner buffet. 1/2 price drinks. party 'til 4am Music: Hip-Hop, Reggae, Latin Soul, R&B RSVP Recommended: 212.591.1253 password at thesoleilgroup.com ---------------- To be removed from this list, email: remove at thesoleilgroup.com with the word "remove" in the subject heading. ---------------- From crawdad at fnal.gov Wed Aug 7 14:13:36 2002 From: crawdad at fnal.gov (Matt Crawford) Date: Wed, 07 Aug 2002 16:13:36 -0500 Subject: Challenge to TCPA/Palladium detractors In-Reply-To: "07 Aug 2002 12:50:29 PDT." Message-ID: <200208072113.g77LDaC17060@gungnir.fnal.gov> > I'd like the Palladium/TCPA critics to offer an alternative proposal > for achieving the following technical goal: > Allow computers separated on the internet to cooperate and share data > and computations such that no one can get access to the data outside > the limitations and rules imposed by the applications. > [...] > You could even have each participant compile the program himself, > but still each app can recognize the others on the network and > cooperate with them. Unless the application author can predict the exact output of the compilers, he can't issue a signature on the object code. The compilers then have to be inside the trusted base, checking a signature on the source code and reflecting it somehow through a signature they create for the object code. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From jsd at monmouth.com Wed Aug 7 13:43:15 2002 From: jsd at monmouth.com (John S. Denker) Date: Wed, 07 Aug 2002 16:43:15 -0400 Subject: Challenge to TCPA/Palladium detractors References: Message-ID: <3D518663.B34405A5@monmouth.com> "AARG!Anonymous" wrote: > > I'd like the Palladium/TCPA critics to offer an alternative proposal > for achieving the following technical goal: > > Allow computers separated on the internet to cooperate and share data > and computations such that no one can get access to the data outside > the limitations and rules imposed by the applications. That is frightfully underspecified. Creating such a system could be very easy or very hard, depending on what range of policies is to be supported, and depending on what your threat model is. At one extreme I might trust an off-the-shelf PC if it were booted from CD by trusted parties in a TEMPEST-shielded room surrounded by armed guards. At the other extreme, making tamper-proof hardware to face unlimited threats is very, very hard -- most likely outside the "PC" price range for the foreseeable future. > In other words, allow a distributed network application to create a > "closed world" where it has control over the data and no one can get > the application to "cheat". IMO this is clearly the real goal of TCPA > and Palladium, in technical terms, when stripped of all the emotional > rhetoric. Well, the "technical terms" are not and should not be the sole focus of the current discussion. There are other questions such as -- what range of policies should be supported -- who gets to set the policy -- who decides who trusts whom -- etc. etc. etc. I agree that there has been too much ad-hominem sewage and emotional rhetoric mixed in with the valid arguments recently. From remailer at aarg.net Wed Aug 7 16:55:11 2002 From: remailer at aarg.net (AARG! Anonymous) Date: Wed, 7 Aug 2002 16:55:11 -0700 Subject: Palladium: hardware layering model Message-ID: <1c9905949ee6ae242d2b3fd69f09eb24@aarg.net> Adam Back writes: > some definitions: > > hw layer -- SCP which I think provides crypto key store, crypto > co-processor for sealing, remote attesation > > ring 0 -- new layer which controls memory management unit and secured > code compartments > > supervisor mode -- normal supervisor mode, which can now only read > user space, but not trusted agents running in code compartments > > user mode -- legacy user level apps under complete control of > supervisor mode > > and some ASCII art: > > +---------------+------------+ > | trusted-agent | user mode | > | space | app space | > | (code +------------+ > | compartment) | supervisor | > | | mode | > +---------------+------------+ > | ring-0 / Memory mgmt unit | > +----------------------------+ > | hardware / SCP key manager | > +----------------------------+ > > each layer below can decide policy and information disclosure through > APIs to the layer above. I don't think this is right, as Peter said that the Palladium stuff could load many days after boot. So I don't think the "ring-0" mode underlies normal supervisor mode as you have shown it. Instead I think they are relatively orthogonal. I'm not sure how to draw it, but I would envision the TOR as a device driver which controls two devices: the trusted execution space, which is some special memory (on the cpu?), and the SCP, the crypto processor. Let us suppose that there is a special instruction to load a block of code into the trusted execution space and give it a new process ID. At the same time this causes the SCP to hash it so that it can attest to it later. Let us also suppose that the ring-0 mode is used only when running code out of the trusted execution space (TE space). What is special about ring-0? Two things: first, it can see the code in the TE space so that it can execute it. And second, it doesn't trap into supervisor mode for things like debugger single-stepping. I'm not familiar with the details of the Pentium family but on most CPUs the debugger single-steps things by setting a flag and returning into the code. The code executes one instruction and then automatically traps into supervisor mode, which hands off to the debugger. This process must be suppressed in ring-0 mode, and likewise for any other features which can force a ring-0 process to trap involuntarily into supervisor mode, which exposes the registers and such. The TOR would then manage the various processes running in the TE space, and their interactions with ordinary code, and possibly the interactions of both with the SCP. I'm not sure if the TOR runs in ring-0 mode and in the TE space; probably it does, as the SCP can attest to it, and we wouldn't want non-Palladium processes to debug it. So really the whole TOR/SCP/TE-space/trusted-agents stuff is relatively orthogonal to the rest of windows. It's almost like you had a fully functional 2nd CPU in there that you could load code into and have it run; that CPU's memory is the TE space, its mode is the ring-0, it has access to the SCP, and it runs the TOR and trusted agents. But Palladium has to use the regular CPU for this so they firewall it off with the ring-0 mode which locks it into this restrictive mode. That's just a guess, probably wrong in many details, but consistent with what I understand so far. Mostly I am hoping to encourage Peter to come forward and correct our misconceptions. > The implications of which are: > > - the SCP can implement sealing with data separation against ring-0 > (ring-0 can't bypass sealing data separation) I have this as well; loading a user agent into TE space creates the hash "fingerprint" which will be used for sealing and attestation; other ring-0 agents will have their own fingerprints and won't be able to unseal what this agent does. The SCP compares fingerprints at unseal time to what it was at seal time and (optionally) won't unseal if they don't match. (This is one of multiple sealing options.) > - ring-0 can read all superviser, user, and trusted agent space, but I don't think so; not necessary in my model, would require significant re-architecting of Windows which won't happen, and inconsistent with the claim that Palladium can load days after boot. > - ring-0 and MMU can compartmentalize trusted agents so they can't > tamper with each other, and Must be true. Some questions: how big is the TE space? How many agents can live there at once? Do they swap in/out? Does data go there, or just code? > - ring-0 and MMU can exclude supervisor mode from trusted agent space > and ring-0 space; supervisor mode is itself just another > compartmentalized trusted-agent level space. Therefore ring-0 can > restrict what supervisor mode (where the normal OS is located) can do. But ring-0 cannot make arbitrary restrictions on sup. mode. Remember they can't afford to re-architect either the entire CPU nor the entire OS for this. The simplest is that in ring-0 mode you disable certain functions that could trap you into supervisor mode thereby losing control of the CPU, and this ring-0 mode gains you access to the TE space. > whereas the normal protected CPU architecture is just: > > +------------+ > | user mode | > | app space | > +------------+ > | supervisor | > | mode | > +------------+ I'm not much of artist but I would put the new stuff off to the side of this in its own tower. Ring-0 mode at the bottom, running the TOR which is shown above it, which manages the user agents which would be on top. The SCP is further off to the side, perhaps managed by the TOR. > - from these assumptions it appears an OS could be implemented so that > all OS calls pass through ring-0 APIs and mediation to get to > supervisor mode OS. In this case the OS could observe system calls > the trusted agent makes, but not in general read, debug, modify > virtualize or modify trusted-agent code. The non-virtualization > presumes encrypted trusted-agent code, which Peter said is not done, > so this can't be how it works. I'm not sure what you mean by the OS observing system calls. By definition, system calls go into the OS. So I don't think that will ever stop happening. But it does mean that when a ring-0 trusted agent makes a system call, we change to normal supervisor mode which makes the trusted space invisible. The point we are dancing around is this. How does it protect the data, along the whole path from the remote machine, through where it is processed locally, until it is sealed on the local disk? It seems that it must be in the clear for a while on the local machine. Where is that - in regular memory, or TE space? It's not that big a deal to be unable to read TE *code*. From what Peter says, that is typically not encrypted on the disk. So the code is no secret. What we must be unable to read are the data being handled by this code: the registers, the contents of memory that are sensitive. And by the registers I include the PC, since that would leak information about the data. We can't single-step it, we can't put breakpoints into it, we can't change it while it is running. > I would be interested to hear what model takes for Palladium mapping > the interactions and restrictions between Trusted Agents, user space, > OS kernel, TOR to the hardware. We need this kind of detail to reason > about limits of the Palladium and make distinctions between what is > possible with Palladium implementation choices vs what other types of > OSes could be built from the hardware features. I am curious about this from the technical perspective. I think this is one of the most interesting developments in many years on the security front. But frankly I don't think it will do them much good to tell you and most other cypherpunks about it, because whatever they say, you and others will twist it and lie if necessary a la Lucky to turn it into some horrible perversion. Even if the design were totally benign, that doesn't mean Microsoft/Intel couldn't change it someday, right? They could put a machine gun into every PC aimed at the user, and a camera over his head. That's the level of reasoning in Lucky's Defcon presentation, except that he says that they've already done it. I applaud Peter's patience but pity him for his naive belief that he is engaging in a good faith exchange where he will get a fair hearing. > One idea I think would be interest is as follows: > > - the TOR (which lives in ring-0) _could_ be used together with the OS > to force all trusted-agent in-flows and out-flows (network traffic) to > go through code under supervisor mode control. I think this is pretty likely, but with the data encrypted by the time the supervisor mode sees it. > I don't think this is likely in the current design; but this change > would be an improvement: > > - it would at least allow user audit and control of in-flows and > out-flows; If the data is in the clear, it would undermine the security guarantees! Look at my online poker game - if the dealer can tap into the data going out, he will learn what everyone else's hands are. Look at the anonymous network - an eavesdropper can learn where all the data is and how it is flowing. The data must not be made available in the clear anywhere the user can get at it, to provide the proper security. > - the user could block suspicious phone-home information out-flows, Well, he *does* know at least the address the data is going to. There's no way to hide that (short of anonymous message forwarding). > - the user could read out-flows and demand un-encrypted documented > formats, or if encrypted, encrypted with keys the supervisor mode gets > copies of. There are some applications which will still work if all the users can *see* all of the data, but just not modify it. Maybe my digital cash example would fall into that category. You can see how much you're spending, but you can't manipulate your wallet. But there are many others, such as those above, where being able to hide even information disclosure from network participants adds tremendous power. You remember the Eternity network, how one concept had files being shared across multiple nodes such that no one knew which files were on his own computer. That was crucially important for non-repudiation and censorship-resistance. This was done with cryptography, but the point is the same: hiding information from network participants can greatly increase security. With TCPA/Palladium you can get some of the same security properties with much simpler ode (with admittedly lower levels of security until hardware improves). Skipping down... > > And of course remote attestation will not work either, if the app > > has been meddled with. > > Remote attestation, which is not itself general -- just a remote > dongle thing -- if not tied to remote dongle controlled sealing which > is necessary for the main application function could be nopped out. I am assuming that you are attesting to the remote system, and you only can control your local one. You want to get something from the remote, and it will only give it if you are running "clean" on real hardware. So you can't virtualize and still attest, since ultimately you don't have a TPM endorsement key (or Palladium equivalent) with a nice TPME endorsement certificate issued on it. Of course if you have control of the server machine, you can ignore attestation. But that just says that the operator of the remote machine can choose for himself which apps to run. He can run an app that checks remote client integrity or he can run one which doesn't care. > So in the general case it seems that remote attestation is also > effectively virtualizable, modifiable and debuggable by first nopping > out remote attestation checks. (This is not strictly virtualizable as > the remote dongle call nopping modification makes it no longer the > same application, but as I said unless this is necessary for the > application it doesn't otherwise change it's behavior, so it's > effectively virtualizable). I'm not sure I follow this, but it sounds like you are talking about manipulating the server machine doing the checks, while in most cases you can only manipulate the client machine making the request. From adam at cypherspace.org Wed Aug 7 09:28:04 2002 From: adam at cypherspace.org (Adam Back) Date: Wed, 7 Aug 2002 17:28:04 +0100 Subject: (fwd) Re: more TCPA stuff (Re: "trust me" pseudonyms in TCPA)] Message-ID: <20020807172804.A594649@exeter.ac.uk> Another Peter Biddle reply to the TCPA/Palladium thread on cryptography. Adam ----- Forwarded message from "Peter N. Biddle" ----- From remailer at aarg.net Wed Aug 7 17:35:14 2002 From: remailer at aarg.net (AARG! Anonymous) Date: Wed, 7 Aug 2002 17:35:14 -0700 Subject: Palladiated Huber: "Software's Cash Register", Forbes, 10/18/93 Message-ID: <977c1e329f6fdb4677ffbe267aece81d@aarg.net> > A blast from the past for you Proto-Palladium fans. > > I remember reading this before I discovered the One True Cypherpunk > Religion the following summer and thinking, "yeah, that's cool". > Unfortunately, nowdays, for all my admiration for Dr. Huber, it just makes > me laugh out loud... I don't know why it should. Wave, the company profiled here, is said to be actively involved with both TCPA and Palladium. They're just a little behind schedule, is all. It's not like the Cypherpunk Revolution is progressing according to plan, either, is it? From jamesd at echeque.com Wed Aug 7 17:36:00 2002 From: jamesd at echeque.com (James A. Donald) Date: Wed, 7 Aug 2002 17:36:00 -0700 Subject: On alliances and enemies. In-Reply-To: Message-ID: <3D515A80.26774.385CDF@localhost> -- Hollywood and the government, would like the internet to be like television, a few big businesses steadily churning out content, and everyone else passively consuming it. Microsoft really would not like that, since, despite all their faults, they are in the computer business. This is analogous to the difference between Hitler and Stalin. Hitler wanted to enslave the whole world right away, Stalin wanted to enslave the world bit by bit as the opportunity permitted, and whenever the time was ripe . Thus it made sense for the west to ally with Stalin. Trouble was, Stalin thought it made sense to ally with Hitler. My concern is not that Bill Gates is in bed with hollywood, but rather than Microsoft may be trying to compromise, may be trying to make a deal, over a matter where in truth no deal is possible, no compromise can work. Microsoft really does not want an internet that is regulated like TV. Hollywood really does. Analogously Stalin wanted most of Eastern Europe, and Hitler wanted all of Eastern Europe, and then some. Sooner or later, Microsoft has to come out on our side. Let us hope sooner, rather than later. Microsoft, like Hollywood, wants unreasonable and burdensome levels of intellectual property protection, but they do not want to destroy computing in order to get it. Hollywood, and to a lesser extent the government, would be happy to destroy unauthorized individual and small business computing and networking even if it did not help them sustain unreasonable and burdensome levels of intellectual property protection. This does not mean we should give Microsoft the benefit of the doubt on Palladium. It does mean we cannot automatically assume that Microsoft is completely in bed with Hollywood. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG pAtW9HDHsrtZztGUc46QOKEaFC3eHqZITeQJH+8P 2/FCNFYTqk89Jr/89vepeUPpC/XHNLdr3Vzuqvsa9 From eugen at leitl.org Wed Aug 7 08:46:41 2002 From: eugen at leitl.org (Eugen Leitl) Date: Wed, 7 Aug 2002 17:46:41 +0200 (CEST) Subject: dangers of TCPA/palladium - will the real anon shady please stand up? In-Reply-To: Message-ID: On Wed, 7 Aug 2002, Sunder wrote: > "Waaa, he was vicious! He used a remailer!" Oh my! Well that's just proof > that he's working for Microsoft! (With a nudge, nudge, wink, wink, say no Are you being deliberately dense? The facts that he's using a remailer and has most uncypherpunk-like notions are alone insufficient to trip the suspicion circuit. But his insinuations are unusually good, and hence I'd like to know who he is. If deep paranoia cryptoanarchy freaks can be made to endorse TCPA/Pd crap that's sufficient motivation for a troll. > Besides, from what I've seen, those anon messages weren't signed. So I > can claim "I am that anonymous" and so can Vulis, Choate, Lucky, Tim, > Declan, RAH, yourself, your mom, the horse she rode on, the FedZ, the NSA > spook Satelite dancers (like the Rockettes, but they wear stego-panty > stockings and have barcodes on their foreheads sent by Lotus Notes so the > DIRNSA has a copy), and the Man Show Juggies. So what? The style is consistent, and he hasn't called a forgery yet. > Would the real "anon shady please stand up?" ROTFL! From rah at shipwright.com Wed Aug 7 15:37:51 2002 From: rah at shipwright.com (R. A. Hettinga) Date: Wed, 7 Aug 2002 18:37:51 -0400 Subject: Palladiated? (was re: wow - palladiated! (Re: Palladium: technical limits and implications)) Message-ID: Evidently, I have permission to pass this along. :-). Don't try this at home, boys and girls. This is a professional neologist at work... Cheers, RAH Comedy is not pretty... --- begin forwarded text From t.c.jones at att.net Wed Aug 7 11:51:46 2002 From: t.c.jones at att.net (t.c.jones at att.net) Date: Wed, 07 Aug 2002 18:51:46 +0000 Subject: Palladium: technical limits and implications (Re: more TCPA stuff (Re: "trust me" pseudonyms in TCPA)) Message-ID: <20020807185147.VXXK11089.mtiwmhc22.worldnet.att.net@webmail.worldnet.att.net> It's a question of trust. The trust of the content owner in this case. If the content owner is to trust the h/w (which has been called a varient of a media player elsewhere on this list) then it will require a signature from a trusted third party. As has been noted before in the smart card case, trusted third parties need to know that the private key, for which they issue a cert, is well protected. I believe we all agree that the best place to protect a private key is h/w. If you want a cert from a 3rd party with that level of asertion, then YOU need to prove that YOU have provide that level of protection. Both smart cards (see FINREAD specs.) and similar h/w can provide this level of protection. (Pls note that I did not claim that all do, only that they can do it if they chose.) hth ..tom > I have one gap in the picture: > > In a previous message in this Peter Biddle said: > > > In Palladium, SW can actually know that it is running on a given > > platform and not being lied to by software. [...] (Pd can always be > > lied to by HW - we move the problem to HW, but we can't make it go > > away completely). > > But what feature of Palladium stops someone taking a Palladium enabled > application and running it in a virtualized environment. ie They > write software to emulate the SCP, sealing and attestation APIs. > > Any API calls in the code to verify non-virtualization can be broken > by putting a different endoresment root CA public key in the > virtualized SCP. > > The Palladium application (without the remote attestation feature) has > no way to determine that it is not virtualized. If the Palladium > application contains the endoresement root CA key that can be changed. > If the application relies on the SCP to contain the endoresmenet key > but doesn't verify it that can be virtualized with a replacement fake > endoresment root CA public key using the existing SCP APIs. > > Then Palladiumized application could be debugged and it's features > used without the Palladium non-virtualization guarantee. > > Am I free to do this as the owner of palladium compatible hardware > running a version of windows with the proposed palladium feature set? > > If so how does this reconcile with your earlier statement that: > > > In Palladium, SW can actually know that it is running on a given > > platform and not being lied to by software > > > Then we also have the remote attestation feature which can't be so > fooled, but for local attestation does the above break work, or is > there some other function preventing that? > > Does that imply that the BORA protections only apply to: > > - applications which call home to use remote attestation before > functioning > > - and even here the remote attestation has to be enforced to data > separation levels -- ie it has to be that the server provides a > required and central part of the application -- like providing the > content, or keys to the content -- otherwise the remote > attestation call can also be nopped out with no ill-effect (much > as calls to dongles with no other effect than to check for > existance of a dongle could be nopped) > > - applications which are encrypted to a machine key which is buried in > the SCP and endorsed by the hardware manufacturer > > - however you said in your previous mail that this is not planned > > * now about my attempts to provide a concise, representative and > readily understandable summary of what the essence of palladium is: > > my previous attempt which you point out some flaws in: > > > Adam Back wrote: > > > Effectively I think the best succinct description of the platforms > > > motivation and function is that: > > > > > > "TCPA/Palladium is an extensible, general purpose programmable dongle > > > soldered to your mother board with centralised points belonging to > > > Microsoft/IBM/Intel/". > > > > The Pd SCP isn't extensible or programable. > > OK that is true. I presume you focussed on SCP because you took the > dongle to mean literally the SCP component alone. > > Let's me try to construct an improved succint Palladium motivation and > function description. We need to make clear the distinction that the > programmability comes from the hardware/firmware/software ensble > provided by: > > hardware: the SCP, new ring0 and code compartmentatlization > > (btw what are the Palladium terms for the new ring0 that the TOR runs > in, and what is the palladium term for the code compartment that > Trusted Agents run in -- I'd like to use consistent terminology) > > super-kernel: TOR operating in new ring0 > > software: palladium enabled applications using the features such as > software attestation, and sealing with control rooted in hardware and > the TOR > > > So would it be fair to characterize the negative aspects of Palladium > as follows: > > "Palladium provides an extensible, general purpose programmable > dongle-like functionality implemented by an ensemble of hardware and > software which provides functionality which can, and likely will be > used to expand centralised control points by OS vendors, Content > Distrbuters and Governments." > > So I think that statement though obviously less possitively spun than > Microsoft would like perhaps addresses your technical objections with > the previous characterization. > > btw I readily concede of course that Palladium platform offers the > security compartmentalization and software assurance aspects anonymous > and Peter Biddle have described; I am just mostly examining the > flip-side of the new boundary of applications buildable to data > separation standards of security with this platform. One could > perhaps construct a more balanced characterization covering both > positive features and negative risks, but I'll let Palladium > proponents work on the former. > > So to discuss your objections to the previous version of my attempted > Palladium characterization: > > - as you say the hardware platform does not itself provide control > points (I agree) > > - as you say, the TOR being publicly auditable does not itself provide > control points > > however the platform can, and surely you can admit the risk, and even > the likelihood that it will in fact be used to continue and further > the existing business strategies of software companies, the content > industry and governments. > > The dongle soldered to your motherboard can conspire with the CPU and > memory management unit to lock the user out of selected processes > running on their own machine. > > If you focus on the subset of buildable applications which operate in > the users interests you can call this a good thing. If you look at > the risks of buildable applications which can be used to act against > the users interests it can equally be a very dangerous thing. Also if > you look at historic business practices, legal trends, and the wishes > of the RIAA/MPAA there are risks that these bad practices and trends > will be futher accelerated, exarcerbated and more strongly enforced. > > I'd be interested to see you face and comment on these negative > aspects rather than keep your comments solely on beneficial user > functions, claim neutrality of low level features, and disclaim > negative aspects by claiming at a low level user choice. The low > level user choice may in the long run prove impractical or almost > impossible for novice users, or even advanced users without hardware > hacking tools, to technically exercise. (I elaborated on the > possiblities for robust format compatibility prevention, and related > possibilities a previous mail.) > > > I wouldn't say that it is "general purpose" either, but I am not > > sure what you mean by this. > > I mean it is programmable in the sense that software attestation, > certification and the endoresed new privileged ring0 code, together > with the hardware enforced code compartments allow the protections of > the firmware and hardware running in the SCP to be extended up to > complete applications -- the Trusted Agents running in code > compartments. > > That makes it general purpse because it is programmable. It could be > used to build many classes of application across a spectrum of good, > debatable and evil: > > - more flexibile and secure anonymity systems (clear user > self-interest as anonymous suggested) > > - DRM (mixed positive and negative, debatable depends on your point of > view) > > - and for example key-escrow of SCP support crypto functions > implemented in the TOR accessed with say CAPI (very negative) > > > > >From my current understanding, the worst problem is the centralised > > > control of this platform. If it were completely open, and possible to > > > fix it's potential dangers, it would bring about a new framework of > > > secured computing and could be a net positive. In it's current form > > > with centralised control and other problems it could be a big net > > > negative. > > > > There isn't centralized control in Pd. Users are in control. It is > > up to whomever cares about the trust on a given system to decide if > > they trust it, and this obviously must start with the user. > > You're focussing on the low level platform specifics, not on the > bigger implications of the overall hardware, TOR, OS and software > ensemble which I was talking about. Yes you can run different TORS. > But using a specific (and audited published) TOR which the user may > find himself choosing to run in order to run Palladium-enabled > applications, all the applications, file formats, services and content > which are tied to doing that -- control points could and likely will > be built. > > It is my opinion that the directions and business pressures are such > that meaningful distributed control is unlikely to be the long term > result of the things that will be built using the Palladium > hardware/software ensemble. > > This seems a fairly clearly consistent and predictable outcome, unless > the software, IP law, RIAA/DMCA and legal systems all make an > _astounding_ complete U-turn in policy and tacitcs coincident with the > deployment of Palladium. > > Can you defend the arguement that Palladium and TCPA don't change the > balance of control against the user and against personal control in > our current balance between technical feasibility of building software > systems enforcing third party control and law? > > (btw I'll stop nagging about documentation now, previous mail crossed > with your reply on the topic). > > Adam > -- > "You do not examine legislation in the light of the benefits it will > convey if properly administered, but in the light of the wrongs it > would do and the harms it would cause if improperly administered." > -- Lyndon Johnson > > --------------------------------------------------------------------- > The Cryptography Mailing List > Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From adam at cypherspace.org Wed Aug 7 10:54:31 2002 From: adam at cypherspace.org (Adam Back) Date: Wed, 7 Aug 2002 18:54:31 +0100 Subject: Palladium: technical limits and implications (Re: more TCPA stuff (Re: "trust me" pseudonyms in TCPA)) In-Reply-To: ; from peternbiddle@hotmail.com on Tue, Aug 06, 2002 at 08:06:04PM -0700 References: <20020805064801.A532566@exeter.ac.uk> <20020805222628.A512885@exeter.ac.uk> Message-ID: <20020807185431.B594649@exeter.ac.uk> I have one gap in the picture: In a previous message in this Peter Biddle said: > In Palladium, SW can actually know that it is running on a given > platform and not being lied to by software. [...] (Pd can always be > lied to by HW - we move the problem to HW, but we can't make it go > away completely). But what feature of Palladium stops someone taking a Palladium enabled application and running it in a virtualized environment. ie They write software to emulate the SCP, sealing and attestation APIs. Any API calls in the code to verify non-virtualization can be broken by putting a different endoresment root CA public key in the virtualized SCP. The Palladium application (without the remote attestation feature) has no way to determine that it is not virtualized. If the Palladium application contains the endoresement root CA key that can be changed. If the application relies on the SCP to contain the endoresmenet key but doesn't verify it that can be virtualized with a replacement fake endoresment root CA public key using the existing SCP APIs. Then Palladiumized application could be debugged and it's features used without the Palladium non-virtualization guarantee. Am I free to do this as the owner of palladium compatible hardware running a version of windows with the proposed palladium feature set? If so how does this reconcile with your earlier statement that: > In Palladium, SW can actually know that it is running on a given > platform and not being lied to by software Then we also have the remote attestation feature which can't be so fooled, but for local attestation does the above break work, or is there some other function preventing that? Does that imply that the BORA protections only apply to: - applications which call home to use remote attestation before functioning - and even here the remote attestation has to be enforced to data separation levels -- ie it has to be that the server provides a required and central part of the application -- like providing the content, or keys to the content -- otherwise the remote attestation call can also be nopped out with no ill-effect (much as calls to dongles with no other effect than to check for existance of a dongle could be nopped) - applications which are encrypted to a machine key which is buried in the SCP and endorsed by the hardware manufacturer - however you said in your previous mail that this is not planned * now about my attempts to provide a concise, representative and readily understandable summary of what the essence of palladium is: my previous attempt which you point out some flaws in: > Adam Back wrote: > > Effectively I think the best succinct description of the platforms > > motivation and function is that: > > > > "TCPA/Palladium is an extensible, general purpose programmable dongle > > soldered to your mother board with centralised points belonging to > > Microsoft/IBM/Intel/". > > The Pd SCP isn't extensible or programable. OK that is true. I presume you focussed on SCP because you took the dongle to mean literally the SCP component alone. Let's me try to construct an improved succint Palladium motivation and function description. We need to make clear the distinction that the programmability comes from the hardware/firmware/software ensble provided by: hardware: the SCP, new ring0 and code compartmentatlization (btw what are the Palladium terms for the new ring0 that the TOR runs in, and what is the palladium term for the code compartment that Trusted Agents run in -- I'd like to use consistent terminology) super-kernel: TOR operating in new ring0 software: palladium enabled applications using the features such as software attestation, and sealing with control rooted in hardware and the TOR So would it be fair to characterize the negative aspects of Palladium as follows: "Palladium provides an extensible, general purpose programmable dongle-like functionality implemented by an ensemble of hardware and software which provides functionality which can, and likely will be used to expand centralised control points by OS vendors, Content Distrbuters and Governments." So I think that statement though obviously less possitively spun than Microsoft would like perhaps addresses your technical objections with the previous characterization. btw I readily concede of course that Palladium platform offers the security compartmentalization and software assurance aspects anonymous and Peter Biddle have described; I am just mostly examining the flip-side of the new boundary of applications buildable to data separation standards of security with this platform. One could perhaps construct a more balanced characterization covering both positive features and negative risks, but I'll let Palladium proponents work on the former. So to discuss your objections to the previous version of my attempted Palladium characterization: - as you say the hardware platform does not itself provide control points (I agree) - as you say, the TOR being publicly auditable does not itself provide control points however the platform can, and surely you can admit the risk, and even the likelihood that it will in fact be used to continue and further the existing business strategies of software companies, the content industry and governments. The dongle soldered to your motherboard can conspire with the CPU and memory management unit to lock the user out of selected processes running on their own machine. If you focus on the subset of buildable applications which operate in the users interests you can call this a good thing. If you look at the risks of buildable applications which can be used to act against the users interests it can equally be a very dangerous thing. Also if you look at historic business practices, legal trends, and the wishes of the RIAA/MPAA there are risks that these bad practices and trends will be futher accelerated, exarcerbated and more strongly enforced. I'd be interested to see you face and comment on these negative aspects rather than keep your comments solely on beneficial user functions, claim neutrality of low level features, and disclaim negative aspects by claiming at a low level user choice. The low level user choice may in the long run prove impractical or almost impossible for novice users, or even advanced users without hardware hacking tools, to technically exercise. (I elaborated on the possiblities for robust format compatibility prevention, and related possibilities a previous mail.) > I wouldn't say that it is "general purpose" either, but I am not > sure what you mean by this. I mean it is programmable in the sense that software attestation, certification and the endoresed new privileged ring0 code, together with the hardware enforced code compartments allow the protections of the firmware and hardware running in the SCP to be extended up to complete applications -- the Trusted Agents running in code compartments. That makes it general purpse because it is programmable. It could be used to build many classes of application across a spectrum of good, debatable and evil: - more flexibile and secure anonymity systems (clear user self-interest as anonymous suggested) - DRM (mixed positive and negative, debatable depends on your point of view) - and for example key-escrow of SCP support crypto functions implemented in the TOR accessed with say CAPI (very negative) > > >From my current understanding, the worst problem is the centralised > > control of this platform. If it were completely open, and possible to > > fix it's potential dangers, it would bring about a new framework of > > secured computing and could be a net positive. In it's current form > > with centralised control and other problems it could be a big net > > negative. > > There isn't centralized control in Pd. Users are in control. It is > up to whomever cares about the trust on a given system to decide if > they trust it, and this obviously must start with the user. You're focussing on the low level platform specifics, not on the bigger implications of the overall hardware, TOR, OS and software ensemble which I was talking about. Yes you can run different TORS. But using a specific (and audited published) TOR which the user may find himself choosing to run in order to run Palladium-enabled applications, all the applications, file formats, services and content which are tied to doing that -- control points could and likely will be built. It is my opinion that the directions and business pressures are such that meaningful distributed control is unlikely to be the long term result of the things that will be built using the Palladium hardware/software ensemble. This seems a fairly clearly consistent and predictable outcome, unless the software, IP law, RIAA/DMCA and legal systems all make an _astounding_ complete U-turn in policy and tacitcs coincident with the deployment of Palladium. Can you defend the arguement that Palladium and TCPA don't change the balance of control against the user and against personal control in our current balance between technical feasibility of building software systems enforcing third party control and law? (btw I'll stop nagging about documentation now, previous mail crossed with your reply on the topic). Adam -- "You do not examine legislation in the light of the benefits it will convey if properly administered, but in the light of the wrongs it would do and the harms it would cause if improperly administered." -- Lyndon Johnson --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From eresrch at eskimo.com Wed Aug 7 18:55:26 2002 From: eresrch at eskimo.com (Mike Rosing) Date: Wed, 7 Aug 2002 18:55:26 -0700 (PDT) Subject: Palladiated? (was re: wow - palladiated! (Re: Palladium: technical limits and implications)) In-Reply-To: Message-ID: On Wed, 7 Aug 2002, R. A. Hettinga wrote: > Status: RO > Date: Wed, 7 Aug 2002 22:40:56 +0100 > From: Adam Back > To: "R. A. Hettinga" > Cc: Adam Back > Subject: wow - palladiated! (Re: Palladium: technical limits and implications) > User-Agent: Mutt/1.2.2i > > On Wed, Aug 07, 2002 at 03:08:08PM -0400, R. A. Hettinga wrote: > > At 6:54 PM +0100 on 8/7/02, Adam Back wrote: > > > Palladiumized > > > > Palladiated? > > > > ;-). > > that's pretty funny, rhymes with irradiated -- nice connotations of > radioactive material with radioactive half-lives spewing > life-hazardous neutron radiation ;-) > > Helps that palladium is in fact a heavy metal. Man, perhaps Pd even > _has_ a half-life on the decay path from plutonium down to lead or > something. That would be very funny. > > Adam > Yeah, well Pd has 46 protons and atomic numbers ranging from 91 to 124. Most are stable, but some have half lives in the micro to millisecond range, a few with hours to days and 1 with 6.5 million years. It's just before silver, so it's most likely to be found in nuclear reactors as a fission product. I'd have to dig some more to find its neutron cross section :-) Patience, persistence, truth, Dr. mike From rah at shipwright.com Wed Aug 7 16:12:16 2002 From: rah at shipwright.com (R. A. Hettinga) Date: Wed, 7 Aug 2002 19:12:16 -0400 Subject: Palladiated Huber: "Software's Cash Register", Forbes, 10/18/93 Message-ID: A blast from the past for you Proto-Palladium fans. I remember reading this before I discovered the One True Cypherpunk Religion the following summer and thinking, "yeah, that's cool". Unfortunately, nowdays, for all my admiration for Dr. Huber, it just makes me laugh out loud... Cheers, RAH ------- http://www.phuber.com/huber/forbes/101893.html SOFTWARE'S CASH REGISTER by Peter Huber Forbes, October 18, 1993 at Pg. 314 Copyright 1993 by Peter Huber. ------- People still boast about making money the old-fashioned way, but the new way is faster. Henry Ford, Thomas Edison and Sam Walton moved people and things: factory workers, wire cable, salesclerks, soda. That meant heavy lifting, which is slow. Nowadays you get rich quick moving bits and bytes. A lot more people are going to get rich that way in the coming years, because the software industry has finally perfected a cash register. To understand how important this is, begin with the basics. To get rich selling widgets, you must move a lot of widgets. And wherever else you may move them, you must move them past a cash register. Unfortunately, things that are easy to meter at the checkout counter -- solid things like Doritos, say -- are comparatively hard to move. The easiest thing to move is information. But until now, information has been hard to meter. The entertainment business has already shown us what kind of wealth can be created out of a commodity as fluid as air if you can somehow get people to pay for it. Think of the television set as a retail outlet, and Bill Cosby as a merchant who can peddle JELL-O to 30 million people at the same time. Sure, the people who stuff gelatin into boxes and ship them to stores may prosper, too, but on nowhere near the same scale as Cosby, who can move his goods at the speed of light. Television created only a handful of Cosbys. Personal computers will create thousands. The 60 million or so PCs placed on U.S. desktops are where the next generation of superrich are setting up their cash registers. The retail outlets themselves -- the desktop computers -- aren't necessarily a source of wealth. Remember that the founders of such hardware producers as Apple Computer, Dell Computer, Tandon Corp., Wang Laboratories and Digital Equipment Corp. all appeared among The Forbes Four Hundred in years past, only to fall by the wayside. The key conceptual leaps -- that microprocessors can power PCs, PCs sell, and they sell by mail -- have already been made. The hardware end of the computer industry now depends largely on the silicon equivalent of toting buckets, lifting bales and coordinating armies of salaried gophers who swallow up much of an entrepreneur's revenue. Software is a different story. It's where the future money is. The program creators who sell through these desktop retail outlets don't need heavy lifting and lots of capital to get their businesses off the ground -- so they don't need to give their companies away to venture capitalists to pay for the launch. Thus it is that this year's Forbes Four Hundred includes at least a dozen software vendors, including three from Microsoft (Gates, Allen, Ballmer), two each from Quark (Gill and Ebrahimi) and WordPerfect (Ashton and Bastian), and one each from Novell (Noorda), Oracle (Ellison) and BMC (Moores). Most of these weren't on the list four years ago. To make a mint on software, just think. Think alone, if you can, or at worst with a tiny team of fellow nerds. Write a program that helps other people think better -- a spreadsheet, a database, an electronic checkbook. Run off a million copies on floppy disks, at a cost of a buck or two each. Then sell them at $195 plus tax. None of this is easy, of course, but that's not the point. If you do somehow pull it off, you do it pretty much on the back of your own sweat equity. It's like one of those 1950s ads for making money at home that you used to see in Popular Mechanics: Zero investment. Infinite profit. Instantly. Just add genius. That, in any event, is how it should work. If it doesn't quite yet, the reason lies in the shortcomings of the cash register. We're still no good at metering information in its pure form, so software must be contained on something clumsy like a floppy disk, just to accommodate the bookkeepers. That means getting shelf space at Egghead Discount Software or some other retailer before you can make millions from your musical spreadsheet program. And there is only so much shelf space. Software is as light as electrons, but to make a buck you still have to put it on a truck. Microsoft persuades hardware distributors like Dell to bundle its software into the hardware. But for every Bill Gates there are 10,000 programmers, photographers and cinematographers who never get a chance to present their wares to consumers at all. Many of those wares would sell -- more than a few would sell spectacularly -- if they could be placed smack in front of potential buyers, without the trucks or the shelves. People have been trying to eliminate this physical side of the software industry for years. The disciples of "shareware" have built up a cottage industry giving programs away over electronic bulletin boards. If you like what you get for free, you're invited to contribute $10 or so for a manual and upgrades. Shareware is a wonderful little economy, but the honor system works only for things that are cheap, and it's hard to get really rich on things that are cheap. Enter Peter Sprague, chairman of National Semiconductor, where he makes not too much money the old-fashioned way, and founder of a little company called Wave Systems Corp., where he hopes to help software creators make a ton of money the new way. Wave Systems has developed an information meter. And its product, or one like it, is going to redefine the software industry. Sprague's first basic insight is that we already have in hand ways to distribute software very, very cheaply. Compact disks, for example -- the enormously capacious optical platters that are fast becoming standard features on PCs. These disks are cheap to reproduce, and a handful of them can store every floppy (and the manuals, too) that you see on the shelves of your local Egghead Discount Software store. Internet, cable television or the airwaves can also distribute almost limitless amounts of software. Delivering software from the next Ridgely Evers (developer of Quickbooks for Intuit) to where people want to use it (on their computers) is as easy now as delivering The Three Stooges across cable TV. So, reasoned Sprague, why shouldn't software developers distribute their programs by putting them out on display where the software is most likely to be bought: on the personal computer itself. Throw it onto a compact disk anthology that will go into the box with the computer, or offer it continuously over networks or the airwaves. Sprague's second insight was that no developer will use the information superhighway that already exists until there are toll gates that allow him or her to collect something for the product. Sprague has the toll gate: an electronic meter that can track who's using what program, and can bill the user for it. It's a chip that can be built for less than $30 and installed in any computer. For now, Sprague may license it to computer manufacturers, but in time, I'd guess, he'll get all his revenue from software and database vendors. They stand to benefit the most. The Wave clip's first function is to unwrap software. Example: WordPerfect is broadcast across a wireless network in encrypted form. The Wave chip decodes. The other thing Sprague's chip does is establish credit, in much the same way as a Pitney Bowes postage machine or a French pay phone card. Through your computer modem the chip can call up your credit card company, and make sure that the right people get paid whenever you decide to buy. That will typically mean a big cut for the software vendor, perhaps a smaller cut for the company that manufactured the computer, and a still smaller cut for Wave. Pricing schemes of every imaginable kind can be supported. As I discussed in a recent column (FORBES, Sept. 27), selling software efficiently requires flexible, creative price structures. Sometimes you want to offer a dozen free test drives as a come-on. Sometimes -- with a brand-name program like WordPerfect, maybe -- you then want to charge a single, one-time, all-you-can-eat price. Sometimes -- as with electronic databases, perhaps -- you want to run a by-the-drink tab, so that people get charged only for articles retrieved and read, as a jukebox charges for records played. The cash register on a chip can handle it all. Cash registers and computers have always been kindred industries. Thomas J. Watson Sr. trained as a salesman at National Cash Register before turning IBM into the greatest selling organization around. Recently, AT&T paid a lot of money for NCR in order to expand its computer business. Now the PC is turning into a cash register once again, and it promises to boost many a software creator up the wealth ladder. -- ----------------- R. A. Hettinga The Internet Bearer Underwriting Corporation 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire' From eresrch at eskimo.com Wed Aug 7 19:28:23 2002 From: eresrch at eskimo.com (Mike Rosing) Date: Wed, 7 Aug 2002 19:28:23 -0700 (PDT) Subject: Palladium: hardware layering model In-Reply-To: <1c9905949ee6ae242d2b3fd69f09eb24@aarg.net> Message-ID: On Wed, 7 Aug 2002, AARG! Anonymous wrote: > What is special about ring-0? Two things: first, it can see the code > in the TE space so that it can execute it. And second, it doesn't > trap into supervisor mode for things like debugger single-stepping. > I'm not familiar with the details of the Pentium family but on most CPUs > the debugger single-steps things by setting a flag and returning into > the code. The code executes one instruction and then automatically traps > into supervisor mode, which hands off to the debugger. This process must > be suppressed in ring-0 mode, and likewise for any other features which > can force a ring-0 process to trap involuntarily into supervisor mode, > which exposes the registers and such. If there's no way to debug the "hidden" (so called "trusted") code using standard techniques, then how can you know it works right? Most all processors now have hardware debugging capability - it is a requirement due to the complexity of the chips. *Somebody* has to be able to run a hardware debugger and have access to the raw hardware, even if it's just Intel running with the covers off. If I'm going to write a TOR, I want access to internal registers. So I'd expect there's a hardware interface to do that. This basicly breaks the whole thing. You can't have a generic platform *and* a trusted platform. You can have a trusted platform which is *specific* - nobody but the manufacturer knows the guts. If people want to buy it because it does something useful, that's ok, but don't call it a generic PC. As an aside, check out http://www.beastrider.com it's a hardware debugger for a DSP (which I built). The Intel processor may not work the same way, but it's got to have some kind of similar interface, and anybody like me can build an interface into it. If the processor is sealed into a tamper proof case (like the IBM 4875) Then it can be made secure for one manufacturer. The system is checked before being sealed. If people want to add one to their PC they are free to do so, but they understand who owns the key inside the sealed case. With TCPA people do not know who owns the key - and that's its basic problem. Until we know real hardware details, we're not really going to figure out what's going on. Since Palladium guys claim that TCPA doesn't do what they want, it seems that the hardware hasn't been figured out yet. If the processor isn't sealed to prevent people like me from building hardware debuggers, then Palladium will be cracked by someone. If it is sealed then it's not a generic PC anymore. I don't think it's possible to outlaw a generic pc, but I guess I'm not willing to let congress begin to think about it either :-\ Patience, persistence, truth, Dr. mike From eugen at leitl.org Wed Aug 7 10:35:14 2002 From: eugen at leitl.org (Eugen Leitl) Date: Wed, 7 Aug 2002 19:35:14 +0200 (CEST) Subject: dangers of TCPA/palladium - will the real anon shady please stand up? In-Reply-To: Message-ID: On Wed, 7 Aug 2002, Sunder wrote: > Not to detract from my own arguement, but to entertain you a bit > further, style can be forged. There are even "Best of Bad Hemmingway" > contests and books for example. Style means nothing. It's as easy to > copy as posting mp3's on a p2p network. You're of course aware that even shallow textual analysis of list archives allows good fingerprinting of even casual posters. Even if we all would post anonymously you could still build reliable clusters. It is impossible to scramble that signature as long as your posts are nontrivial in length by pretending to be somebody else. I'm not aware of a fully automated tool to reliably scramble that fingerprint. (Pointers welcome). Doing it semimanually is prohibitively expensive in a forum such as this. From adam at cypherspace.org Wed Aug 7 13:38:55 2002 From: adam at cypherspace.org (Adam Back) Date: Wed, 7 Aug 2002 21:38:55 +0100 Subject: Palladium: hardware layering model (Re: Palladium: technical limits and implications) In-Reply-To: <51678c581368e18c35beca5d8665c528@aarg.net>; from remailer@aarg.net on Wed, Aug 07, 2002 at 12:35:12PM -0700 References: <51678c581368e18c35beca5d8665c528@aarg.net> Message-ID: <20020807213855.A597654@exeter.ac.uk> some definitions: hw layer -- SCP which I think provides crypto key store, crypto co-processor for sealing, remote attesation ring 0 -- new layer which controls memory management unit and secured code compartments supervisor mode -- normal supervisor mode, which can now only read user space, but not trusted agents running in code compartments user mode -- legacy user level apps under complete control of supervisor mode and some ASCII art: +---------------+------------+ | trusted-agent | user mode | | space | app space | | (code +------------+ | compartment) | supervisor | | | mode | +---------------+------------+ | ring-0 / Memory mgmt unit | +----------------------------+ | hardware / SCP key manager | +----------------------------+ each layer below can decide policy and information disclosure through APIs to the layer above. The implications of which are: - the SCP can implement sealing with data separation against ring-0 (ring-0 can't bypass sealing data separation) - ring-0 can read all superviser, user, and trusted agent space, but - ring-0 and MMU can compartmentalize trusted agents so they can't tamper with each other, and - ring-0 and MMU can exclude supervisor mode from trusted agent space and ring-0 space; supervisor mode is itself just another compartmentalized trusted-agent level space. Therefore ring-0 can restrict what supervisor mode (where the normal OS is located) can do. whereas the normal protected CPU architecture is just: +------------+ | user mode | | app space | +------------+ | supervisor | | mode | +------------+ - from these assumptions it appears an OS could be implemented so that all OS calls pass through ring-0 APIs and mediation to get to supervisor mode OS. In this case the OS could observe system calls the trusted agent makes, but not in general read, debug, modify virtualize or modify trusted-agent code. The non-virtualization presumes encrypted trusted-agent code, which Peter said is not done, so this can't be how it works. I would be interested to hear what model takes for Palladium mapping the interactions and restrictions between Trusted Agents, user space, OS kernel, TOR to the hardware. We need this kind of detail to reason about limits of the Palladium and make distinctions between what is possible with Palladium implementation choices vs what other types of OSes could be built from the hardware features. One idea I think would be interest is as follows: - the TOR (which lives in ring-0) _could_ be used together with the OS to force all trusted-agent in-flows and out-flows (network traffic) to go through code under supervisor mode control. I don't think this is likely in the current design; but this change would be an improvement: - it would at least allow user audit and control of in-flows and out-flows; - the user could block suspicious phone-home information out-flows, - the user could read out-flows and demand un-encrypted documented formats, or if encrypted, encrypted with keys the supervisor mode gets copies of. - similarly in-flow control is interesting, because with no in-flows a trusted agent could be more liberally allowed to make out-flows (if it has no input knowledge, and is in a code compartment, and the user gave it no sensitive it doesn't know anything to leak.) (Even with encrypted code, or public code which could not otherwise be audited actively in the sense of debugging it's actual operation to see what it does in practice in your machine given your data and circumstances rather than looking at static code and third party certifications to try to deduce that. Not all apps may be unencrypted (a TOR and SCP could clearly be built to support this feature). So on anonymous comments about OS control: > Obviously no application can reliably know anything if the OS is > hostile. Any application can be meddled with arbitrarily by the OS. I'm not sure if anonymous is just generalising when he says the app can't in any circumstances know anything if the OS is hostile, but I think it could potentially know things if the OS is hostile. As I described with the control and layer I think the palladium hardware uses. It seems possible to build some of separations and exclude the OS from certain types of application. It depends what you include in the OS; if the OS includes the TOR, then no. But it was stated that the TOR is somewhat independent from the OS. You could mix and match and use an MS Palladium TOR with linux potentially (though perhaps not in practice, it would have to be designed to allow it). It also depends on how the OS, trusted agents and supervisor mode is mapped to the hardware. > What Palladium can do, though, is arrange that the app can't get at > previously sealed data if the OS has meddled with it. The sealing > is done by hardware based on the app's hash. So if the OS has changed > the app per the above, it won't be able to get at old sealed data. Peter seemed to claim these kinds of assurance. Sealing doesn't prevent application virtualization, it just prevents the sealed data being shared between non-virtualized instances of the apps and virtualized instances. So I was wondering how Peter could simultaneously claim that encryption was not used and that "SW can known that it is running on a given platform." > And of course remote attestation will not work either, if the app > has been meddled with. Remote attestation, which is not itself general -- just a remote dongle thing -- if not tied to remote dongle controlled sealing which is necessary for the main application function could be nopped out. So in the general case it seems that remote attestation is also effectively virtualizable, modifiable and debuggable by first nopping out remote attestation checks. (This is not strictly virtualizable as the remote dongle call nopping modification makes it no longer the same application, but as I said unless this is necessary for the application it doesn't otherwise change it's behavior, so it's effectively virtualizable). Adam From Pete.Chown at skygate.co.uk Wed Aug 7 14:07:25 2002 From: Pete.Chown at skygate.co.uk (Pete Chown) Date: 07 Aug 2002 22:07:25 +0100 Subject: Challenge to TCPA/Palladium detractors In-Reply-To: References: Message-ID: <1028754445.1812.78.camel@yeltsin.mthink> Anonymous wrote: > I'd like the Palladium/TCPA critics to offer an alternative proposal > for achieving the following technical goal: > > Allow computers separated on the internet to cooperate and share data > and computations such that no one can get access to the data outside > the limitations and rules imposed by the applications. On balance, I suspect I would say that this is not a desirable goal. I can see that it has its uses, but I think they are outweighed by the fact that I would no longer have complete control of my own computer. "Complete control" means being able to lie if I choose to. If it is coming anyway, I think the harm would be mitigated if two features were provided: Firstly, there should be no discrimination between operating systems. I want to be able to run a version of Linux (or any other operating system) that makes use of the hardware security features. If I built my own operating system, people might not trust it as much as operating systems that are better known. Fine, that's the way trust works. But I still want my operating system to be able to use the hardware. The signatures would be for "program foo running on PeteOS", so making clear to the relying party that the signature is only as good as my operating system's security. Secondly, there should be no discrimination between applications. I should be able to write a DRM system that works in the same way as any RIAA-approved one. Of course people may not trust my system, that's their choice. I'd be interested to know what the experts think -- will this functionality be available to me? -- Pete --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From adam at cypherspace.org Wed Aug 7 14:21:42 2002 From: adam at cypherspace.org (Adam Back) Date: Wed, 7 Aug 2002 22:21:42 +0100 Subject: Challenge to TCPA/Palladium detractors In-Reply-To: ; from remailer@aarg.net on Wed, Aug 07, 2002 at 12:50:29PM -0700 References: Message-ID: <20020807222142.A596971@exeter.ac.uk> On Wed, Aug 07, 2002 at 12:50:29PM -0700, AARG!Anonymous wrote: > I'd like the Palladium/TCPA critics to offer an alternative proposal > for achieving the following technical goal: > > Allow computers separated on the internet to cooperate and share data > and computations such that no one can get access to the data outside > the limitations and rules imposed by the applications. The TCPA/Palladium folks have been working on this for apparently around 5 years. We don't yet have a complete definition of what Palladium is, but anyway... > Can you fix those problems and still achieve the basic goal, above? It may be that some interesting hardware, TOR and OS design changes could be added which could change the balance. Other aspects are as John Denker said more to do with who will control keys and policies and how much effective user control and choice remains over these policies. My initial thoughts were around hardware and TOR enforced in-flow and out-flow control to trusted agents. This idea was seeded by the smart-card setting of Stefan Brands digital credentials. (Read [1] if you are interested, it's a very clever idea, related to observers in cryptogaphic protocols in hardware settings). Briefly the observer in Brands protocol (and observers have been proposed in other cryptogaphic literature also) tackles an analogous problem with cryptographic assurance in the special purpose case of privacy preserving credentials, e-cash and other applications that can be built from those techniques. You have a tamper-resistant smart card. However the user can't reasonably audit the behavior of the smart-card processor because it intentionally hides it's keys from the user. Even if the source is published, audited, and claims and endoresments about the hardware made, the user still can't easily audit or reasonablly trust what is actually in his smart-card. The tamper-resistant smart card is somewhat related to the crypto functions of the SCP in Palladium or the TPM in TCPA, but the observer approach may offer lessons for TCPA/Palladium in general at higher levels. The tamper-resistant smart card is considered untrusted and hostile to user privacy. The tamper-resistant smart card processor and software is acting in the interests of the credential issuer / ecash issuer to prevent the user double-spending coins (*) / using credentials more times than allowed. The user has a general purpose computer running software he can completely audit, control observe running and modify. The smart-card has to make all communications with ecash acccepting merchants, certificate verifiers etc via the general purpose computer the smart-card is connected to. The general purpose computer implements the observer protocols. The smart-card setting variant of Brands protocol cryptographically assures 2 things: - the ecash issuer / credential CA can be assured that the user can not double spend (or in general violate other properties mediated by the tamper-resistant smart card) - the user is cryptographically assured that the smart-card can not invade his privacy. This works because the in-flows and out-flows to the smart card are hardware assured to pass via the general purpose computer, auditable, use published formats and are cryptographically blinded, to the extent of optimally frustrating even subliminal channels, via steganography and the like. In the same way that TCPA/Palladium are a generalisation of the dongle concept, this would be a generalisation of the cryptographic concept of observers. So for your convenience here's a cut and paste of that initial thought on applying the observer principle to general purpose TCPA/Palladium platform from the previous message with subject "Palladium: hardware layering model": I wrote in that message: | One idea I think would be interest is as follows: | | - the TOR (which lives in ring-0) _could_ be used together with the OS | to force all trusted-agent in-flows and out-flows (network traffic) to | go through code under supervisor mode control. | | I don't think this is likely in the current design; but this change | would be an improvement: | | - it would at least allow user audit and control of in-flows and | out-flows; | | - the user could block suspicious phone-home information out-flows, | | - the user could read out-flows and demand un-encrypted documented | formats, or if encrypted, encrypted with keys the supervisor mode gets | copies of. | | - similarly in-flow control is interesting, because with no in-flows a | trusted agent could be more liberally allowed to make out-flows (if it | has no input knowledge, and is in a code compartment, and the user | gave it no sensitive it doesn't know anything to leak.) this is not a fully fleshed out idea as I only thought of it yesterday, and can't fully analyse it's implications because we don't yet know proper details of what Palladium hardware is, nor how microsofts proposed Palladium enhanced windows would be implemented on that hardware. Adam (*) Actually he will still be caught and identified with Brands ecash protocols when the coins are deposited if he does double-spend coins after breaking hardware tamper-resistance, but that is a level of detailed not central to this discussion. [1] "A Technical Overview of Digital Credentials", Stefan Brands, Feb 2002, to appear in International Journal on Information Security. See Section 8. http://www.xs4all.nl/~brands/overview.pdf --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From adam at cypherspace.org Wed Aug 7 14:40:56 2002 From: adam at cypherspace.org (Adam Back) Date: Wed, 7 Aug 2002 22:40:56 +0100 Subject: wow - palladiated! (Re: Palladium: technical limits and implications) Message-ID: On Wed, Aug 07, 2002 at 03:08:08PM -0400, R. A. Hettinga wrote: > At 6:54 PM +0100 on 8/7/02, Adam Back wrote: > > Palladiumized > > Palladiated? > > ;-). that's pretty funny, rhymes with irradiated -- nice connotations of radioactive material with radioactive half-lives spewing life-hazardous neutron radiation ;-) Helps that palladium is in fact a heavy metal. Man, perhaps Pd even _has_ a half-life on the decay path from plutonium down to lead or something. That would be very funny. Adam --- end forwarded text -- ----------------- R. A. Hettinga The Internet Bearer Underwriting Corporation 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire' --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From mv at cdc.gov Wed Aug 7 23:43:54 2002 From: mv at cdc.gov (Major Variola (ret)) Date: Wed, 07 Aug 2002 23:43:54 -0700 Subject: commercial birds over Qatar, differential imagery in open press, Pgon not happy Message-ID: <3D52132A.519EB81B@cdc.gov> http://www.globalsecurity.org/org/news/2002/020806-iraq1.htm Tim Brown of the defense think tank Globalsecurity.org which has published an extensive analysis of the latest satellite imagery on its web site, said the base "looks like it is being designed to replace the Prince Sultan Air Base in Saudi Arabia so we don't have to rely on the Saudis for this operation." Pentagon officials last night refused to discuss details of the preparations at al Udeid. One added that planners are "not happy" the images are floating around on the Internet - "but [we] realize there's nothing we can do." From lpublishing at sympatico.ca Wed Aug 7 21:19:34 2002 From: lpublishing at sympatico.ca (MG PUBLISHING) Date: Thu, 8 Aug 2002 00:19:34 -0400 Subject: Subsidies, Grants and loans available Message-ID: <200208080419.g784JcoA009960@ak47.algebra.com> MG PUBLISHING (Canada) 4865 Highway 138, R.R. 1 St-Andrews west ON K0C 2A0 MG PUBLISHING (United States) 73 Prim road # 216 Colchester VT 05446 PRESS RELEASE CANADIAN SUBSIDY DIRECTORY 2002 & AMERICAN GRANTS AND LOANS DIRECTORY 2002 (Legal deposit, ISBN: 2-922870-04-9 & 2-922870-02-2) M.G. Publishing is offering to the public a revised edition of the Subsidies, Grants and loans directories, guides containing more than 1400 and 2800 direct and indirect financial subsidies, grants and loans offered by government departments and agencies, foundations, associations and organizations. In these new 2002 editions all programs are well described. The Subsidies, Grants and loans directories are the most comprehensive tools to start up a business, improve existent activities, set up a business plan, or obtain assistance from experts in fields such as: Industry, transport, agriculture,communications, municipal infrastructure, education, import-export, labor, construction and renovation, the service sector, hi-tech industries, research and development, joint ventures, arts, cinema, theatre, music and recording industry, the self employed, contests, and new talents. Assistance from and for foundations and associations, guidance to prepare a business plan, market surveys, computers, and much more! Each directory is sold $ 49.95, to obtain a copy please call one of the following bookstores: American Publications: (866)322-3376 Business Resource Center: (250)381-4822, 8am-4pm pacific time. Fureteur bookstore: (450)465-5597, Fax: (450)465-8144 (credit card orders only). From cee4477632111 at yahoo.com Wed Aug 7 22:25:18 2002 From: cee4477632111 at yahoo.com (cee4477632111 at yahoo.com) Date: Thu, 8 Aug 2002 01:25:18 -0400 Subject: How about Earning a College Degree At Home? 632111000 Message-ID: <200208080237.KAA07417@bkkss.dyndns.org> Obtain a prosperous future, money earning power, and the admiration of all. Degrees from Prestigious Accredited Universities based on your present knowledge and life experience. CALL NOW to receive your diploma within days!!! 1 425 790 3463 No required tests, classes, books, or interviews. Bachelors, masters, MBA, and doctorate (PhD) diplomas available in the field of your choice. No one is turned down. Confidentiality assured. CALL NOW to receive your diploma within days!!! 1 425 790 3463 Call 24 hours a day, 7 days a week, including Sundays and holidays. 632111000 From adam at cypherspace.org Wed Aug 7 18:48:19 2002 From: adam at cypherspace.org (Adam Back) Date: Thu, 8 Aug 2002 02:48:19 +0100 Subject: Palladiated? (was re: wow - palladiated! (Re: Palladium: technical limits and implications)) In-Reply-To: ; from rah@shipwright.com on Wed, Aug 07, 2002 at 06:37:51PM -0400 References: Message-ID: <20020808024819.A600037@exeter.ac.uk> [Trimmed Cc a bit, I'll let Bob decide where it goes beyond this]. Now that Bob coined the neologism "palladiated" (blame Bob -- my "palladiumized" was not in jest, just used in the middle of a tech discussion) it has to be done, so I asked the universal oracle (google.com) about palladium and half-life, and lo the Pd-103 isotope has a 17-day half-life, and Pd-109 of 13.5 hours and are classified as having moderate radiotoxicity. Unfortunately for Bob's neologism not quite up there with fission grade isotopes like like Plutonium which rate as very high toxicity, but still you wouldn't want to ingest to much of the stuff... Pd isotopes are obtained by bombarding Gold with neutrons apparently. http://www.stevequayle.com/Shop/Radiation/Radiotoxicity.appendix.html Anyway, now back to the intersting tech discussion on the balance of of owner vs third party control in the MS Palladium and TCPA platforms... Adam On Wed, Aug 07, 2002 at 06:37:51PM -0400, R. A. Hettinga wrote: > Evidently, I have permission to pass this along. :-). > > Don't try this at home, boys and girls. This is a professional neologist at > work... > > Cheers, > RAH > Comedy is not pretty... > > --- begin forwarded text > > Date: Wed, 7 Aug 2002 22:40:56 +0100 > From: Adam Back > To: "R. A. Hettinga" > Subject: wow - palladiated! (Re: Palladium: technical limits and implications) > > On Wed, Aug 07, 2002 at 03:08:08PM -0400, R. A. Hettinga wrote: > > At 6:54 PM +0100 on 8/7/02, Adam Back wrote: > > > Palladiumized > > > > Palladiated? > > > > ;-). > > that's pretty funny, rhymes with irradiated -- nice connotations of > radioactive material with radioactive half-lives spewing > life-hazardous neutron radiation ;-) > > Helps that palladium is in fact a heavy metal. Man, perhaps Pd even > _has_ a half-life on the decay path from plutonium down to lead or > something. That would be very funny. > > Adam From sm001171862 at yahoo.com Wed Aug 7 23:58:50 2002 From: sm001171862 at yahoo.com (sm001171862 at yahoo.com) Date: Thu, 08 Aug 2002 02:58:50 -0400 Subject: 1st Worldwide Automated Marketing System! - Take A FREE Tour!! Message-ID: A non-text attachment was scrubbed... Name: not available Type: text/html Size: 7423 bytes Desc: not available URL: From adam at cypherspace.org Wed Aug 7 22:34:15 2002 From: adam at cypherspace.org (Adam Back) Date: Thu, 8 Aug 2002 06:34:15 +0100 Subject: Palladium: hardware layering model In-Reply-To: <1c9905949ee6ae242d2b3fd69f09eb24@aarg.net>; from remailer@aarg.net on Wed, Aug 07, 2002 at 04:55:11PM -0700 References: <1c9905949ee6ae242d2b3fd69f09eb24@aarg.net> Message-ID: <20020808063415.A590658@exeter.ac.uk> On Wed, Aug 07, 2002 at 04:55:11PM -0700, AARG!Anonymous wrote: > Adam Back wrote: > > +---------------+------------+ > > | trusted-agent | user mode | > > | space | app space | > > | (code +------------+ > > | compartment) | supervisor | > > | | mode | > > +---------------+------------+ > > | ring-0 / Memory mgmt unit | > > +----------------------------+ > > | hardware / SCP key manager | > > +----------------------------+ > > > > each layer below can decide policy and information disclosure through > > APIs to the layer above. > > I don't think this is right, as Peter said that the Palladium stuff could > load many days after boot. So I don't think the "ring-0" mode underlies > normal supervisor mode as you have shown it. Instead I think they are > relatively orthogonal. No I think the above diagram is closer than what you propose. Peter also pointed us at Seth Schoen's blog [1] which is a write up of a briefing Microsoft gave to EFF. It contains the statement: | The nub is a kind of trusted memory manager, which runs with more | privilege than an operating system kernel. The nub also manages access | to the SCP. Looks consistent with my picture to me. Your other objection: > I don't think this is right, as Peter said that the Palladium stuff could > load many days after boot. I think would just be covered by the details of how the machine switches from this picture: +------------+ | user mode | | app space | +------------+ | supervisor | | mode | +------------+ to the one above. For example imagine a default stub nub/TOR that leaves the new MMU features wide open. (Supervisor mode can access everything, no Trusted Agent code compartments running). The would be some API to allow the supervisor mode code to load a TOR and switch the TOR code to ring-0 while leaving the OS running in supervisor mode. Or alternatively and with equivalent effect: with the boot state, the OS runs in full ring-0 mode, but just isn't written to make use of any of the extra ring-0 features. When it switches to loading a nub/TOR the OS is relagated to supervisor mode, some MMU permission bits are juggled around and the TOR occupies ring-0, and the TOR is just an OS micro-kernel which happens to be written to use the new hardware features (code compartmentalization, new MMU features, sealing etc) Clarification on this: > > So in the general case it seems that remote attestation is also > > effectively virtualizable, modifiable and debuggable by first nopping > > out remote attestation checks. (This is not strictly virtualizable as > > the remote dongle call nopping modification makes it no longer the > > same application, but as I said unless this is necessary for the > > application it doesn't otherwise change it's behavior, so it's > > effectively virtualizable). > > I'm not sure I follow this, but it sounds like you are talking about > manipulating the server machine doing the checks, while in most cases > you can only manipulate the client machine making the request. Not what I meant. Say that you have some code that looks like this: /* some code */ if ( ! remote_attest( /* ... */ ) ) { exit 0; } /* lots more code */ then the remote attest is not doing anything apart from acting as a remote dongle, so all I have to do to virtualize this code, or break the licensing scheme based on the remote dongle is nop out the remote attest verification, then the code can be run as a user application rather than a trusted agent application and so can be run in a debugger, have it's state examined etc. If on the other hand the code says: download_sealed_content( /* ... */ ); key = remote_attest_and_key_negotiate( /* ... */ ); decrypt_sealed_content( key, /* ... */ ); then nopping out the remote_attest will have a deleterious effect on the applications function, and so virtualizing it with the remote attests nopped out will not be useful in bypassing it's policies. Adam -- http://www.cypherspace.org/adam/ From sunder at sunder.net Thu Aug 8 07:14:24 2002 From: sunder at sunder.net (Sunder) Date: Thu, 8 Aug 2002 10:14:24 -0400 (edt) Subject: Challenge to TCPA/Palladium detractors In-Reply-To: Message-ID: You can only do this if you can trust the hardware. As long as any potential untrustworthy folks have access to that hardware, it cannot be done. It is possible to do the rest of this if you manage to secure the machines from any other kinds of access by disabling all services other than that particular p2p (to prevent remote access overflows from insecure applications). If you see the network problem as a multi-ended VPN, that's the next part. But I do not see any way for any member of the network to certify that any other node is running exactly the same software, unless all nodes restrict access to the hardware and have an external certification process. If anyone anywhere can grab the software - binary or source and join the network while still having hardware access, all bets are off. The only thing the other nodes can certify is that the crypto signatures are right, and that the protocol is the same. But even if you sign the binaries, you don't know that the thing at the other end has the signature it just sent you. You can try to make things complex such as pushing binaries to the other node and having them run there, but you don't know if you're inside a VMware box, or Bochs emulator, or a real machine. Even if you can certify that the application does what you think it does, you can't ceritfy that the operating system or the hardware isn't going to do anything else. End of story. Can't be done so long as anyone other than you has root on the machine, or has physical access. Hence you need to buttplug the hardware and make it difficult to modify. Even so, you don't have any idea of if that CPU really is what it says it is, or that the hardware will do what you think it will do. Hardware can be replaced or patched with things that can look like the original, or things that at some opportune moment interrupt and switch out that hardware, then get full access to all the ram. No, I couldn't afford such hardware mods. But say someone that has enough money to own a DVD pressing factory certainly can afford the R&D. In the end TCPA/Palladium will be broken. Just the USG kept pushing single DES until even a bit after the DES cracker got built. I've no problem with that, nor the fact the RIAA/MPAA want to protect their warez - if they get that oppresive, I won't be buying it, and I'm positive that others won't either... In the end, they'll just be burning a lot of money and find out that they'll go broke. Ironic? Yup. As long as it's a free market, they'll fry for pissing off their consumers. I do have a problem with having spyware forced down my machines by John Law. Intel wants to put Pd compliant chips in their mobo's, fine, I won't buy their hardware -- or if I do, I'll be sure to reflash the BIOS to a slightly different enough version without signatures to force the Pd chip to shut down... If it won't let me, their loss. There's still AMD. AMD joins intel? Fuck x86, there's still Sun, and Apple. The only way that Pd will be successful is if every hardware manufacturer is forced by law to include it. And I've no problem with MSFT making their software oppresive, they're just digging their own graves, I'll applaud as they sink in to the bog. Fuck'em. They're extinct. Long as the motherboard will let me boot whatever OS I want, long as Kongress keeps their paws out of my machine and doesn't extract a tax to pay the losers for their "losses", MSFT, Intel, MPAA, RIAA can do whatever they want. And no, I don't believe that making an open source, hardware free version of what they're trying to do will prevent Jackoff Vallenti from pushing dollars to kongress to close the PeeCee hole while sucking Bill Gates's balls simultaneously. In the end, the only guarantee you have is that the thing at the end is talking the same language as you and that anyone else can't snoop the traffic and see what's there - so long as your crypto-fu is good, and the security on both machines is decent enough to prevent them from being owned. So why bother? Just because the evil empire is running at full speed towards the precipice doesn't mean we need open source versions of the same insanity that drives'em. ----------------------Kaos-Keraunos-Kybernetos--------------------------- + ^ + :NSA got $20Bill/year|Passwords are like underwear. You don't /|\ \|/ :and didn't stop 9-11|share them, you don't hang them on your/\|/\ <--*-->:Instead of rewarding|monitor, or under your keyboard, you \/|\/ /|\ :their failures, we |don't email them, or put them on a web \|/ + v + :should get refunds! |site, and you must change them very often. --------_sunder_ at _sunder_._net_------- http://www.sunder.net ------------ On Wed, 7 Aug 2002, AARG! Anonymous wrote: > I'd like the Palladium/TCPA critics to offer an alternative proposal > for achieving the following technical goal: > > Allow computers separated on the internet to cooperate and share data > and computations such that no one can get access to the data outside > the limitations and rules imposed by the applications. > > In other words, allow a distributed network application to create a > "closed world" where it has control over the data and no one can get > the application to "cheat". IMO this is clearly the real goal of TCPA > and Palladium, in technical terms, when stripped of all the emotional > rhetoric. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From dog3 at eruditium.org Thu Aug 8 09:23:42 2002 From: dog3 at eruditium.org (cubic-dog) Date: Thu, 8 Aug 2002 12:23:42 -0400 (EDT) Subject: dangers of TCPA/palladium - will the real anon shady please stand up? In-Reply-To: Message-ID: On Wed, 7 Aug 2002, Sunder wrote: > IMNHO TCPA sucks balls. But "anonymous" has the right to speak > anonymously as does anyone, and most of us here will defend that right, > regardless of accepting or rejecting TCPA/Palladium/MSFT. Agreed, The argument stands or collapses on it's own merit. The true name of the author is meaningless. And yes, I also think it "sucks balls". From dog3 at eruditium.org Thu Aug 8 09:51:43 2002 From: dog3 at eruditium.org (cubic-dog) Date: Thu, 8 Aug 2002 12:51:43 -0400 (EDT) Subject: Challenge to TCPA/Palladium detractors In-Reply-To: Message-ID: On Wed, 7 Aug 2002, AARG! Anonymous wrote: > I'd like the Palladium/TCPA critics to offer an alternative proposal > for achieving the following technical goal: > > Allow computers separated on the internet to cooperate and share data > and computations such that no one can get access to the data outside > the limitations and rules imposed by the applications. Let me restate for clarity, "no one can get access to the data outside the limitations, et al." Simply put, (aside from the usual caveat of "with infinite time and resources") it can't be done in the sense of you and I sharing a document or some such model. Way too many variables/paths/unknowns. > In other words, allow a distributed network application to create a > "closed world" where it has control over the data and no one can get > the application to "cheat". IMO this is clearly the real goal of TCPA > and Palladium, in technical terms, when stripped of all the emotional > rhetoric. "it" I suppose means the "distributed network application". Using the term "no one" makes this whole idea pretty much impossible. "No one" exludes the sufficiently motivated who are willing to go to any lengths. Brute force in its actual sense pretty much always works. Also, when you state that your given scenario is "clearly the real goal" you have already discarded a whopping number of variables, all of which may bear on the challenge. *I* don't know that "this is clearly the real goal of TCPA and Palladium" at all. I accept your opinion as your opinion. I believe you are sincere in interest of discussion. However, it certainly is not my opinion at all. I am not at all clear on what exactly the problem is that TCPA and Palladium are supposed to solve. I presume, until I can be shown otherwise that "it" is a tool to further expand the power of patent and copywrite holders (or more to the point, their barristers) to impose their will on my freedom of speech. Since I don't want to play the part of the fellow who won't be convinced, all I ask is to be shown in clear terms EXACTLY what the problem is, and how EXACTLY this problem is solved by this technology. When I mean exactly, I mean in simple go/no-go logic. I don't need nor particularly want to see the technical specs. There are those out there, and here as well, who are much more qualified to review all that. From dog3 at eruditium.org Thu Aug 8 10:09:06 2002 From: dog3 at eruditium.org (cubic-dog) Date: Thu, 8 Aug 2002 13:09:06 -0400 (EDT) Subject: On alliances and enemies. In-Reply-To: <3D515A80.26774.385CDF@localhost> Message-ID: On Wed, 7 Aug 2002, James A. Donald wrote: > -- > Hollywood and the government, would like the internet to be like > television, a few big businesses steadily churning out content, > and everyone else passively consuming it. > > Microsoft really would not like that, since, despite all their > faults, they are in the computer business. > > lots of good stuff and analogies snipped Why not? For the purpose of this argument, lets accept as fact this Hollywood/gubbmint alliance. So, why wouldn't Bill & Co want to play? As long as they get a software subscription license fee from every "consumer" of the product, that can be added to everytime a new ground-breaking, earth-shattering, fancy super multimedia immersion technology "standard" is introduced? It *seems* to me that Microsoft wants out of even the software license model they currently have and want to just plug into the consumers "line of credit" and withdraw as they see fit without having to do much more than create easily obsolete-able software techniques that they can consistantly reinvent so that they can continue to siphon credit from their milkcows much in the same way that the gubbmint collects taxes, only with much better "ease of use." I don't see Stalin/Hitler, I see; Standard Oil/ Department of Transporation/ Interstate Commerce Commission) General Motors/ Ford/ and so forth. From dog3 at eruditium.org Thu Aug 8 11:11:56 2002 From: dog3 at eruditium.org (cubic-dog) Date: Thu, 8 Aug 2002 14:11:56 -0400 (EDT) Subject: dangers of TCPA/palladium In-Reply-To: <200208081725.TAA01877@home.unipay.nl> Message-ID: On Thu, 8 Aug 2002, R. Hirschfeld wrote: > > Date: Mon, 5 Aug 2002 16:25:26 -0700 > > From: AARG!Anonymous > > > The only way that TCPA will become as popular as you fear is if it really > > solves problems for people. Otherwise nobody will pay the extra $25 to > > put it in their machine. > > Although I support the vote-with-your-wallet paradigm, this analysis > seems overly simplistic to me. Macrovision doesn't solve problems for > most VCR purchasers, but they pay for it anyway. They have no choice. Well put! In fact, Macrovision creates problems for people, does very little to stop "theft of intellectual property". But what it does do is negatively impact the base product, share out a piece of the profits to an otherwise non-player, add a layer of annoyance, and accomplish nothing of benefit for the target, the end user, the one who pays the money. From rsedc at atlantic.gse.rmit.edu.au Wed Aug 7 22:12:00 2002 From: rsedc at atlantic.gse.rmit.edu.au (rsedc at atlantic.gse.rmit.edu.au) Date: Thu, 8 Aug 2002 15:12:00 +1000 Subject: Palladiated? (was re: wow - palladiated! (Re: Palladium: technical limits and implications)) In-Reply-To: ; from R. A. Hettinga on Wed, Aug 07, 2002 at 06:37:51PM -0400 References: Message-ID: <20020808151200.A28920@atlantic.gse.rmit.edu.au> > On Wed, Aug 07, 2002 at 03:08:08PM -0400, R. A. Hettinga wrote: > > At 6:54 PM +0100 on 8/7/02, Adam Back wrote: > > > Palladiumized > > > > Palladiated? > > And the antonym? Odyssielded. Rhymes with shielded. http://homepage.mac.com/cparada/GML/Odysseus.html Odysseus was the first to learned the Palladium Oracles from the Seer Hellenus. Odysseus neutralised (neutronised?) Palladium's defence for Troy. Odysseus invented the first Trojan Horse. Incidentally public revelation of the Palladium is supposed to be on Seventh Day to the Ides of Jun, i.e. 8th. June. The Newsweek article was a bit late. http://www.clubs.psu.edu/aegsa/rome/jun06.htm David Chia --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From remailer at aarg.net Thu Aug 8 16:55:45 2002 From: remailer at aarg.net (AARG!Anonymous) Date: Thu, 8 Aug 2002 16:55:45 -0700 Subject: Challenge to TCPA/Palladium detractors Message-ID: <8c708993eecdbee279fbe47fdeb4a0d0@aarg.net> Anon wrote: > You could even have each participant compile the program himself, > but still each app can recognize the others on the network and > cooperate with them. Matt Crawford replied: > Unless the application author can predict the exact output of the > compilers, he can't issue a signature on the object code. The > compilers then have to be inside the trusted base, checking a > signature on the source code and reflecting it somehow through a > signature they create for the object code. It's likely that only a limited number of compiler configurations would be in common use, and signatures on the executables produced by each of those could be provided. Then all the app writer has to do is to tell people, get compiler version so-and-so and compile with that, and your object will match the hash my app looks for. DEI --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From gbnewby at ils.unc.edu Thu Aug 8 15:39:24 2002 From: gbnewby at ils.unc.edu (Greg Newby) Date: Thu, 8 Aug 2002 18:39:24 -0400 Subject: AdCouncil PSAs Message-ID: <20020808223924.GA8285@ils.unc.edu> Holy fuck, I can't believe these new TV PSAs from the AdCouncil: http://www.adcouncil.org/campaigns/campaign_for_freedom I thought they were going to be rah-rah patriotic and stuff. In fact, they use scare tactics -- way beyond "this is your brain on drugs." I think these are to urge conformity and quell dissent, not celebrate freedom. Check out the "library," "church," "arrest" & "diner" PSAs especially. >From the PSA's descriptive text, "This first round of PSAs for the campaign has been created to celebrate our nation's freedom and remind Americans about the importance of freedom and the need to protect it for future generations." In fact, though, that's not the message I saw at all. The message I saw was scenes from one step -- a baby step -- beyond where we are now: reduced freedoms, neighbors monitoring and distrusting each other, overzealous and barely constrained law enforcement. Fear. The Web page says the PSAs are designed based on market research to "assist Americans during the war on terrorism." I don't understand why they used scare tactics in these but the outcome, for me, is a different interpretation of the PSA's tag-lines, "Freedom. Appreciate it. Cherish it. Protect it." What I hear is "what you have IS freedom, despite how it appears. See, we can show you how much worse it could be." Whew....Greg PS: I did a search in their calendar to see when these are supposed to air. Result: "'freedom' not found." From jamesd at echeque.com Thu Aug 8 18:59:48 2002 From: jamesd at echeque.com (James A. Donald) Date: Thu, 08 Aug 2002 18:59:48 -0700 Subject: On alliances and enemies. In-Reply-To: References: <3D515A80.26774.385CDF@localhost> Message-ID: <3D52BFA4.15416.1518E41@localhost> -- On 8 Aug 2002 at 13:09, cubic-dog wrote: > For the purpose of this argument, lets accept as fact this > Hollywood/gubbmint alliance. So, why wouldn't Bill & Co want to > play? A big bureaucracy has a lot of inertia. It wants to do what it always has been doing, it gets set in its ways. If the internet and consumer computers are mandated to be like TV, the TV people will wind up in charge, and Microsoft will not wind up in charge. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG OrPfArPJfauYoxApR4gFvBiF/ejwrZGskzoVEQJt 2QHCPliH2SKXP0eaVWlIy65Nye07RsyZOo8xbrIAA From ray at unipay.nl Thu Aug 8 10:25:31 2002 From: ray at unipay.nl (R. Hirschfeld) Date: Thu, 8 Aug 2002 19:25:31 +0200 Subject: dangers of TCPA/palladium In-Reply-To: <09fdc16bc6a040e13686c9150aca01d9@aarg.net> (message from AARG!Anonymous on Mon, 5 Aug 2002 16:25:26 -0700) References: <09fdc16bc6a040e13686c9150aca01d9@aarg.net> Message-ID: <200208081725.TAA01877@home.unipay.nl> > Date: Mon, 5 Aug 2002 16:25:26 -0700 > From: AARG!Anonymous > The only way that TCPA will become as popular as you fear is if it really > solves problems for people. Otherwise nobody will pay the extra $25 to > put it in their machine. Although I support the vote-with-your-wallet paradigm, this analysis seems overly simplistic to me. Macrovision doesn't solve problems for most VCR purchasers, but they pay for it anyway. They have no choice. In some cases people are required to buy and use something that they might not otherwise be inclined to pay for, e.g., catalytic converters in automobiles (which also use palladium). It doesn't seem reasonable to similarly require TCPA in computers, but legislators might think (or be lobbied) otherwise. If the fears that some people have expressed prove justified and TCPA becomes primarily a means to enforce draconian copyright restrictions, then people may well choose to pay for it just to regain pre-TCPA functionality. In that case, the problems it solves for them are the same ones it causes! --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From swpteam at hotmail.com Thu Aug 8 18:29:26 2002 From: swpteam at hotmail.com (steve) Date: Thu, 8 Aug 2002 20:29:26 -0500 Subject: FREE REPORT: Making over half million dollars every 4 to 5 months!!! Message-ID: <200208090129.g791TQJ1017369@ak47.algebra.com> Steven W. Pratt Ph: 610-842-6318 233 Brandywine Rd Collegeville, PA 19426 USING THE POWER OF INTERNET, READ THE FOLLOWING MESSAGE CAREFULLY AS SEEN ON NATIONAL TV: ''Making over half million dollars every 4 to 5 months from You're home for an investment of only $25 U.S. or CANADIAN Dollars expense one time'' THANKS TO THE COMPUTER AGE AND THE INTERNET! ================================================= BE A MILLIONAIRE LIKE OTHERS WITHIN A YEAR!!! Before you say ''Bull'', please read the following. This is the letter you have been hearing about on the news lately. Due to the popularity of this letter on the Internet, a national weekly news program recently devoted an entire show to the investigation of this program described below, to see if it really can make people money. The show also investigated whether or not the program was legal. Their findings proved once and for all that there are ''absolutely NO laws prohibiting the participation in the program and if people can follow the simple instructions, they are bound to make some mega bucks with only $25 out of pocket cost''. DUE TO THE RECENT INCREASE OF POPULARITY & RESPECT THIS PROGRAM HAS ATTAINED; IT IS CURRENTLY WORKING BETTER THAN EVER. This is what one had to say: ''Thanks to this profitable opportunity. I was approached many times before but each time I passed on it. I am so glad I finally joined just to see what one could expect in return for the minimal effort and money required. To my astonishment, I received total $ 610,470.00 in 21 weeks, with money still coming in''. Pam Hedland, Fort Lee, New Jersey. --------------------------------------------------- ----- **** PRINT THIS NOW FOR YOUR FUTURE REFERENCE **** $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ $$$$ If you would like to make at least $500,000 every 4 to 5 months easily and comfortably, please read the following...THEN READ IT AGAIN and AGAIN!!! $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ $$$$ FOLLOW THE SIMPLE INSTRUCTION BELOW AND YOUR FINANCIAL DREAMS WILL COME TRUE, GUARANTEED! INSTRUCTIONS: **** Order all 5 reports shown on the list below. **** For each report, send $5 CASH, THE NAME & NUMBER OF THE REPORT YOU ARE ORDERING and YOUR E- MAIL ADDRESS to the person whose name appears ON THAT LIST next to the report. MAKE SURE YOUR RETURN ADDRESS IS ON YOUR ENVELOPE TOP LEFT CORNER in case of any mail problems. **** When you place your order, make sure you order each of the 5 reports. You will need all 5 reports so that you can save them on your computer and resell them. YOUR TOTAL COST $5 X 5 = $25.00. **** Within a few days you will receive, via e- mail, each of the 5 reports from these 5 different individuals. Save them on your computer so they will be accessible for you to send to the 1,000's of people who will order them from you. Also make a floppy of these reports and keep it on your desk in case something happen to your computer. **** IMPORTANT __ DO NOT alter the names of the people who are listed next to each REPORT, or their sequence on the list, in any way other than what is instructed below in step '' 1 through 6 '' or you will loose out on majority of your profits. Once you understand the way this works, you will also see how it does not work if you change it. Remember, this method has been tested, and if you alter, it will NOT work!!! People have tried to put their friends / relatives names on all five thinking they could get all the money. But it does not work this way. Believe us, we all have tried to be greedy and then nothing happened. So Do Not try to change anything other than what is instructed. Because if you do, it will not work for you. Remember, Honesty reaps the reward!!! 1.... After you have ordered all 5 reports, take this advertisement and REMOVE the name & address of the person in REPORT #5. This person has made it through the cycle and is no doubt counting their fortune. 2. Move the name & address in REPORT #4 down TO REPORT #5 3. Move the name & address in REPORT #3 down TO REPORT #4 4. Move the name & address in REPORT #2 down TO REPORT #3 5. Move the name & address in REPORT #1 down TO REPORT #2 6. Insert YOUR name & address in the REPORT #1 Position. PLEASE MAKE SURE you copy every name & address ACCURATELY! ================================================= **** Take this entire letter, with the modified list of names, and save it on your computer. DO NOT MAKE ANY OTHER CHANGES. Save this on a disk as well just in case if you loose any data. **** To assist you with marketing your business on the Internet, the 5 reports you purchase will provide you with invaluable marketing information, which includes how to send bulk e-mails legally, where to find thousands of free classified ads and much more. There are 2 Primary methods to get this venture going: METHOD #1: BY SENDING BULK E-MAIL LEGALLY ================================================= Let's say that you decide to start small, just to see how it goes, and we will assume you and those involved send out only 5,000 e- mails each. Let's also assume that the mailing receive only a 0.2% response (the response could be much better but lets just say it is only 0.2%. Also many people will send out hundreds of thousands e-mails instead of only 5,000 each). Continuing with this example, you send out only 5,000 e- Mails. With a 0.2% response, that is only 10 orders for REPORT # 1. Those 10 people responded by sending out 5,000 e-mail each for a total of 50,000. Out of those 50,000 e-mails only 0.2% responded with orders. That's = 100 people responded and ordered REPORT # 2. Those 100 people mail out 5,000 e-mails each for a total of 500,000 e-mails. The 0.2% response to that is 1000 orders for REPORT # 3. Those 1000 people send out 5,000 e- mails each for a total of 5 million E-mails sent out. The 0.2% response to that is 10,000 orders for REPORT # 4. Those 10,000 people send out 5,000 e- mails each for a total of 50,000,000 (50 million) e-mails. The 0.2% response to that is 100,000 orders for REPORT # 5 THAT'S 100,000 ORDERS TIMES $5 EACH = $500,000.00 (half million). Your total income in this example is: 1...$50 + 2...$500 + 3...$5,000 + 4...$50,000 + 5...$500,000 Grand Total = $555,550.00 NUMBERS DO NOT LIE. GET A PENCIL & PAPER AND FIGURE OUT THE WORST POSSIBLE RESPONSES AND NO MATTER HOW YOU CALCULATE IT, YOU WILL STILL MAKE A LOT OF MONEY! --------------------------------------------------- -------- REMEMBER FRIEND, THIS IS ASSUMING ONLY 10 PEOPLE ORDERING OUT OF 5,000 YOU MAILED TO. Dare to think for a moment what would happen if everyone, or half or even one 4th of those people mailed 100,000 e-mails each or more? There are over 150 million people on the internet worldwide and counting. Believe me, any people will do just that, and more! _________________ AVAILABLE REPORTS __________________ ORDER EACH REPORT BY ITS NUMBER & NAME ONLY. Notes: Always send $5 cash (U.S. CURRENCY) or Canadian for each REPORT. Checks NOT accepted. Make sure the cash is concealed by wrapping it in at least 2 sheets of paper. On one of those Sheets of paper write the NUMBER & the NAME of the REPORT you are ordering, YOUR E-MAIL ADDRESS and your name and postal address. PLACE YOUR ORDER FOR THESE REPORTS NOW: ================================================= REPORT #1 ''The Insider's Guide to Advertising for Free on the Net'' Order REPORT #1 from: Steven Pratt 233 Brandywine Rd Collegeville, PA 19426 __ _________________________________________________ REPORT #2 ''The Insider's Guide to Sending Bulk e- mail on the Net'' Hubert Fulkerson 402 East Las Palmaritas Drive Phoenix, AZ 85020-3436 _________________________________________________ REPORT #3 ''The Secret to Multilevel marketing on the Net'' Order REPORT #3 from: Glen Kelly 890 Ravenwood Ct. Biloxi, Ms. 39532 ___________________________________________________ REPORT #4 ''How to become a millionaire utilizing MLM & the Net'' Order REPORT #4 from: C Shaw P.O. Box 468 Schomberg, Ontario Canada LOG ITO ___________________________________________________ REPORT #5 ''HOW TO SEND 1 MILLION E-MAILS FOR FREE'' Order REPORT #5 from: Elaine Rix 138 Dundas Street, West, #243 Toronto, Ontario Canada M5G 1C3 _________________________________________ $$$$$$$$$$$$ YOUR SUCCESS GUIDELINES $$$$$$$$$$$$$$ Follow these guidelines to guarantee your success: *** If you do not receive at least 10 orders for REPORT #1 within 2 weeks, continue sending e-mails until you do. *** After you have received 10 orders, 2 to 3 weeks after that you should receive 100 orders or more for REPORT #2. If you did not, continue advertising or sending e-mails until you do. *** Once you have received 100 or more orders for REPORT #2, YOU CAN RELAX, because the system is already working for you and the cash will continue to roll in! THIS IS IMPORTANT TO REMEMBER: Every time your name is moved down on the list, you are placed in front of a Different REPORT. You can KEEP TRACK of your PROGRESS by watching which REPORT people are ordering from you. IF YOU WANT TO GENERATE MORE INCOME SEND ANOTHER BATCH OF E-MAILS AND START THE WHOLE PROCESS AGAIN. There is NO LIMIT to the income you can generate from this business!!! ___________________________________________________ FOLLOWING IS A NOTE FROM THE ORIGINATOR OF THIS PROGRAM: "You have just received information that can give you financial freedom for the rest of your life, with NO RISK And JUST A LITTLE BIT OF EFFORT. You can make more money in the next few weeks and months than you have ever imagined. Follow the program EXACTLY AS INSTRUCTED. Do Not change it in any way. It works exceedingly well as it is now. Remember to e-mail a copy of this exciting REPORT after you have put your name and address in REPORT #1 and moved others to #2 ..........#5 as instructed above. One of the people you send this to may send out 100,000 or more e-mails and your name will be on everyone of them. Remember though, the more you send out the more potential customers you will reach. So my friend, I have given you the ideas, information, materials and opportunity to become financially independent. IT IS UP TO YOU NOW! **************** MORE TESTIMONIALS ***************** --------------------------------------------------- -------- ''Not being the gambling type, it took me several weeks to make up my mind to participate in this plan. But conservative that I am, I decided that the initial investment was so little that there was just no way that I wouldn't get enough orders to at least get my money back''. ''I was surprised when I found my medium size post office box crammed with orders. I made $319,210.00 in the first 12 weeks. The nice thing about this deal is that it does not matter where people live. There simply isn't a better investment with a faster return and so big''. Dan Sondstrom, Alberta, Canada --------------------------------------------------- -------- ''I had received this program before. I deleted it, but later I wondered if I should have given it a try. Of course, I had no idea who to contact to get another copy, so I had to wait until I was e-mailed again by someone else.........11 months passed then it luckily came again...... I did not delete this one! I made more than $490,000 on my first try and all the money came within 22 weeks''. Susan De Suza, New York, N.Y. --------------------------------------------------- -------- ''It really is a great opportunity to make relatively easy money with little cost to you. I followed the simple instructions carefully and within 10 days the money started to come in. My first month I made $ 20, 560.00 and by the end of third month my total cash count was $ 362,840.00. Life is beautiful, Thanx to internet''. Fred Dellaca, Westport, New Zealand --------------------------------------------------- -------- ORDER YOUR REPORTS TODAY AND GET STARTED ON YOUR ROAD TO FINANCIAL FREEDOM! ================================================== If you have any questions of the legality of this program, contact the Office of Associate Director for Marketing Practices, Federal Trade Commission, Bureau of Consumer Protection, Washington, D.C. /////////////////////////////////////////////////// //////// ONE TIME MAILING, NO NEED TO REMOVE /////////////////////////////////////////////////// //////// This message is sent in compliance of the proposed bill SECTION 301. per Section 301, Paragraph (a)(2)(C) of S. 1618. Further transmission to you by the sender of this e-mail may be stopped at no cost to you by sending a reply to youcansucceed at hotmail.com Steven W. Pratt Ph: 610-842-6318 (Please call if you have questions or concerns) 233 Brandywine Rd Collegeville, PA 19426 This message is not intended for residents in the State of Washington, screening of addresses has been done to the best of our technical ability. From ray at unipay.nl Thu Aug 8 12:55:40 2002 From: ray at unipay.nl (R. Hirschfeld) Date: Thu, 8 Aug 2002 21:55:40 +0200 Subject: Challenge to TCPA/Palladium detractors In-Reply-To: (message from AARG!Anonymous on Wed, 7 Aug 2002 12:50:29 -0700) References: Message-ID: <200208081955.VAA02106@home.unipay.nl> > Date: Wed, 7 Aug 2002 12:50:29 -0700 > From: AARG!Anonymous > I'd like the Palladium/TCPA critics to offer an alternative proposal > for achieving the following technical goal: > > Allow computers separated on the internet to cooperate and share data > and computations such that no one can get access to the data outside > the limitations and rules imposed by the applications. The model and the goal are a bit different, but how about secure multi-party computation, as introduced by Chaum, Crepeau, and Damgard in 1988 and subsequently refined by others? --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From levitte at openssl.org Thu Aug 8 15:35:40 2002 From: levitte at openssl.org (Richard Levitte - VMS Whacker) Date: Fri, 09 Aug 2002 00:35:40 +0200 (CEST) Subject: [ANNOUNCE] OpenSSL 0.9.6f released Message-ID: <20020809.003540.10906124.levitte@openssl.org> OpenSSL version 0.9.6f released =============================== OpenSSL - The Open Source toolkit for SSL/TLS http://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 0.9.6f of our open source toolkit for SSL/TLS. This new OpenSSL version is a security and bugfix release and incorporates several changes to the toolkit (for a complete list see http://www.openssl.org/source/exp/CHANGES). The most significant changes are: o Various important bugfixes. We consider OpenSSL 0.9.6f to be the best version of OpenSSL available and we strongly recommend that users of older versions upgrade as soon as possible. OpenSSL 0.9.6f is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under http://www.openssl.org/source/mirror.html): o http://www.openssl.org/source/ o ftp://ftp.openssl.org/source/ [1] OpenSSL comes in the form of two distributions this time. The reasons for this is that we want to deploy the external crypto device support but don't want to have it part of the "normal" distribution just yet. The distribution containing the external crypto device support is popularly called "engine", and is considered experimental. It's been fairly well tested on Unix and flavors thereof. If run on a system with no external crypto device, it will work just like the "normal" distribution. The distribution file names are: o openssl-0.9.6f.tar.gz [normal] MD5 checksum: 160ac38bd2784e633ed291d03f0087d4 o openssl-engine-0.9.6f.tar.gz [engine] MD5 checksum: 26f4b7189fb3ef9c701e961ffe101a95 The checksums were calculated using the following commands: openssl md5 < openssl-0.9.6f.tar.gz openssl md5 < openssl-engine-0.9.6f.tar.gz Yours, The OpenSSL Project Team... Mark J. Cox Ben Laurie Andy Polyakoff Ralf S. Engelschall Richard Levitte Geoff Thorpe Dr. Stephen Henson Bodo Möller Lutz Jänicke Ulf Möller -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From bill.stewart at POBOX.COM Fri Aug 9 00:36:34 2002 From: bill.stewart at POBOX.COM (Bill Stewart) Date: Fri, 09 Aug 2002 00:36:34 -0700 Subject: SF Bay area to begin massive tracking of FasTrak commuters [ or if it is available , we will use or abuse it djf] Message-ID: <5.1.1.6.2.20020809002812.02a86800@idiom.com> The Fastrak system used for toll collections in San Francisco and other areas has found another use - monitoring traffic flow on freeways by tracking suckers\\\\\\\customers' cars when they're *not* in tollbooths. The system managers purport that they'll protect privacy by destroying any individually identifiable data after a day, and also keeping personal identification information separate from encrypted transponder IDs, but fundamentally, if they information's there, it's accessible and usable. -----Original Message----- From: Dave Farber [mailto:dave at farber.net] Sent: Thursday, August 08, 2002 5:33 PM To: ip Subject: IP: SF Bay area to begin massive tracking of FasTrak commuters [ or if it is available , we will use or abuse it djf] http://www.newsday.com/news/nationworld/wire/sns-ap-tracking-drivers0808aug08.story?coll=sns%2Dap%2Dnationworld%2Dheadlines http://www.newsday.com/news/nationworld/wire/sns-ap-tracking-drivers0808aug08.story Traffic System Causes Privacy Outcry By KAREN GAUDETTE Associated Press Writer August 8, 2002, 6:36 PM EDT OAKLAND, Calif. -- In about a month, traffic sensors being installed along San Francisco Bay area highways will be able to track a quarter million drivers along their commutes. Proponents say the $37 million enhancement to the region's electronic toll system will be a boon to commuters, providing motorists real-time information about some of the nation's worst road congestion via cell phone, radio or Internet. Traffic planners will be able to gather crucial data on problem areas. But despite government assurances, the new program is also raising fears that drivers' privacy will be invaded. Similar to systems in Houston and the New York region, the Bay area's FasTrak program already eases waits at toll plazas by enabling motorists to pay with electronic devices velcroed to the windshields of vehicles. Now, radio-based sensors mounted on highway signs every few miles will augment the devices' usefulness. To the dismay of some FasTrak users, monitoring is not optional. The only way to avoid triggering the sensors throughout nine Bay Area counties is to stash the transponder in its accompanying Mylar bag. Project leaders at the Metropolitan Transportation Commission say they're not interested in the movements of individual drivers, and have gone to great lengths to protect privacy, including encrypting the serial number of each transponder as its location is transmitted. Authorities promise to keep this data separate from the identities of FasTrak users and other information needed to make automatic monthly deductions from their bank or credit card accounts. "We're not tracking or trying to follow any individual car, just the overall traffic flow," TravInfo project manager Michael Berman said. But some drivers say having a more detailed traffic report isn't worth the sense that someone's watching. "I personally am a little creeped out by it," said interior designer Heidi Hirvonen-White, who crosses the Golden Gate Bridge commuting between Tiburon and San Francisco. "In today's society it seems like any sort of code or whatnot can be broken." Those in the automotive telematics industry say the Bay Area's "TravInfo" project is only the latest example of the growing phenomenon of remote monitoring. Many rental fleets and trucking companies already use satellite positioning systems to track cars and cargo. Companies promote similar products for keeping tabs on kids, Alzheimer's patients or cheating spouses. Washington is also promoting locator technology. By October, the Federal Communications Commission wants cell phones equipped with locator technology to help emergency responders find callers. That requirement will also enable authorities to track users, even calculating road speeds, said Ray Grefe, vice president of business development for telematics software company Televoke. "I think there are going to be some nasty court battles that come out of all of this stuff," Grefe said. Transponder data has already been used in court. In 1997, E-ZPass records helped show what kidnappers did to New Jersey restaurant millionaire Nelson Gross, whose BMW crossed the George Washington Bridge into Manhattan, where his beaten corpse was found. Another case involved a Connecticut rental car company that charged customers $150 each time a GPS receiver showed they were speeding. The company has since stopped the practice. Berman emphasized that the Bay Area system won't be used to track kidnappers or car thieves who happen to have FasTrak in their cars, let alone adulterers. The MTC -- along with its partners, the California Highway Patrol and the state transportation department -- has received no requests from law enforcement to tweak the system so drivers could be pursued, Berman said, adding, "I think if they were to request it, we would say no. That's not our job." But privacy advocates say that once the sensors are in place, there's nothing to prevent such a change. New laws imposed after Sept. 11 make it much easier for police to obtain such information. "Yes, they're building in limitations on the data use, but there's nothing to prevent them from changing the policies in the future," said Beth Givens, director of the San Diego-based Privacy Rights Clearinghouse. Each of the California system's sensors has two antennas. One continually sends out a radio pulse that "wakes up" when it hits a passing FasTrak transponder. The other antenna notes the transponder's serial number, and transmits it, using encryption, via cellular modem to the MTC's Travel Information Center in Oakland. Transponders beep as cars pass through toll plazas, but remain silent when they pass the sensors. All record of serials numbers stored in electronic files will be destroyed daily, leaving only general averages and patterns for later study, Berman said. In Texas, 1.5 million commuters use a similar traffic information service, said Artee Jones, spokesman for Houston TranStar, which incorporates similar privacy measures. While some FasTrak users remain troubled, few said they'd give up the shorter toll booth lines or discounts to avoid participating. Michael Pieri of Richmond said he has nothing to hide, but he'll still stash the transponder away between tolls. "That's fine if you volunteer for that," he said. "But involuntarily, I don't think it's a good thing at all." * __ On the Net: Metropolitan Transportation Commission: http://www.mtc.ca.gov TravInfo program: http://www.travinfo.org http://www.televoke.com Copyright ) 2002, The Associated Press For archives see: http://www.interesting-people.org/archives/interesting-people/ From ray at unipay.nl Thu Aug 8 15:46:24 2002 From: ray at unipay.nl (R. Hirschfeld) Date: Fri, 9 Aug 2002 00:46:24 +0200 Subject: Challenge to TCPA/Palladium detractors In-Reply-To: <200208081955.VAA02106@home.unipay.nl> (ray@unipay.nl) References: <200208081955.VAA02106@home.unipay.nl> Message-ID: <200208082246.AAA02417@home.unipay.nl> > Date: Thu, 8 Aug 2002 21:55:40 +0200 > From: "R. Hirschfeld" > > > Date: Wed, 7 Aug 2002 12:50:29 -0700 > > From: AARG!Anonymous > > > I'd like the Palladium/TCPA critics to offer an alternative proposal > > for achieving the following technical goal: > > > > Allow computers separated on the internet to cooperate and share data > > and computations such that no one can get access to the data outside > > the limitations and rules imposed by the applications. > > The model and the goal are a bit different, but how about secure > multi-party computation, as introduced by Chaum, Crepeau, and Damgard > in 1988 and subsequently refined by others? Sorry, I see from an earlier message of yours that you are looking for a simple non-crypto solution, so I guess this doesn't fit the bill. The examples you gave in your earlier message all seem to be equivalent to having the participants send the data to a trusted third party who performs the computation, except that the trusted third party is transplanted to one or more of the participants computers, which are protected against their owners. I guess it boils down to whether or not the level of trust is sufficient. This seems iffy when one of the participants is also the trust provider. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From shamrock at cypherpunks.to Fri Aug 9 00:48:21 2002 From: shamrock at cypherpunks.to (Lucky Green) Date: Fri, 9 Aug 2002 00:48:21 -0700 Subject: Challenge to TCPA/Palladium detractors In-Reply-To: <8c708993eecdbee279fbe47fdeb4a0d0@aarg.net> Message-ID: <004901c23f79$23192b80$6801a8c0@xpserver> Anonymous wrote: > Matt Crawford replied: > > Unless the application author can predict the exact output of the > > compilers, he can't issue a signature on the object code. The > > compilers then have to be inside the trusted base, checking a > > signature on the source code and reflecting it somehow through a > > signature they create for the object code. > > It's likely that only a limited number of compiler > configurations would be in common use, and signatures on the > executables produced by each of those could be provided. > Then all the app writer has to do is to tell people, get > compiler version so-and-so and compile with that, and your > object will match the hash my app looks for. DEI The above view may be overly optimistic. IIRC, nobody outside PGP was ever able to compile a PGP binary from source that matched the hash of the binaries built by PGP. --Lucky Green --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From shamrock at cypherpunks.to Fri Aug 9 00:48:44 2002 From: shamrock at cypherpunks.to (Lucky Green) Date: Fri, 9 Aug 2002 00:48:44 -0700 Subject: Utilizing Palladium against software piracy Message-ID: <005101c23f79$2fdb9e70$6801a8c0@xpserver> I would like to again thank the Palladium team, in particular Peter Biddle, for participating in yesterday's panel at the USENIX Security conference on Palladium and TCPA. Unfortunately I do not have the time at the moment to write up the many valuable and informative points made during the panel discussion. I will, however, highlight one such issue: As Peter pointed out, while the Palladium effort was started to meet the content protection requirements of digital video content providers, he also pointed out that Microsoft and its Palladium group have so far been unable to determine a method in which Palladium could be utilized to assist in the efforts against application software piracy. As Peter mentioned, the Palladium team on several occasions had to tell the Microsoft's anti-piracy group that Palladium is unsuitable to assist in software (as distinct from content) licensing and anti-piracy efforts. Since Microsoft is not aware of a method to utilize the Palladium environment in the enforcement of software licenses, Peter argued, Microsoft does not intend to and will not utilize Palladium to assist in the enforcement of software licensing. I, on the other hand, am able to think of several methods in which Palladium or operating systems built on top of TCPA can be used to assist in the enforcement of software licenses and the fight against software piracy. I therefore, over the course of the night, wrote - and my patent agent filed with the USPTO earlier today - an application for an US Patent covering numerous methods by which software applications can be protected against software piracy on a platform offering the features that are slated to be provided by Palladium. --Lucky Green From anonymous at remailer.havenco.com Thu Aug 8 20:52:56 2002 From: anonymous at remailer.havenco.com (Anonymous User) Date: Fri, 9 Aug 2002 03:52:56 +0000 (UTC) Subject: Signing as one member of a set of keys Message-ID: This program can be used by anonymous contributors to release partial information about their identity - they can show that they are someone from a list of PGP key holders, without revealing which member of the list they are. Maybe it can help in the recent controvery over the identity of anonymous posters. It's a fairly low-level program that should be wrapped in a nicer UI. I'll send a couple of perl scripts later that make it easier to use. === /* Implementation of ring signatures from * http://theory.lcs.mit.edu/~rivest/RivestShamirTauman-HowToLeakASecret.pdf * by Rivest, Shamir and Tauman * * This creates and verifies a signature such that it was produced from * one of a fixed set of RSA keys. * * It requires the openssl library to build, which is available from * www.openssl.org. * * This program takes a PGP public key ring file which holds a set of * old-style RSA public keys. It creates and verifies signatures which * are such that they were issued by one of the keys in that file, but * there is no way to tell which one did it. In this way the signer can * leak partial information about his identity - that he is one member * of a selected set of signers. * * To sign, the signer must also give a PGP secret key file which holds * one key (actually the program ignores any keys past the first). * That key should be the secret part of one of the keys in the public * key file. Also, it should be set to have no passphrase - it is too * complicated for a simple program like this to try to untangle PGP * passphrases. So set your key to have no passphrase, then run this * program, then set it back. * * The program outputs the signature in the form of a list of big numbers, * base64 encoded. There will be as many numbers as there were keys in * the public key file. So signatures are quite large in this scheme, * proportional to the number of keys in the group that the signature * comes from. They are also proportional to the largest key in the * group, so all else being equal try not to include really big keys if * you care about size. * * The signature is not appended to the text being signed, it is just * output separately. The signer can combine them manually with some kind * of cut marks so that the recipient can separate out the signature from * the file being signed. Some perl scripts that do this are supposed * to be distributed with the program. (That is what is used to verify * the signature in this file itself.) * * The recipient must use the same PGP public key file that the signer * used. So that may have to be sent along as well. He runs the program * with the PGP file and the file to be verified, and sends the signature * data into stdin (using the "<" character). The program will print * whether the signature is good or not. * * This program was written in just a couple of evenings so it is * a little rough. This is version 0.9 or so - at least it works. * It has only been tested on my Linux system. * * The program is released into the public domain. See the end for * authorship information. */ #include #include #include "openssl/bn.h" #include "openssl/rsa.h" #include "openssl/sha.h" #include "openssl/evp.h" /* Cipher block size; we use Blowfish */ #define CIPHERBLOCK 8 typedef unsigned char uchar; enum { ERR_OK = 0, ERR_BADPKT=-100, ERR_EOF, ERR_SECNOTFOUND, ERR_BADSIG, }; /************************** PGP FILE PARSING ***************************/ /* Read the N and E values from a PGP public key packet */ int rdpgppub( BIGNUM *n, BIGNUM *e, unsigned *bytesused, uchar *buf, unsigned len ) { int nbits, nlen, ebits, elen; unsigned o=2; if (len < 10) return ERR_BADPKT; if (buf[0] == 4) /* Check version 4, 3, or 2 */ o = 0; else if (buf[0] != 2 && buf[0] != 3) /* V2&3 have 2 extra bytes */ return ERR_BADPKT; if (buf[5+o] != 1) /* Check alg - 1 is RSA */ return ERR_BADPKT; nbits = (buf[6+o] << 8) | buf[7+o]; /* Read modulus */ nlen = (nbits + 7)/8; if (len < 10+o+nlen) return ERR_BADPKT; BN_bin2bn(buf+o+8, nlen, n); ebits = (buf[8+o+nlen] << 8) | buf[9+o+nlen]; /* Read exponent */ elen = (ebits + 7)/8; if (len < 10+o+nlen+elen) return ERR_BADPKT; BN_bin2bn(buf+10+o+nlen, elen, e); if (bytesused) *bytesused = 10+o+nlen+elen; return ERR_OK; } /* Read the N, E, D values from a PGP secret key packet with no passphrase */ int rdpgpsec( BIGNUM *n, BIGNUM *e, BIGNUM *d, uchar *buf, unsigned len ) { int err; int nbits, nlen, ebits, elen, dbits, dlen; unsigned o; if ((err = rdpgppub(n, e, &o, buf, len)) < 0) return err; if (len < o+3) return ERR_BADPKT; if (buf[o] != 0) /* Check that packet is unencrypted */ return ERR_BADPKT; dbits = (buf[o+1] << 8) | buf[o+2]; /* Read private exponent */ dlen = (dbits + 7)/8; if (len < o+3+dlen) return ERR_BADPKT; BN_bin2bn(buf+o+3, dlen, d); return ERR_OK; } /* Read the next PGP packet into malloc'd memory */ int getpgppkt( uchar **pbuf, unsigned *plen, int *type, FILE *f ) { int c, c1; uchar *buf; unsigned len; int llen; uchar lbuf[4]; c = fgetc(f); if (c == EOF) return ERR_EOF; if ((c & 0xc0) == 0x80) { /* Old PGP packet */ *type = (c >> 2) & 0xf; llen = c & 0x3; if (llen++==3) return ERR_BADPKT; rdllen: if (llen==3) llen=4; memset (lbuf, 0, 4); if (fread(lbuf+4-llen, 1, llen, f) != llen) return ERR_BADPKT; len = (lbuf[0]<<24) | (lbuf[1]<<16) | (lbuf[2]<<8) | lbuf[3]; } else if ((c & 0xc0) == 0xc0) { /* New PGP packet */ *type = c & 0x3f; c = fgetc(f); if (c == EOF) return ERR_BADPKT; if (c == 0xff) { llen = 4; goto rdllen; } if (c >= 0xe0) return ERR_BADPKT; if (c >= 0xc0) { /* Two byte length */ c1 = fgetc(f); if (c1 == EOF) return ERR_BADPKT; len = (c<<8) + c1 - 0xc000 + 0xc0; } else { /* One byte length */ len = c; } } else { /* Non PGP packet */ return ERR_BADPKT; } buf = malloc(len); if (buf==NULL) return ERR_BADPKT; if (fread(buf, 1, len, f) != len) return ERR_BADPKT; *pbuf = buf; *plen = len; return ERR_OK; } /* Read a PGP key ring and create arrays of all the n, e values */ int rdpgppubring(BIGNUM ***n_arr_ptr, BIGNUM ***e_arr_ptr, int *nkeys_ptr, FILE *f) { int err = ERR_OK; uchar *buf; unsigned len; int type; int nkeys = 0; BIGNUM **n_arr = NULL; BIGNUM **e_arr = NULL; BIGNUM *n, *e; n_arr = malloc(sizeof(BIGNUM *)); e_arr = malloc(sizeof(BIGNUM *)); while (err == ERR_OK) { err = getpgppkt (&buf, &len, &type, f); if (err != ERR_OK) break; if (type == 6) /* public key packet */ { n = BN_new(); e = BN_new(); err = rdpgppub(n, e, NULL, buf, len); if (err != ERR_OK) break; ++nkeys; n_arr = realloc(n_arr, sizeof(BIGNUM *) * nkeys); e_arr = realloc(e_arr, sizeof(BIGNUM *) * nkeys); n_arr[nkeys-1] = n; e_arr[nkeys-1] = e; } free (buf); } if (err != ERR_EOF) return err; err = ERR_OK; *n_arr_ptr = n_arr; *e_arr_ptr = e_arr; *nkeys_ptr = nkeys; return err; } /* Read a PGP secret key file and find the corresponding value in the * array of public key values. Return the d value and the index in the * public key array. */ int rdpgpsecring(BIGNUM *d, int *secindex, BIGNUM **n_arr, BIGNUM **e_arr, int nkeys, FILE *f) { int err = ERR_OK; BIGNUM *n, *e; uchar *buf; unsigned len; int i; int type; err = getpgppkt (&buf, &len, &type, f); if (err != ERR_OK) return err; if (type != 5) /* Secret key packet */ return ERR_BADPKT; n = BN_new(); e = BN_new(); err = rdpgpsec(n, e, d, buf, len); if (err != ERR_OK) return err; for (i=0; i 0) { t = n[i]; n[i] = n[j]; n[j] = t; t = e[i]; e[i] = e[j]; e[j] = t; } } } return ERR_OK; } /* Hash the file. Should have opened it in ASCII mode so that we have * standard Unix line endings (newlines only). */ int hashfile( uchar md[5], FILE *f ) { char buf[1024]; SHA_CTX sha; SHA_Init(&sha); for ( ; ; ) { if (fgets (buf, sizeof(buf), f) == NULL) break; SHA_Update(&sha, buf, strlen(buf)); } SHA_Final (md, &sha); return ERR_OK; } /* Do an RSA enc/dec, where the input/output value may be larger * than n. In fact, val should be much larger than n or this may fail * to keep val within the desired range. * To decrypt pass d in place of e. */ int rsaencdec( BIGNUM *rslt, BIGNUM *val, BIGNUM *n, BIGNUM *e, BN_CTX *ctx ) { BIGNUM *rem = BN_new(); BIGNUM *newrem = BN_new(); BN_div (NULL, rem, val, n, ctx); BN_mod_exp (newrem, rem, e, n, ctx); BN_sub (rslt, val, rem); BN_add (rslt, rslt, newrem); BN_free (rem); BN_free (newrem); } /************************** SIG CREATE/VERIFY ***************************/ /* Verify a signature. sigs holds the per-key signature values, * hashval is the hash of the data which was signed, valbytes is the * length of the values we work with, several bytes longer than the longest * modulus, and n_arr and e_arr are the RSA public key values, of whic * there are nkeys of them. (There are also nkeys of sigs.) */ int checksig( BIGNUM **sigs, uchar *hashval, int hashvalbytes, int valbytes, BIGNUM **n_arr, BIGNUM **e_arr, int nkeys, BN_CTX *ctx ) { BIGNUM *val = BN_new(); uchar ivec[CIPHERBLOCK]; BF_KEY bf; uchar *sigbuf; uchar *xorbuf; int vallen; int i, j; /* Key cipher with the hash value */ BF_set_key (&bf, hashvalbytes, hashval); /* Init xorbuf to 0's */ xorbuf = malloc(valbytes); memset (xorbuf, 0, valbytes); sigbuf = malloc(valbytes); for (i=0; i valbytes) { fprintf (stderr, "Bad signature created by signer\n"); exit (3); } /* XOR into buffer */ memset (sigbuf, 0, valbytes); BN_bn2bin (val, sigbuf+valbytes-vallen); for (j=0; j valbytes with random val */ vallen = BN_num_bytes(val); /* XOR into right xor buf and encrypt */ memset (sigbuf, 0, valbytes); BN_bn2bin (val, sigbuf+valbytes-vallen); for (j=0; jsecindex; i--) { /* For other keys do a fake value */ sigs[i] = BN_new(); BN_rand_range (sigs[i], bigval); rsaencdec (val, sigs[i], n_arr[i], e_arr[i], ctx); /* Infinitisimal chance that vallen > valbytes with random val */ vallen = BN_num_bytes(val); /* XOR into left xor buf and decrypt */ memset (sigbuf, 0, valbytes); BN_bn2bin (val, sigbuf+valbytes-vallen); for (j=0; j References: <200208072113.g77LDaC17060@gungnir.fnal.gov> Message-ID: <3D5378ED.9941.21E6F6@localhost> -- On Wed, 7 Aug 2002, Matt Crawford wrote: > > Unless the application author can predict the exact output of > > the compilers, he can't issue a signature on the object code. > > The On 9 Aug 2002 at 10:48, Eugen Leitl wrote: > Same version of compiler on same source using same build > produces identical binaries. This has not been my experience. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG vP+cB8hTnaqPfAtiGlYdo9QuJCpq884ER6Mo+F9m 2SkruXvZexqOoTAk6QuWuruF5x4fT0Rq4v/YSxLAt From cyphrpnk at shannon.permutation.net Fri Aug 9 09:01:10 2002 From: cyphrpnk at shannon.permutation.net (cyphrpnk) Date: Fri, 9 Aug 2002 09:01:10 -0700 Subject: AARG and eugene are net.loons-why signatures of binaries always change. Message-ID: <20020809090110.A24161@shannon.permutation.net> Hi all, Its obvious that some of us here are developers and still others have never typed make or gcc in their lives. -v and -V options given to various forms of ld caused the embeddment of version information in the binary(Sunpro does this also, AND early versions of MSC allowed embeddment of version information also.) The fact that most environments dont link -Bstatic and instead link -Bdynamic means that every time you attempt to produce a binary from 2 different systems that the dynamic link information will be different checkout link.h link_elf.h link_aout.h in /usr/include in addition MOST modern developement environments include a date field when compiled and linked in the binary sheesh a cypherpunk BTW. AARG and eugene are idiots nyah nyah nyah!! From simpson at samsimpson.com Fri Aug 9 09:16:17 2002 From: simpson at samsimpson.com (Sam Simpson) Date: Fri, 9 Aug 2002 09:16:17 -0700 (PDT) Subject: Challenge to TCPA/Palladium detractors In-Reply-To: <004901c23f79$23192b80$6801a8c0@xpserver> Message-ID: I'm not surprised that most people couldn't produce a matching PGP executbales - most compilers (irrespective of compiler optimisation options etc) include a timestamp in the executable. Regards, Sam Simpson sam at samsimpson.com http://www.samsimpson.com/ Mob: +44 (0) 7866 726060 Home Office: +44 (0) 1438 229390 Fax: +44 (0) 1438 726069 On Fri, 9 Aug 2002, Lucky Green wrote: > Anonymous wrote: > > Matt Crawford replied: > > > Unless the application author can predict the exact output of the > > > compilers, he can't issue a signature on the object code. The > > > compilers then have to be inside the trusted base, checking a > > > signature on the source code and reflecting it somehow through a > > > signature they create for the object code. > > > > It's likely that only a limited number of compiler > > configurations would be in common use, and signatures on the > > executables produced by each of those could be provided. > > Then all the app writer has to do is to tell people, get > > compiler version so-and-so and compile with that, and your > > object will match the hash my app looks for. DEI > > The above view may be overly optimistic. IIRC, nobody outside PGP was > ever able to compile a PGP binary from source that matched the hash of > the binaries built by PGP. > > --Lucky Green > > > --------------------------------------------------------------------- > The Cryptography Mailing List > Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From remailer at aarg.net Fri Aug 9 10:05:15 2002 From: remailer at aarg.net (AARG!Anonymous) Date: Fri, 9 Aug 2002 10:05:15 -0700 Subject: Thanks, Lucky, for helping to kill gnutella Message-ID: <8c25bf764b14de9e2d3d9cd24a6d49fb@aarg.net> An article on Salon this morning (also being discussed on slashdot), http://www.salon.com/tech/feature/2002/08/08/gnutella_developers/print.html, discusses how the file-trading network Gnutella is being threatened by misbehaving clients. In response, the developers are looking at limiting the network to only authorized clients: > On Gnutella discussion sites, programmers are discussing a number of > technical proposals that would make access to the network contingent > on good behavior: If you write code that hurts Gnutella, in other > words, you don't get to play. One idea would allow only "clients that > you can authenticate" to speak on the network, Fisk says. This would > include the five-or-so most popular Gnutella applications, including > "Limewire, BearShare, Toadnode, Xolox, Gtk-Gnutella, and Gnucleus." If > new clients want to join the group, they would need to abide by a certain > communication specification. They intend to do this using digital signatures, and there is precedent for this in past situations where there have been problems: > Alan Cox, a veteran Linux developer, says that he's seen this sort of > debate before, and he's not against a system that keeps out malicious > users using technology. "Years and years ago this came up with a game > called Xtrek," Cox says. People were building clients with unfair > capabilities to play the space game -- and the solution, says Cox, > was to introduce digital signatures. "Unless a client has been signed, > it can't play. You could build any client you wanted, but what you can't > do is build an Xtrek client that let you play better." Not discussed in the article is the technical question of how this can possibly work. If you issue a digital certificate on some Gnutella client, what stops a different client, an unauthorized client, from pretending to be the legitimate one? This is especially acute if the authorized client is open source, as then anyone can see the cert, see exactly what the client does with it, and merely copy that behavior. If only there were a technology in which clients could verify and yes, even trust, each other remotely. Some way in which a digital certificate on a program could actually be verified, perhaps by some kind of remote, trusted hardware device. This way you could know that a remote system was actually running a well-behaved client before admitting it to the net. This would protect Gnutella from not only the kind of opportunistic misbehavior seen today, but the future floods, attacks and DOSing which will be launched in earnest once the content companies get serious about taking this network down. If only... Luckily the cypherpunks are doing all they can to make sure that no such technology ever exists. They will protect us from being able to extend trust across the network. They will make sure that any open network like Gnutella must forever face the challenge of rogue clients. They will make sure that open source systems are especially vulnerable to rogues, helping to drive these projects into closed source form. Be sure and send a note to the Gnutella people reminding them of all you're doing for them, okay, Lucky? --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From ericm at lne.com Fri Aug 9 10:39:13 2002 From: ericm at lne.com (Eric Murray) Date: Fri, 9 Aug 2002 10:39:13 -0700 Subject: Thanks, Lucky, for helping to kill gnutella In-Reply-To: <8c25bf764b14de9e2d3d9cd24a6d49fb@aarg.net>; from remailer@aarg.net on Fri, Aug 09, 2002 at 10:05:15AM -0700 References: <8c25bf764b14de9e2d3d9cd24a6d49fb@aarg.net> Message-ID: <20020809103913.B5594@slack.lne.com> On Fri, Aug 09, 2002 at 10:05:15AM -0700, AARG! Anonymous wrote: > > On Gnutella discussion sites, programmers are discussing a number of > > technical proposals that would make access to the network contingent > > on good behavior: If you write code that hurts Gnutella, in other > > words, you don't get to play. One idea would allow only "clients that > > you can authenticate" to speak on the network, Fisk says. This would > > include the five-or-so most popular Gnutella applications, including > > "Limewire, BearShare, Toadnode, Xolox, Gtk-Gnutella, and Gnucleus." If > > new clients want to join the group, they would need to abide by a certain > > communication specification. > > They intend to do this using digital signatures, and there is precedent > for this in past situations where there have been problems: Depending on the clients to "do the right thing" is fundamentally stupid. [..] > Be sure and send a note to the Gnutella people reminding them of all > you're doing for them, okay, Lucky? This sort of attack doesn't do your position any good. Eric From Palmcitywhol at yahoo.com Fri Aug 9 09:33:17 2002 From: Palmcitywhol at yahoo.com (Palmcitywhol at yahoo.com) Date: Fri, 9 Aug 2002 11:33:17 -0500 Subject: liquidation Message-ID: <200208091647.g79Gl0pU020661@ak47.algebra.com> A non-text attachment was scrubbed... Name: not available Type: text/html Size: 303 bytes Desc: not available URL: From bram at gawth.com Fri Aug 9 11:59:05 2002 From: bram at gawth.com (Bram Cohen) Date: Fri, 9 Aug 2002 11:59:05 -0700 (PDT) Subject: Thanks, Lucky, for helping to kill gnutella In-Reply-To: <8c25bf764b14de9e2d3d9cd24a6d49fb@aarg.net> Message-ID: AARG!Anonymous wrote: > If only there were a technology in which clients could verify and yes, > even trust, each other remotely. Some way in which a digital certificate > on a program could actually be verified, perhaps by some kind of remote, > trusted hardware device. This way you could know that a remote system was > actually running a well-behaved client before admitting it to the net. > This would protect Gnutella from not only the kind of opportunistic > misbehavior seen today, but the future floods, attacks and DOSing which > will be launched in earnest once the content companies get serious about > taking this network down. Before claiming that the TCPA, which is from a deployment standpoint vaporware, could help with gnutella's scaling problems, you should probably learn something about what gnutella's problems are first. The truth is that gnutella's problems are mostly that it's a screamer protocol, and limiting which clients could connect would do nothing to fix that. Limiting which clients could connect to the gnutella network would, however, do a decent job of forcing to pay people for one of the commercial clients. In this way it's very typical of how TCPA works - a non-solution to a problem, but one which could potentially make money, and has the support of gullible dupes who know nothing about the technical issues involved. > Be sure and send a note to the Gnutella people reminding them of all > you're doing for them, okay, Lucky? Your personal vendetta against Lucky is very childish. -Bram Cohen "Markets can remain irrational longer than you can remain solvent" -- John Maynard Keynes --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From eugen at leitl.org Fri Aug 9 03:49:02 2002 From: eugen at leitl.org (Eugen Leitl) Date: Fri, 9 Aug 2002 12:49:02 +0200 (CEST) Subject: Challenge to TCPA/Palladium detractors In-Reply-To: <00ae01c23f8b$11247080$c71121c2@sharpuk.co.uk> Message-ID: On Fri, 9 Aug 2002, David Howe wrote: > It doesn't though - that is the point. I am not sure if it is simply > that there are timestamps in the final executable, but Visual C (to give > a common example, as that is what the windows PGP builds compile with) > will not give an identical binary, even if you hit "rebuild all" twice > in close succession and compare the two outputs, nothing having changed. I've just verified this also occurs on OpenSSL under RH 7.3 (gcc --version 2.96). I haven't done a binary diff, but I'm also suspecting a time stamp. Can anyone shed some light on this? From eresrch at eskimo.com Fri Aug 9 13:03:57 2002 From: eresrch at eskimo.com (Mike Rosing) Date: Fri, 9 Aug 2002 13:03:57 -0700 (PDT) Subject: Thanks, Lucky, for helping to kill gnutella In-Reply-To: Message-ID: On Fri, 9 Aug 2002, Jay Sulzberger wrote: > There are many solutions at the level of "technical protocols" that solve > the projection of these problems down to the low dimensional subspace of > "technical problems". Some of these "technical protocols" will be part of > a full system which accomplishes the desired ends. Please contact me > off-list if you willing to spend some money for an implementation. Hey! Tell the Gnutella folks I'll be happy to bid on that too! I'm pretty sure I can get them a solid solution, especially since it's just a "technical" problem. Patience, persistence, truth, Dr. mike From mv at cdc.gov Fri Aug 9 13:38:32 2002 From: mv at cdc.gov (Major Variola (ret)) Date: Fri, 09 Aug 2002 13:38:32 -0700 Subject: Tommy loses his toys (laptop stolen from MacDill SCIF) Message-ID: <3D542848.32EFCB28@cdc.gov> Guess who wasn't using encrypted disks? MacDILL AIR FORCE BASE - Two laptop computers missing from Gen. Tommy Franks' headquarters were kept in an ultrasensitive locked and alarmed security room intended to safeguard some of the military's deepest secrets in the U.S. war on terrorism, officials said Wednesday. At least one of the laptops contained highly classified information, they said. The room is known in military shorthand as a SCIF, or Secure Compartmented Information Facility. The government uses them at installations worldwide and regulates their security features so closely that voluminous rules have been written on how they are to be built and protected. It sits deep inside the building that houses U.S. Central Command headquarters, which is running the war in Afghanistan and which is tightly guarded by troops armed with M-16s. The building stands inside the MacDill Air Force Base perimeter, which is well guarded, too. http://www.tampatrib.com/MGA4YPZ4M4D.html ....... Maybe Wen Ho Lee sold them to a pawn shop.. From levitte at openssl.org Fri Aug 9 05:15:12 2002 From: levitte at openssl.org (Richard Levitte - VMS Whacker) Date: Fri, 09 Aug 2002 14:15:12 +0200 (CEST) Subject: [ANNOUNCE] OpenSSL 0.9.6g released Message-ID: <20020809.141512.76578258.levitte@openssl.org> OpenSSL version 0.9.6g released =============================== OpenSSL - The Open Source toolkit for SSL/TLS http://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 0.9.6g of our open source toolkit for SSL/TLS. This new OpenSSL version is a bugfix release. The most significant changes are: o Important building fixes on Unix. o Fix crash in CSwift engine. [engine] We consider OpenSSL 0.9.6g to be the best version of OpenSSL available and we strongly recommend that users of older versions upgrade as soon as possible. OpenSSL 0.9.6g is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under http://www.openssl.org/source/mirror.html): o http://www.openssl.org/source/ o ftp://ftp.openssl.org/source/ [1] OpenSSL comes in the form of two distributions this time. The reasons for this is that we want to deploy the external crypto device support but don't want to have it part of the "normal" distribution just yet. The distribution containing the external crypto device support is popularly called "engine", and is considered experimental. It's been fairly well tested on Unix and flavors thereof. If run on a system with no external crypto device, it will work just like the "normal" distribution. The distribution file names are: o openssl-0.9.6g.tar.gz [normal] MD5 checksum: 515ed54165a55df83f4eb4e4e9078d3f o openssl-engine-0.9.6g.tar.gz [engine] MD5 checksum: 87cb788c99e40b6e67268ea35d1d250c The checksums were calculated using the following commands: openssl md5 < openssl-0.9.6g.tar.gz openssl md5 < openssl-engine-0.9.6g.tar.gz Yours, The OpenSSL Project Team... Mark J. Cox Ben Laurie Andy Polyakoff Ralf S. Engelschall Richard Levitte Geoff Thorpe Dr. Stephen Henson Bodo Möller Lutz Jänicke Ulf Möller --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From bram at gawth.com Fri Aug 9 14:23:34 2002 From: bram at gawth.com (Bram Cohen) Date: Fri, 9 Aug 2002 14:23:34 -0700 (PDT) Subject: Thanks, Lucky, for helping to kill gnutella In-Reply-To: <20020809195532.500AD46D3@notatla.demon.co.uk> Message-ID: Antonomasia wrote: > My copy of "Peer to Peer" (Oram, O'Reilly) is out on loan but I think > Freenet and Mojo use protocols that require new users to be > contributors before they become consumers. (Leaving aside that > Gnutella seems doomed on scalability grounds.) Freenet and Mojo Nation have had serious issues in the wild, but my project, BitTorrent, is currently being used in serious deployment, and its leech resistance algorithms are proving quite robust - http://bitconjurer.org/BitTorrent/ This is a very narrow form of leech resistance, but it may be all that is needed. -Bram Cohen "Markets can remain irrational longer than you can remain solvent" -- John Maynard Keynes --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From jays at panix.com Fri Aug 9 12:16:34 2002 From: jays at panix.com (Jay Sulzberger) Date: Fri, 9 Aug 2002 15:16:34 -0400 (EDT) Subject: Thanks, Lucky, for helping to kill gnutella In-Reply-To: <8c25bf764b14de9e2d3d9cd24a6d49fb@aarg.net> Message-ID: On Fri, 9 Aug 2002, AARG!Anonymous wrote: < ... /> > Not discussed in the article is the technical question of how this can > possibly work. If you issue a digital certificate on some Gnutella > client, what stops a different client, an unauthorized client, from > pretending to be the legitimate one? This is especially acute if the > authorized client is open source, as then anyone can see the cert, > see exactly what the client does with it, and merely copy that behavior. > > If only there were a technology in which clients could verify and yes, > even trust, each other remotely. Some way in which a digital certificate > on a program could actually be verified, perhaps by some kind of remote, > trusted hardware device. This way you could know that a remote system was > actually running a well-behaved client before admitting it to the net. > This would protect Gnutella from not only the kind of opportunistic > misbehavior seen today, but the future floods, attacks and DOSing which > will be launched in earnest once the content companies get serious about > taking this network down. There are many solutions at the level of "technical protocols" that solve the projection of these problems down to the low dimensional subspace of "technical problems". Some of these "technical protocols" will be part of a full system which accomplishes the desired ends. Please contact me off-list if you willing to spend some money for an implementation. Your claim, if true, would also demonstrate that no credit card payments over the Net, no apt-get style updating, no Paypal-like system, no crypto time-stamp system, etc., can exist today. > > If only... Luckily the cypherpunks are doing all they can to make sure > that no such technology ever exists. They will protect us from being able > to extend trust across the network. They will make sure that any open > network like Gnutella must forever face the challenge of rogue clients. > They will make sure that open source systems are especially vulnerable > to rogues, helping to drive these projects into closed source form. > > Be sure and send a note to the Gnutella people reminding them of all > you're doing for them, okay, Lucky? AARG!, this is again unworthy of you. You are capable of attempting to confuse and misdirect at a higher level. You might wish to emphasize that the real difficulties are at the levels where the reasons for the small usage of GNUPG lie. That really the "technical" details of the TCPA/Palladium system hardly matter. What TCPA/Palladium will allow is the provision to the masses of even more powerful brews of fantasy, game playing, advertising, etc.. And that there will be a small number of hobbyists who use the "unprotected ports of TCPA/Palladium" for their own limited experiments/amusements/etc.. The real point of TCPA/Palladium is that a "locus of trust", seemingly guaranteed by the Powers That Be, will be created, and that the existence of this same locus, under the facies of "locus of dealmaking/lawyering", will so reassure the Infotainment Arm of the Englobulators that the Arm will unleash its extraordinary forces to build and sell ever more entrancing Palaces of Dreams. The "unprotected ports" will allow a mostly self-supporting farm team system which will function without much direct oversight and little outlay of money by Englobulator Central or any of the Arms. The limited freedom of the Farm System, with its convenient pull strings, for the cases where something large and not controlled by Those Who Know Best takes off, will be a powerful lure to up and coming future Talent, who, when the time comes, may be Signed, without today's confusing and annoying possibility of continued independence. Indeed, the EULA of every system might have a section which binds users who display Marketable Things to an automatic Arbitration of Contract. oo--JS. From alex18015 at hotmail.com Fri Aug 9 12:30:10 2002 From: alex18015 at hotmail.com (Alex) Date: Fri, 9 Aug 2002 15:30:10 -0400 Subject: Make $50,000 or more in 90 days just sending e-mails Message-ID: Dear Friend, You can earn a lot of money in the next 90 days sending e-mail. Seem impossible? Is there a catch? NO, there is no catch; just send your e-mails and be on your way to financial freedom. Basically, I send out as many of these e-mails as I can, then people send me cash in the mail for information that I just e-mail back to them. Everyday, I make a three minute drive to my P.O. Box knowing that there are at least a few hundred dollars waiting for me. And the best part, IT IS COMPLETELY LEGAL. Just read the next few paragraphs and see what you think. If you like what you read, great! If you don't, read it again because you must have missed something. "AS SEEN ON NATIONAL TELEVISION" "Making over a half million dollars every 6 months from your home for an investment of only $25 US dollars expense ONE TIME. THANKS TO THE COMPUTER AGE AND THE INTERNET, BE A MILLIONAIRE LIKE OTHERS WITHIN A YEAR!!! Before you say, "No Way!" read the following. This is the letter you've been reading about in the news lately. Due to the popularity of this letter on the Internet, a major nightly news program recently devoted an entire show to the investigation of the program described below to see if it really can make people money. The show also investigated whether or not the program was legal. Their findings proved once and for all that there are absolutely no laws prohibiting the participation in this program. This has helped to show people that this is a simple, harmless, and fun way to make some extra money at home. And, besides even if you never got involved in the program, the reports themselves are well worth the money. They can help you start and advertise ANY business on the internet. That is, these reports stand alone and are beneficial to anyone wishing to do business on the internet. The results of this show have been truly remarkable. So many people are participating that those involved are doing much better than ever before. Since everyone makes more as more people try it out, its been very exciting to be a part of it lately. You will understand once you experience it. "HERE IT IS BELOW" *** Print This Now For Future Reference *** The following income opportunity is one you may be interested in taking a look at. It can be started with VERY LITTLE investment ($25) and the income return is TREMENDOUS!!! THIS IS A LEGITIMATE, LEGAL, MONEY MAKING OPPORTUNITY. It does not require you to come into contact with people, do any hard work, and best of all, you never have to leave your house except to get the mail. Simply follow the instructions, and you really can make this happen. This e-mail order marketing program works every time if you put in the effort to make it work. E-mail is the sales tool of the future. Take advantage of this non-commercialized method of advertising NOW! The longer you wait, the more savvy people will be taking your business using e-mail. Get what is rightfully yours. Program yourself for success and dare to think BIG. It sounds corny, but it's true. You'll never make it big if you don't have this belief system in place. MULTI-LEVEL MARKETING (MLM) has finally gained respectability. It is being taught in the Harvard Business School, and both Stanford Research and the Wall Street Journal have stated that between 50% and 65% of all goods and services will be sold through multi-level methods. This is a Multi-Billion Dollar industry and of the 500,000 millionaires in the U.S., 20% (100,000) made their fortune in the last several years in MLM. Moreover, statistics show 45people become millionaires everyday through Multi-Level Marketing. You may have heard this story before, but Donald Trump made an appearance on the David Letterman show. Dave asked him what he would do if he lost everything and had to start over from scratch. Without hesitating Trump said he would find a good network marketing company and get to work. The audience, started to hoot and boo him. He looked out at the audience and dead-panned his response. "That's why I'm sitting up here and you are all sitting out there!" With network marketing you have two sources of income. Direct commissions from sales you make yourself and commissions from sales made by people you introduce to the business. Residual income is the secret of the wealthy. It means investing time and money once, and getting paid again and again and again. In network marketing, it also means getting paid for the work of others. The enclosed information is something I almost let slip through my fingers. Fortunately, sometime later I reread everything and gave some thought and study to it. My name is Jonathan Rourke. Two years ago, the corporation I worked at for the past twelve years down- sized and my position was eliminated. After unproductive job interviews, I decided to open my own business. Over the past year, I incurred many unforeseen financial problems. I owed my family, friends and creditors over $35,000. The economy was taking a toll on my business and I just couldn't seem to make ends meet. I had to refinance and borrow against my home to support my family and struggling business. AT THAT MOMENT something significant happened in my life and I am writing to share that experience in hopes that this will change your life FOREVER FINANCIALLY!!! In mid December, I received this program via e-mail. Six month's prior to receiving this program, I had been sending away for information on various business opportunities. All of the programs I received, in my opinion were not cost effective. They were either too difficult for me to comprehend or the initial investment was too much for me to risk to see if they would work or not. One claimed that I would make a million dollars in one year. It didn't tell me I'd have to write a book to make it! But like I was saying, in December I received this program. I didn't send for it, or ask for it; they just got my name off a mailing list. THANK GOODNESS FOR THAT!!! After reading it several times, to make sure I was reading it correctly, I couldn't believe my eyes. Here was a MONEY MAKING PHENOMENON. I could invest as much as I wanted to start without putting me further into debt. After I got a pencil and paper and figured it out, I would at least get my money back. But like most of you I was still a little skeptical and a little worried about the legal aspects of it all. So I checked it out with the U.S. Post Office (1-800-725-2161 24 hrs) and they confirmed that it is indeed legal! After determining the program was LEGAL and NOT A CHAIN LETTER, I decided "WHY NOT." Initially I sent out 10,000 e-mails. It cost me about $15 for my time on-line. The great thing about e-mail is that I don't need any money for printing to send out the program, and because all of my orders are filled via e-mail, the only expense is my time. I am telling you like it is. I hope it doesn't turn you off, but I promised myself that I would not 'rip-off" anyone, no matter how much money it cost me. Here is the basic version of what you need to do: Your first goal is to receive at least 20 orders for Report #1 within 2 weeks of your first program going out. IF YOU DON'T, SEND OUT MORE PROGRAMS UNTIL YOU DO. Your second goal is to receive at least 150+ orders for Report #2 within 4 weeks. IF NOT, SEND OUT MORE PROGRAMS UNTIL YOU DO. Once you have your 150 orders, relax, you've met your goal. You will make $50,000+ but keep at it! If you don't get 150 right off, keep at it! It may take some time for your down line to build. Keep at it, stay focused, and do not let yourself get distracted. In less than one week, I was starting to receive orders for REPORT #1. I kept at it - kept mailing out the program and by January 13, 1 had received 26 orders for REPORT #1. My first step in making $50,000 in 90 days was done. By January 30, 1 had received 196 orders for REPORT #2; 46 more than I needed. So I sat back and relaxed. By March 1, of my e-mailing of 10,000, I received $58,000 with more coming in every day. I paid off ALL my debts and bought a much needed new car. Please take time to read the attached program, IT WILL CHANGE YOUR LIFE FOREVER!! Remember, it won't work if you don't try it. This program does work, but you must follow it EXACTLY! Especially the rules of not trying to place your name in a different place. It won't work, you'll lose out on a lot of money! In order for this program to work very fast, try to meet your goal of 20+ orders for Report #1, and 150+ orders for Report #2 and you will make $50,000 or more in 90 days. If you don't reach the first two goals with in four weeks, relax, you will still make a ton of money, it may take a few months or so longer. But keep mailing out the programs and stay focused! That's the key. I AM LIVING PROOF THAT IT WORKS!!! If you choose not to participate in this program, I am sorry. It really is a great opportunity with little cost or risk to you. If you choose to participate, follow the program and you will be on your way to financial security. If you are a fellow business owner and are in financial trouble like I was, or you want to start your own business, consider this a sign. I DID! -Sincerely, Jonathan Rourke P.S. Do you have any idea what 11,700 $5 bills ($58,000) look like piled up on a kitchen table? IT'S AWESOME! A PERSONAL NOTE FROM THE ORIGINATOR OF THIS PROGRAM: By the time you have read the enclosed program and reports, you should have concluded that such a program, and one that is legal, could not have been created by an amateur. Let me tell you a little about myself. I had a profitable business for 10 years. Then in 1979 my business began falling off. I was doing the same things that were previously successful for me, but it wasn't working. Finally, I figured it out. It wasn't me; it was the economy. Inflation and recession had replaced the stable economy that had been with us since 1945. I don't have to tell you what happened to the unemployment rate...because many of you know from first hand experience. There were more failures and bankruptcies than ever before. The middle class was vanishing. Those who knew what they were doing invested wisely and moved up. Those who did not including those who never had anything to save or invest were moving down into the ranks of the poor. As the saying goes, 'THE RICH GET RICHER AND THE POOR GET POORER." The traditional Methods of making money will never allow you to "move up" or "get rich". Inflation will see to that. You have just received information that can give you financial freedom for the rest of your life, with "NO RISK"and "JUST A LITTLE BIT OF EFFORT." You can make more money in the next few months than you have ever imagined. Follow the program EXACTLY AS INSTRUCTED. Do not change it in any way. It works exceedingly well as it is now. Remember to e-mail a copy of this exciting report to everyone you can think of. One of the people you send this to may send out 50,000 ... and your name will be on everyone of them! Remember though, the more you send out the more potential customers you will reach. So my friend, I have given you the ideas, information, materials and opportunity to become financially independent. IT IS UP TO YOU NOW! "THINK ABOUT IT." Before you delete this program from your mailbox, as I almost did, take a little time to read it and REALLY THINK ABOUT IT. Get a pencil and figure out what could happen when YOU participate. Figure out the worst possible response and no matter how you calculate it, you will still make a lot of money! You will definitely get back what you invested. Any doubts you have will vanish when your first orders come in. IT WORKS! -Jody Jacobs, Richmond, VA HERE'S HOW THIS AMAZING PROGRAM WILL MAKE YOU THOUSANDS OF DOLLAR$ This method of raising capital REALLY WORKS 100% EVERY TIME. I am sure that you could use up to $50,000 or more in the next 90 days. Before you say "No Way!" please read this program carefully. This is not a chain letter, but a perfectly legal money making opportunity. Basically, this is what you do: As with all multilevel businesses, we- build our business by recruiting new partners and selling our products. Every state in the USA allows you to recruit new multilevel business partners, and we offer a product for EVERY dollar sent. YOUR ORDERS COME BY MAIL AND ARE FILLED BY E-MAIL, so you are not involved in personal selling. You do it privately in your own home, store, or office. This is the GREATEST Multi-Level Mail Order Marketing anywhere: This is what you MUST do. 1. Order all 5 reports shown on the list below (You can't sell them if you don't have them). * For each report, send $5.00 CASH, the NAME & NUMBER OF THE REPORT YOU ARE ORDERING, YOUR E-MAIL ADDRESS, and YOUR NAME & RETURN ADDRESS (in case of a problem). *MAKE SURE YOUR RETURN ADDRESS IS ON YOUR ENVELOPE - IN CASE OF ANY MAIL PROBLEMS! * When you place your order, make sure you order each of the five reports. You need all five reports so that you can save them on your computer and resell them. * Within a few days you will receive, via e-mail, each of the five reports. Save them on your computer so they will be accessible for you to send to the 1,000's of people who will order them from you. 2. IMPORTANT- DO NOT alter the names of the people who are listed next to each report, or their order on the list in any way other than as instructed below in steps "a" through 'g" or you will lose out on the majority of your profits. Once you understand the way this works you'll also see how it doesn't work if you change it. Remember, this method has been tested, and if you alter it, it will not work. a. Look below for the listing of available reports. b. After you've ordered the. five reports, take this Advertisement and remove the name and address under REPORT #5. This person has made it through the cycle and is no doubt counting their $50,000! c. Move the name and address under REPORT #4 down to REPORT #5. d. Move the name and address under REPORT #3 down to REPORT #4. e. Move the name and address under REPORT #2 down to REPORT #3 f. Move the name and address under REPORT #1 down to REPORT #2. g. Insert your name and address in the REPORT #1 position. Please make sure you copy every name and address ACCURATELY! Copy and paste method works well,. 3. Take this entire letter, including the modified list of names, and save it to your computer. Make NO changes to the Instruction portion of this letter. Your cost to participate in this is practically nothing (surely you can afford $25). You obviously already have an Internet Connection and e-mail is FREE! To assist you with marketing your business on the internet, the 5 reports you purchase will provide you with invaluable marketing information which includes how to send bulk e-mails, where to find thousands of free classified ads and much, much more. Here are two primary methods of building your downline: METHOD #1: SENDING BULK E-MAIL Let's say that you decide to start small, just to see how it goes, and we'll assume you and all those involved send out only 2,000 programs each. Let's also assume that the mailing receives a 0.5% response. Using a good list, the response could be much better. Also, many people will send out hundreds of thousands of programs instead of 2,000. But continuing with this example, you send out only 2,000 programs. With a 0.5% response, that is only 10 orders for REPORT #1. Those 10 people respond by sending out 2,000 programs each for a total of 20,000. Out of those 0.5%, 100 people respond and order REPORT #2. Those 100 mail out 2,000 programs each for a total of 200,000. The 0.5% response to that is 1,000 orders for REPORT #3. Those 1,000 send out 2,000 programs each for a 2,000,000 total. The 0.5% response to that is I 0,000 orders for REPORT #4. That amounts to 10,000 each of $5 bills for you in CASH MONEY! Then think about level five! That's $500,000 alone! Your total income in this example is $50 + $500 + $5,000+ $50,000 + $500,000 for a total of $555,550!!! REMEMBER FRIEND, THIS IS ASSUMING 1,990 OUT OF THE 2,000 PEOPLE YOU MAIL TO WILL DO ABSOLUTELY NOTHING AND TRASH THIS PROGRAM! DARE TO THINK FOR A MOMENT WHAT WOULD HAPPEN IF EVERYONE, OR HALF SENT OUT 100,000 PROGRAMS INSTEAD OF 2,000. Believe me, many people will do just that and more! REPORT #2 will show you the best methods for bulk e-mailing, and e-mail software. METHOD #2 - PLACING FREE ADS ON THE INTERNET 1. Advertising on the Net is very, very inexpensive, and there are HUNDREDS of FREE places to advertise. Let's say you decide to start small just to see how well it works. Assume your goal is to get ONLY 10 people to participate on your first level. Placing a lot of FREE ads on the internet will EASILY get a larger response. Also assume that everyone else in YOUR ORGANIZATION gets ONLY 10 downline members. Follow this example to achieve the STAGGERING results below: 1st level-your 10 members with $5 ....... $50 2nd level-10 members from those 10 ($5 x 100) ....... $500 3rd level-10 members from those 100 ($5 x 1,000)....... $5,000 4th level-10 members from those 1,000 ($5 x 10k) ....... $50,000 5th level-10 members from those 10,000 ($5 x 100k) ....... $500,000 THIS TOTALS - $555,550 Remember friends, this assumes that the people who participate only recruit 10 people each. Think for a moment what would happen if they got 20 people to participate! Most people get 100's of participants. THINK ABOUT IT! For every $5.00 you receive, all you must do is e-mail them the report they ordered. THAT'S IT! ALWAYS PROVIDE SAME-DAY SERVICE ON ALL ORDERS! This will guarantee that the e-mail THEY send out with YOUR name and address on it will be prompt because they can't advertise until they receive the report! AVAILABLE REPORTS *** Order Each REPORT by NUMBER, AND NAME *** * ALWAYS SEND $5 CASH (U.S. CURRENCY) FOR EACH REPORT. CHECKS NOT ACCEPTED * - ALWAYS SEND YOUR ORDER VIA FIRST CLASS MAIL - Make sure the cash is concealed by wrapping it in at least two sheets of paper (SO THAT THE BILL CAN'T BE SEEN AGAINST LIGHT) On one of those sheets of paper include: (a) the number & name of the report you are ordering, (b) your e-mail address, and (c) your name & postal address (in case your e-mail provider encounters problems). PLACE YOUR ORDER FOR THESE REPORTS NOW: REPORT #1 "The Insiders Guide to Advertizing for Free on the Internet" ORDER REPORT #1 FROM: Alex AuYeung 231 E Morton St. Bethlehem, PA 18015 USA REPORT #2 "The Insiders Guide to Sending Bulk Email on the Internet" ORDER REPORT #2 FROM: Wendy Anderson 23 Angus Lane Riverview, New Brunswick Canada E1B 5M2 REPORT #3 "The Secrets to Multilevel Marketing on the Internet" ORDER REPORT #3 FROM: Randy Dillard P.O. Box 8 Osprey, FL 34229 USA REPORT #4 'How to become a Millionaire utilizing the Power of Multilevel Marketing and the Internet" ORDER REPORT #4 FROM: Carla Brown P.O. Box 39093 Sarasota, FL 34238 USA REPORT #5 "How to Send One Million E-Mails for Free." ORDER REPORT #5 FROM: Glynn Schmidt P.O. Box 19424 Sarasota, FL 34276 USA About 50,000 new people get online every month! ******* TIPS FOR SUCCESS ******* * TREAT THIS AS YOUR BUSINESS! Be prompt, professional, and follow the directions accurately. * Send for the five reports IMMEDIATELY so you will have them when the orders start coming in. When you receive a $5 order, you MUST send out the requested product/report. * ALWAYS PROVIDE SAME-DAY SERVICE ON THE ORDERS YOU RECEIVE. * Be patient and persistent with this program. If you follow the instructions exactly, your results WILL BE SUCCESSFUL! * ABOVE ALL, HAVE FAITH IN YOURSELF AND KNOW YOU WILL SUCCEED! ******* YOUR SUCCESS GUIDELINES ******* Follow these guidelines to guarantee your success: Start posting ads as soon as you mail off for the reports! By the time you start receiving orders, your reports will be in your mailbox! For now, something simple, such as posting on message boards something to the effect of "Would you like to know how to earn $50,000 working out of your house with NO initial investment? Email me with the keywords "more info" to find out how. And, when they email you, send them this report in response! If you don't receive 20 orders for REPORT #1 within two weeks, continue advertising or sending e-mails until you do. Then, a couple of weeks later you should receive at least 100 orders for REPORT#2. If you don't, continue advertising or sending e-mails until you do. Once you have received 100 or more orders for REPORT #2, YOU CAN RELAX, because the system is already working for you, and the cash will continue to roll in! THIS IS IMPORTANT TO REMEMBER: Every time your name is moved down on the list you are placed in front of a DIFFERENT report. You can KEEP TRACK of your PROGRESS by watching which report people are ordering from you. If you want to generate more income, send another batch of e-mails or continue placing ads and start the whole process again! There is no limit to the income you will generate from this business! Before you make your decision as to whether or not you participate in this program, answer one question ... DO YOU WANT TO CHANGE YOUR LIFE? If the answer is yes, please look at the following facts about this program: 1. YOU ARE SELLING A PRODUCT WHICH DOES NOT COST ANYTHING TO PRODUCE! 2. YOU ARE SELLING A PRODUCT WHICH DOES NOT COST ANYTHING TO SHIP! 3. YOU ARE SELLING A PRODUCT WHICH DOES NOT COST YOU ANYTHING TO ADVERTISE! 4. YOU ARE UTILIZING THE POWER OF THE INTERNET AND THE POWER OF MULTI-LEVEL MARKETING TO DISTRIBUTE YOUR PRODUCT ALL OVER THE WORLD! 5. YOUR ONLY EXPENSES OTHER THAN YOUR INITIAL $25 INVESTMENT IS YOUR TIME! 6. VIRTUALLY ALL OF THE INCOME YOU GENERATE FROM THIS PROGRAM IS PURE PROFIT! 7. THIS PROGRAM WILL CHANGE YOUR LIFE FOREVER. ******* TESTIMONIALS******* This program does work, but you must follow it EXACTLY! Especially the rule of not trying to place your name in a different position, it won't work and you'll lose a lot of potential income. I'm living proof that it works. It really is a great opportunity to make relatively easy money, with little cost to you. If you do choose to participate, follow the program exactly, and you'll be on your way to financial security. -Steven Bardfield, Portland, OR My name is Mitchell. My wife, Jody, and I live in Chicago, IL. I am a cost accountant with a major U.S. Corporation and I make pretty good money. When I received the program I grumbled to Jody about receiving "junk mail." I made fun of the whole thing, spouting my knowledge of the population and percentages involved. I 'knew' it wouldn't work. Jody totally ignored my supposed intelligence and jumped in with both feet. I made merciless fun of her, and was ready to lay the old 'I told you so' on her when the thing didn't work... well, the laugh was on me! Within two weeks she had received over 50 responses. Within 45 days she had received over $147,200 in $5 bills! I was shocked! I was sure that I had it all figured and that it wouldn't work. I AM a believer now. I have joined Jody in her "hobby. " I did have seven more years until retirement, but I think of the 'rat race,' and it's not for me. We owe it all to MLM. -Mitchell Wolf MD., Chicago, IL. The. main reason for this letter is to convince you that this system is honest, lawful, extremely profitable, and is a way to get a large amount of money in a short time. I was approached several times before 1 checked this out. I joined just to see what one could expect in return for the minimal effort and money required. To my astonishment I received $36,470.00 in the first 14 weeks, with money still coming in. -Charles Morris, Esq. Not being the gambling type, it took me several weeks to make up my mind to participate in this plan. But conservative that I am, I decided that the initial investment was so little that there was just no way that I wouldn't get enough orders to at least get my money back. Boy, was I surprised when I found my medium- size post office box crammed with orders! For awhile, it got so overloaded that I had to start picking up my mail at the window. I'll make more money this year than any 10 years of my life before. The nice thing about this deal is that it doesn't matter where people live. There simply isn't a better investment with a faster return. -Paige Willis, Des Moines, IA I had received this program before. I deleted it, but later I wondered if I shouldn't have given it a try. Of course, I had no idea who to contact to get another copy, so I had to wait until I was e-mailed another program ... 11 months passed then it came ... I didn't delete this one! ... I made. more than $41,000 on the first try!! -Violet Wilson, Johnstown, PA This is my third time to participate in this plan. We have quit our jobs, and will soon buy a home on the beach and live off the interest on our money. The only way on earth that this plan will work for you is if you do it. For your sake, and for your family's sake don't pass up this golden opportunity. Good luck and happy spending! -Kerry Ford, Centerport, NY IT IS UP TO YOU NOW! Take 5 minutes to Change Your Future! ORDER YOUR REPORTS TODAY AND GET STARTED ON YOUR ROAD TO FINANCIAL FREEDOM! FOR YOUR INFORMATION: If you need help with starting a business, registering a business name, learning how income tax is handled, etc., contact your local office of the Small Business Administration (a Federal agency) 1(800) 827-5722 for free help and answers to questions. Also, the Internal Revenue Service offers free help via telephone and free seminars about business tax requirements. Under Bill S1618 Title HI passed by the 105th US Congress this letter cannot be considered spam as long as the sender includes contact information and a method of removal. This is a one time e-mail transmission. No request for removal is necessary. To remove (even though this is not necessary) press alex18015 at hotmail.com STOP! If you never read another e-mail PLEASE take a moment to read this one. This really is worth your valuable time. Even if you never got involved in the program, the reports themselves are well worth the money. They can help you start and advertise ANY business on the internet. That is, these reports stand alone and are beneficial to anyone wishing to do business on the internet. At the very least PRINT THIS OUT NOW to read later if you are pressed for time. From remailer at aarg.net Fri Aug 9 16:10:08 2002 From: remailer at aarg.net (AARG! Anonymous) Date: Fri, 9 Aug 2002 16:10:08 -0700 Subject: No subject Message-ID: Adam Back writes a very thorough analysis of possible consequences of the amazing power of the TCPA/Palladium model. He is clearly beginning to "get it" as far as what this is capable of. There is far more to this technology than simple DRM applications. In fact Adam has a great idea for how this could finally enable selling idle CPU cycles while protecting crucial and sensitive business data. By itself this could be a "killer app" for TCPA/Palladium. And once more people start thinking about how to exploit the potential, there will be no end to the possible applications. Of course his analysis is spoiled by an underlying paranoia. So let me ask just one question. How exactly is subversion of the TPM a greater threat than subversion of your PC hardware today? How do you know that Intel or AMD don't already have back doors in their processors that the NSA and other parties can exploit? Or that Microsoft doesn't have similar backdoors in its OS? And similarly for all the other software and hardware components that make up a PC today? In other words, is this really a new threat? Or are you unfairly blaming TCPA for a problem which has always existed and always will exist? From remailer at aarg.net Fri Aug 9 17:15:19 2002 From: remailer at aarg.net (AARG! Anonymous) Date: Fri, 9 Aug 2002 17:15:19 -0700 Subject: TCPA/Palladium -- likely future implications Message-ID: <09128eee2dde41bc96cae43940d56ab1@aarg.net> I want to follow up on Adam's message because, to be honest, I missed his point before. I thought he was bringing up the old claim that these systems would "give the TCPA root" on your computer. Instead, Adam is making a new point, which is a good one, but to understand it you need a true picture of TCPA rather than the false one which so many cypherpunks have been promoting. Earlier Adam offered a proposed definition of TCPA/Palladium's function and purpose: > "Palladium provides an extensible, general purpose programmable > dongle-like functionality implemented by an ensemble of hardware and > software which provides functionality which can, and likely will be > used to expand centralised control points by OS vendors, Content > Distrbuters and Governments." IMO this is total bullshit, political rhetoric that is content-free compared to the one I offered: : Allow computers separated on the internet to cooperate and share data : and computations such that no one can get access to the data outside : the limitations and rules imposed by the applications. It seems to me that my definition is far more useful and appropriate in really understanding what TCPA/Palladium are all about. Adam, what do you think? If we stick to my definition, you will come to understand that the purpose of TCPA is to allow application writers to create closed spheres of trust, where the application sets the rules for how the data is handled. It's not just DRM, it's Napster and banking and a myriad other applications, each of which can control its own sensitive data such that no one can break the rules. At least, that's the theory. But Adam points out a weak spot. Ultimately applications trust each other because they know that the remote systems can't be virtualized. The apps are running on real hardware which has real protections. But applications know this because the hardware has a built-in key which carries a certificate from the manufacturer, who is called the TPME in TCPA. As the applications all join hands across the net, each one shows his cert (in effect) and all know that they are running on legitimate hardware. So the weak spot is that anyone who has the TPME key can run a virtualized TCPA, and no one will be the wiser. With the TPME key they can create their own certificate that shows that they have legitimate hardware, when they actually don't. Ultimately this lets them run a rogue client that totally cheats, disobeys all the restrictions, shows the user all of the data which is supposed to be secret, and no one can tell. Furthermore, if people did somehow become suspicious about one particular machine, with access to the TPME key the eavesdroppers can just create a new virtual TPM and start the fraud all over again. It's analogous to how someone with Verisign's key could masquerade as any secure web site they wanted. But it's worse because TCPA is almost infinitely more powerful than PKI, so there is going to be much more temptation to use it and to rely on it. Of course, this will be inherently somewhat self-limiting as people learn more about it, and realize that the security provided by TCPA/Palladium, no matter how good the hardware becomes, will always be limited to the political factors that guard control of the TPME keys. (I say keys because likely more than one company will manufacture TPM's. Also in TCPA there are two other certifiers: one who certifies the motherboard and computer design, and the other who certifies that the board was constructed according to the certified design. The NSA would probably have to get all 3 keys, but this wouldn't be that much harder than getting just one. And if there are multiple manufacturers then only 1 key from each of the 3 categories is needed.) To protect against this, Adam offers various solutions. One is to do crypto inside the TCPA boundary. But that's pointless, because if the crypto worked, you probably wouldn't need TCPA. Realistically most of the TCPA applications can't be cryptographically protected. "Computing with encrypted instances" is a fantasy. That's why we don't have all those secure applications already. Another is to use a web of trust to replace or add to the TPME certs. Here's a hint. Webs of trust don't work. Either they require strong connections, in which case they are too sparse, or they allow weak connections, in which case they are meaningless and anyone can get in. I have a couple of suggestions. One early application for TCPA is in closed corporate networks. In that case the company usually buys all the computers and prepares them before giving them to the employees. At that time, the company could read out the TPM public key and sign it with the corporate key. Then they could use that cert rather than the TPME cert. This would protect the company's sensitive data against eavesdroppers who manage to virtualize their hardware. For the larger public network, the first thing I would suggest is that the TPME key ought to be in hardware, so it can't be given out freely. Of course the NSA could still come in and get their virtual-TPM keys signed one at a time. So the next step is that the device holding the TPME key must be managed in a high security environment. This may be difficult, given the need to sign potentially thousands of TPM keys a day, but I think it has to be done. I want to see watchdogs from the EFF and a lot of other groups sitting there 24 hours a day watching over the device. Remember how Clipper was going to use a vault, split keys and all this elaborate precautions? We need at least that much security. Think about it: this one innocuous little box holding the TPME key could ultimately be the root of trust for the entire world. IMO we should spare no expense in guarding it and making sure it is used properly. With enough different interest groups keeping watch, we should be able to keep it from being used for anything other than its defined purpose. From jamesd at echeque.com Fri Aug 9 18:21:44 2002 From: jamesd at echeque.com (James A. Donald) Date: Fri, 09 Aug 2002 18:21:44 -0700 Subject: TCPA/Palladium -- likely future implications In-Reply-To: <09128eee2dde41bc96cae43940d56ab1@aarg.net> Message-ID: <3D540838.25514.251A3CE@localhost> -- On 9 Aug 2002 at 17:15, AARG! Anonymous wrote: > to understand it you need a true picture of TCPA rather than the > false one which so many cypherpunks have been promoting. As TCPA is currently vaporware, projections of what it will be, and how it will be used are judgments, and are not capable of being true or false, though they can be plausible or implausible. Even with the best will in the world, and I do not think the people behind this have the best will in the world, there is an inherent conflict between tamper resistance and general purpose programmability. To prevent me from getting at the bits as they are sent to my sound card or my video card, the entire computer, not just the dongle, has to be somewhat tamper resistant, which is going to make the entire computer somewhat less general purpose and programmable, thus less useful. The people behind TCPA might want to do something more evil than you say they want to do, if they want to do what you say they want to do they might be prevented by law enforcement which wants something considerably more far reaching and evil, and if they want to do it, and law enforcement refrains from reaching out and taking hold of their work, they still may be unable to do it for technical reasons. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG D7ZUyyAS+7CybaH0GT3tHg1AkzcF/LVYQwXbtqgP 2HBjGwLqIOW1MEoFDnzCH6heRfW1MNGv1jXMIvtwb From k.brown at ccs.bbk.ac.uk Fri Aug 9 10:43:05 2002 From: k.brown at ccs.bbk.ac.uk (Ken Brown) Date: Fri, 09 Aug 2002 18:43:05 +0100 Subject: Challenge to TCPA/Palladium detractors References: <200208072113.g77LDaC17060@gungnir.fnal.gov> <3D5378ED.9941.21E6F6@localhost> Message-ID: <3D53FF29.4A4959E0@ccs.bbk.ac.uk> "James A. Donald" wrote: > > -- > On Wed, 7 Aug 2002, Matt Crawford wrote: > > > Unless the application author can predict the exact output of > > > the compilers, he can't issue a signature on the object code. > > > The > > On 9 Aug 2002 at 10:48, Eugen Leitl wrote: > > Same version of compiler on same source using same build > > produces identical binaries. > > This has not been my experience. Nor anyone else's If only because the exact image you depends on a hell of a lot of programs & libraries. Does anyone expect /Microsoft/ of all software suppliers to provide consistent versioning and reproducible or predictable software environments? These are the people who brought us "DLL Hell". These are the people who fell into the MDAC versioning fiasco. Ken From gmorsyalesyf at hotmail.com Sat Aug 10 04:51:45 2002 From: gmorsyalesyf at hotmail.com (Kay Hoag) Date: Fri, 09 Aug 2002 18:51:45 -1700 Subject: See YOUR CREDIT improve Online in Real Time! 11695 Message-ID: <00004c6802ac$000004c8$00002f6f@mx14.hotmail.com> A non-text attachment was scrubbed... Name: not available Type: text/html Size: 2679 bytes Desc: not available URL: From eresrch at eskimo.com Fri Aug 9 19:03:38 2002 From: eresrch at eskimo.com (Mike Rosing) Date: Fri, 9 Aug 2002 19:03:38 -0700 (PDT) Subject: TCPA ad nauseum In-Reply-To: Message-ID: On Fri, 9 Aug 2002, AARG! Anonymous wrote: > Of course his analysis is spoiled by an underlying paranoia. So let me > ask just one question. How exactly is subversion of the TPM a greater > threat than subversion of your PC hardware today? How do you know that > Intel or AMD don't already have back doors in their processors that > the NSA and other parties can exploit? Or that Microsoft doesn't have > similar backdoors in its OS? And similarly for all the other software > and hardware components that make up a PC today? > > In other words, is this really a new threat? Or are you unfairly blaming > TCPA for a problem which has always existed and always will exist? The difference is that *anyone* can see what goes on inside an Intel or AMD processor. Only the key holder of the TPM can see inside the "protected" code space. You can't put back doors into the code now because the code is visible to all users. The purpose of crypto is to hide information even tho the attacker can see all the machinery work. If you don't want to have the machinery visible, then use a sealed system (like smart card). Patience, persistence, truth, Dr. mike From eresrch at eskimo.com Fri Aug 9 19:10:27 2002 From: eresrch at eskimo.com (Mike Rosing) Date: Fri, 9 Aug 2002 19:10:27 -0700 (PDT) Subject: TCPA/Palladium -- likely future implications In-Reply-To: <09128eee2dde41bc96cae43940d56ab1@aarg.net> Message-ID: On Fri, 9 Aug 2002, AARG! Anonymous wrote: > : Allow computers separated on the internet to cooperate and share data > : and computations such that no one can get access to the data outside > : the limitations and rules imposed by the applications. > > It seems to me that my definition is far more useful and appropriate in > really understanding what TCPA/Palladium are all about. Adam, what do > you think? Just because you can string words together and form a definition doesn't make it realizable. Once data is in the clear it can be copied, and no rules can change that. Either the data is available to the user, and they can copy it - or the data is not available to the user, and there's nothing they can do when their machine does somebody elses calculations. > I have a couple of suggestions. One early application for TCPA is in > closed corporate networks. In that case the company usually buys all > the computers and prepares them before giving them to the employees. > At that time, the company could read out the TPM public key and sign > it with the corporate key. Then they could use that cert rather than > the TPME cert. This would protect the company's sensitive data against > eavesdroppers who manage to virtualize their hardware. And guess what? I can buy that today! I don't need either TCPA or Palladium. So why do we need TCPA? > Think about it: this one innocuous little box holding the TPME key could > ultimately be the root of trust for the entire world. IMO we should > spare no expense in guarding it and making sure it is used properly. > With enough different interest groups keeping watch, we should be able > to keep it from being used for anything other than its defined purpose. Man, I want the stuff you are smoking! One attack point is the root of trust for the whole world!!???!!! Take another hit dude, and make sure you see lots of colors too. Patience, persistence, truth, Dr. mike From remailer at aarg.net Fri Aug 9 19:30:09 2002 From: remailer at aarg.net (AARG!Anonymous) Date: Fri, 9 Aug 2002 19:30:09 -0700 Subject: Challenge to TCPA/Palladium detractors Message-ID: <9a9b042036dae4dc85cd793e52375ec5@aarg.net> Re the debate over whether compilers reliably produce identical object (executable) files: The measurement and hashing in TCPA/Palladium will probably not be done on the file itself, but on the executable content that is loaded into memory. For Palladium it is just the part of the program called the "trusted agent". So file headers with dates, compiler version numbers, etc., will not be part of the data which is hashed. The only thing that would really break the hash would be changes to the compiler code generator that cause it to create different executable output for the same input. This might happen between versions, but probably most widely used compilers are relatively stable in that respect these days. Specifying the compiler version and build flags should provide good reliability for having the executable content hash the same way for everyone. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From adam at cypherspace.org Fri Aug 9 12:11:15 2002 From: adam at cypherspace.org (Adam Back) Date: Fri, 9 Aug 2002 20:11:15 +0100 Subject: Signing as one member of a set of keys In-Reply-To: ; from anonymous@remailer.havenco.com on Fri, Aug 09, 2002 at 03:52:56AM +0000 References: Message-ID: <20020809201115.A643604@exeter.ac.uk> Very nice. Nice plausible set of candidate authors also: pub 1022/5AC7B865 1992/12/01 loki at obscura.com pub 1024/2B48F6F5 1996/04/10 Ian Goldberg pub 1024/97558A1D 1994/01/10 Pr0duct Cypher pub 1024/2719AF35 1995/05/13 Ben Laurie pub 1024/58214C37 1992/09/08 Hal Finney <74076.1041 at compuserve.com> pub 1024/C8002BD1 1997/03/04 Eric Young pub 1024/FBBB8AB1 1994/05/07 Colin Plumb Wonder if we can figure out who is most likely author based on coding style from such a small set. It has (8 char) TABs but other wise BSD indentation style (BSD normally 4 spaces). Also someone who likes triply indirected pointers ***blah in there. Has local variables inside even *if code blocks* eg, inside main() (most people avoid that, preferring to declare variables at the top of a function, and historically I think some older gcc / gdb couldn't debug those variables if I recall). Very funky use of goto in getpgppkt, hmmm. Somewhat concise coding and variable names. Off the cuff guess based on coding without looking at samples of code to remind, probably Colin or Ian. Of course (Lance Cottrell/Ian Goldberg/Pr0duct Cypher/Ben Laurie/Hal Finney/Eric Young/Colin Plumb) possibly deviated or mimicked one of their coding styles. Kind of interesting to see a true nym in there also. Also the Cc -- Coderpunks lives? I think the Cc coderpunks might be a clue also, I think some of these people would know it died. I think that points more at Colin. Other potential avenue might be implementation mistake leading to failure of the scheme to robustly make undecidable which of the set is the true author, given alpha code. Adam On Fri, Aug 09, 2002 at 03:52:56AM +0000, Anonymous User wrote: > This program can be used by anonymous contributors to release partial > information about their identity - they can show that they are someone > from a list of PGP key holders, without revealing which member of the > list they are. Maybe it can help in the recent controvery over the > identity of anonymous posters. It's a fairly low-level program that > should be wrapped in a nicer UI. I'll send a couple of perl scripts > later that make it easier to use. From remailer at aarg.net Fri Aug 9 20:25:40 2002 From: remailer at aarg.net (AARG! Anonymous) Date: Fri, 9 Aug 2002 20:25:40 -0700 Subject: Thanks, Lucky, for helping to kill gnutella Message-ID: Several people have objected to my point about the anti-TCPA efforts of Lucky and others causing harm to P2P applications like Gnutella. Eric Murray wrote: > Depending on the clients to "do the right thing" is fundamentally > stupid. Bran Cohen agrees: > Before claiming that the TCPA, which is from a deployment standpoint > vaporware, could help with gnutella's scaling problems, you should > probably learn something about what gnutella's problems are first. The > truth is that gnutella's problems are mostly that it's a screamer > protocol, and limiting which clients could connect would do nothing to fix > that. I will just point out that it was not my idea, but rather that Salon said that the Gnutella developers were considering moving to authorized clients. According to Eric, those developers are "fundamentally stupid." According to Bram, the Gnutella developers don't understand their own protocol, and they are supporting an idea which will not help. Apparently their belief that clients like Qtrax are hurting the system is totally wrong, and keeping such clients off the system won't help. I can't help believing the Gnutella developers know more about their own system than Bram and Eric do. If they disagree, their argument is not with me, but with the Gnutella people. Please take it there. Ant chimes in: > My copy of "Peer to Peer" (Oram, O'Reilly) is out on loan but I think Freenet > and Mojo use protocols that require new users to be contributors before they > become consumers. Pete Chown echoes: > If you build a protocol which allows selfish behaviour, you have done > your job badly. Preventing selfish behaviour in distributed systems is > not easy, but that is the problem we need to solve. It would be a good > discussion for this list. As far as Freenet and MojoNation, we all know that the latter shut down, probably in part because the attempted traffic-control mechanisms made the whole network so unwieldy that it never worked. At least in part this was also due to malicious clients, according to the analysis at http://www.cs.rice.edu/Conferences/IPTPS02/188.pdf. And Freenet has been rendered inoperative in recent months by floods. No one knows whether they are fundamental protocol failings, or the result of selfish client strategies, or calculated attacks by the RIAA and company. Both of these are object lessons in the difficulties of successful P2P networking in the face of arbitrary client attacks. Some people took issue with the personal nature of my criticism: > Your personal vendetta against Lucky is very childish. > This sort of attack doesn't do your position any good. Right, as if my normal style has been so effective. Not one person has given me the least support in my efforts to explain the truth about TCPA and Palladium. Anyway, maybe I was too personal in singling out Lucky. He is far from the only person who has opposed TCPA. But Lucky, in his slides at http://www.cypherpunks.to, claims that TCPA's designers had as one of their objectives "To meet the operational needs of law enforcement and intelligence services" (slide 2); and to give privileged access to user's computers to "TCPA members only" (slide 3); that TCPA has an OS downloading a "serial number revocation list" (SNRL) which he has provided no evidence for whatsoever (slide 14); that it loads an "initial list of undesirable applications" which is apparently another of his fabrications (slide 15); that TCPA applications on startup load both a serial number revocation list but also a document revocation list, again a completely unsubstantiated claim (slide 19); that apps then further verify that spyware is running, another fabrication (slide 20). He then implies that the DMCA applies to reverse engineering when it has an explicit exemption for that (slide 23); that the maximum possible sentence of 5 years is always applied (slide 24); that TCPA is intended to: defeat the GPL, enable information invalidation, facilitate intelligence collection, meet law enforcement needs, and more (slide 27); that only signed code will boot in TCPA, contrary to the facts (slide 28). He provides more made-up details about the mythical DRL (slide 31); more imaginary details about document IDs, information monitoring and invalidation to support law enforcement and intelligence needs, none of which has anything to do with TCPA (slide 32-33). As apparent support for these he provides an out-of-context quote[1] from a Palladium manager, who if you read the whole article was describing their determination to keep the system open (slide 34). He repeats the unfounded charge that the Hollings bill would mandate TCPA, when there's nothing in the bill that says such a thing (slide 35); and he exaggerates the penalties in that bill by quoting the maximum limits as if they are the default (slide 36). Lucky can provide all this misinformation, all under the pretence, mind you, that this *is* TCPA. He was educating the audience, mostly people who were completely unfamiliar with the system other than some vague rumors. And this is what he presents, a tissue of lies and fabrications and unfounded sensationalism. Don't forget, TCPA and Palladium were designed by real people. In making these charges, Lucky is not just talking about a standard, he is talking about its authors. He is saying that those people were attempting to serve intelligence needs, to make sure that people had to run spyware, to close down the system so it could keep "undesirable" applications off. He is accusing the designers of far worse than anything I have said about him. He is basically saying that they are striving to bring about a technological police state. And yet, no one (other than me, of course) dared to criticize Lucky for these claims. He can say whatever he wants, be as outrageous as he wants, and no one says a thing. I don't know whether everyone agrees with him, or is simply unwilling to risk criticism by departing from the groupthink which is so universal around here. I asked Eric Murray, who knows something about TCPA, what he thought of some of the more ridiculous claims in Ross Anderson's FAQ (like the SNRL), and he didn't respond. I believe it is because he is unwilling to publicly take a position in opposition to such a famous and respected figure. But anyway, maybe I was too personal in criticizing Lucky. Tell you what. I'll apologize to Lucky as soon as he apologizes to the designers of TCPA for the fabrications in his slide show. Deal? ------------------------------------------------------------------------ [1] We are talking to the government now, and maybe this is where we get some advantage from having a broad industry initiative. Our fundamental goal is "let's do the right thing." We have pretty strong feelings about what the right thing is on terms of making sure that things are truly anonymous and that key escrow kinds of things don't happen. But there ARE governments in the world, and not just the U.S. Government. http://www.techweb.com/index/news/Hardwa...WB19980901S0016/INW20020626S0007 From rah at shipwright.com Fri Aug 9 17:38:28 2002 From: rah at shipwright.com (R. A. Hettinga) Date: Fri, 9 Aug 2002 20:38:28 -0400 Subject: Thanks, Lucky, for helping to kill gnutella (fwd) In-Reply-To: References: Message-ID: At 1:03 AM +0200 on 8/10/02, Some anonymous, and now apparently innumerate, idiot in my killfile got himself forwarded to Mr. Leitl's cream of cypherpunks list: > They will protect us from being able > to extend trust across the network. As Dan Geer and Carl Ellison have reminded us on these lists and elsewhere, there is no such thing as "trust", on the net, or anywhere else. There is only risk. Go learn some finance before you attempt to abstract emotion into the quantifiable. Actual numerate, thinking, people gave up on that nonsense in the 1970's, and the guys who proved the idiocy of "trust", showing, like LaGrange said to Napoleon about god, that the capital markets "had no need that hypothesis, Sire" ended up winning a Nobel for that proof the 1990's*. Cheers, RAH *The fact that Scholes and Merton eventually ended up betting on equity volatility like it was actually predictable and got their asses handed to them for their efforts is beside the point, of course. :-). -- ----------------- R. A. Hettinga The Internet Bearer Underwriting Corporation 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire' --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From ant at notatla.demon.co.uk Fri Aug 9 12:55:32 2002 From: ant at notatla.demon.co.uk (Antonomasia) Date: Fri, 9 Aug 2002 20:55:32 +0100 (BST) Subject: Thanks, Lucky, for helping to kill gnutella Message-ID: <20020809195532.500AD46D3@notatla.demon.co.uk> From: AARG!Anonymous > An article on Salon this morning (also being discussed on slashdot), > http://www.salon.com/tech/feature/2002/08/08/gnutella_developers/print.html, > discusses how the file-trading network Gnutella is being threatened by > misbehaving clients. In response, the developers are looking at limiting > the network to only authorized clients: > They intend to do this using digital signatures, and there is precedent > for this in past situations where there have been problems: > > Alan Cox, .... "Years and years ago this came up with a game > If only there were a technology in which clients could verify and yes, > Be sure and send a note to the Gnutella people reminding them of all > you're doing for them, okay, Lucky? Now that is resorting to silly accusation. My copy of "Peer to Peer" (Oram, O'Reilly) is out on loan but I think Freenet and Mojo use protocols that require new users to be contributors before they become consumers. (Leaving aside that Gnutella seems doomed on scalability grounds.) Likewise the WAN shooter games have (partially) defended against cheats by making the client hold no authoritative data and by disqualifying those that send impossible traffic. (Excluding wireframe graphics cards is another matter.) If I were a serious gamer I'd want 2 communities - one for plain clients to match gaming skills and another for "cheat all you like" contests to match both gaming and programming skills. If the Gnuts need to rework the protocol they should do so. My objection to this TCPA/palladium thing is that it looks aimed at ending ordinary computing. If the legal scene were radically different this wouldn't be causing nearly so much fuss. Imagine: - a DoJ that can enforce monopoly law - copyright that expires in reasonable time (5 years for s/w ? 15 years for books,films,music... ?) - fair use and first sale are retained - no concept of indirect infringement (e.g. selling marker pens) - criminal and civil liability for incorrectly barring access in DRM - hacking is equally illegal for everybody - no restriction on making and distributing/selling any h/w,s/w If Anonymous presents Gnutella for serious comparison with the above issues I say he's looking in the wrong end of his telescope. -- ############################################################## # Antonomasia ant notatla.demon.co.uk # # See http://www.notatla.demon.co.uk/ # ############################################################## --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From Pete.Chown at skygate.co.uk Fri Aug 9 12:56:25 2002 From: Pete.Chown at skygate.co.uk (Pete Chown) Date: 09 Aug 2002 20:56:25 +0100 Subject: Thanks, Lucky, for helping to kill gnutella In-Reply-To: <8c25bf764b14de9e2d3d9cd24a6d49fb@aarg.net> References: <8c25bf764b14de9e2d3d9cd24a6d49fb@aarg.net> Message-ID: <1028922985.1918.255.camel@yeltsin.mthink> Anonymous wrote: > ... the file-trading network Gnutella is being threatened by > misbehaving clients. In response, the developers are looking at limiting > the network to only authorized clients: This is the wrong solution. One of the important factors in the Internet's growth was that the IETF exercised enough control, but not too much. So HTTP is standardised, which allows (theoretically) any browser to talk to any web server. At the same time the higher levels are not standardised, so someone who has an idea for a better browser or web server is free to implement it. If you build a protocol which allows selfish behaviour, you have done your job badly. Preventing selfish behaviour in distributed systems is not easy, but that is the problem we need to solve. It would be a good discussion for this list. > Not discussed in the article is the technical question of how this can > possibly work. If you issue a digital certificate on some Gnutella > client, what stops a different client, an unauthorized client, from > pretending to be the legitimate one? Exactly. This has already happened with unauthorised AIM clients. My freedom to lie allows me to use GAIM rather than AOL's client. In this case, IMO, the ethics are the other way round. AOL seeks to use its (partial) monopoly to keep a grip on the IM market. The freedom to lie mitigates this monopoly to an extent. -- Pete --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From wolf at priori.net Fri Aug 9 21:26:37 2002 From: wolf at priori.net (Meyer Wolfsheim) Date: Fri, 9 Aug 2002 21:26:37 -0700 (PDT) Subject: Signing as one member of a set of keys In-Reply-To: Message-ID: On Fri, 9 Aug 2002, Anonymous User wrote: > This program can be used by anonymous contributors to release partial > information about their identity - they can show that they are someone > from a list of PGP key holders, without revealing which member of the > list they are. Maybe it can help in the recent controvery over the > identity of anonymous posters. It's a fairly low-level program that > should be wrapped in a nicer UI. I'll send a couple of perl scripts > later that make it easier to use. > > === Most delightful. Thank you for reminding us that Cypherpunks do indeed write code. More comments in a bit. [MW SNIP] > ++multisig v1.0 > pEsBwalpBRxWyJR8tkYm6qR27UW9IT6Vg8SlOHIsEkk04RJvoSy0cy4ISFCq6vDX > 5ub6c+MYi/UoyR6tI7oqpMu1abcXWm2DkfDiCsD6jQddVkiiYdG7Bih8JWdWmp5l > AgzqUoz14671/ezmWSrPNsTNKV96+ZLEanZsqfkpQcnZpLkWVpJzQFe0VgDQ64b2 > +e2efrbknLFq0FTdX7Sh3qzAfzNYYgADmeOxDoTm9sb6T0fULf1P7mjiN2LZXuEW > m/8QvksaQi9KGa/0xN2m0heNtS1cfsTa+NJz8XYyG/tnMy7+mvI3c3lrnz+6Dpyp > pbNwaX+12VcqtfNec9faoq8RJgFxmSO/ZfMOGM8cFBQ75ZOaoBJP5ObHZ/63FFh5 > Wh5GzwJjQs0vLwpM3iF6G+IixEqAQYisUdCopP1wXCLgltDM6l7jRlXxNDj0AXQ1 > eQJolo32vemcy8Z8GAn5tpQHmJwpdzZpboWRQY53pD4mVnEMN4GBC1mhbbI2z+Oh > lPglqmmy3p4D+psNU1rlNv6yH/L0PgcuW7taVpbopjl4HLuJdWcKHJlXish3D/jb > eoQ856fYFZ/omGiO9x1D0BsnGFLZVWob4OIZRzO/Pc49VIhFy5NsV2zuozStId89 > [...] > */ That [...] you see is an artifact of the anonymous remailer you were using. Mixmaster, I believe, gives the option to truncate messages which appear to include binary encoded data. PGP messages are explicitly allowed to be sent. Immediate problem: we can't verify your signature. Short term solution: find a remailer that allows binary posting. Long term solution: perhaps contact the Mixmaster authors and ask them to explicitly allow "multisig" data? -MW- From cypherpunks at minder.net Fri Aug 9 11:50:04 2002 From: cypherpunks at minder.net (cypherpunks) Date: Fri, 9 Aug 2002 21:50:04 +0300 Subject: TURNE ORGANiZASYONLARI iCiN KAMPANYA.. Message-ID: <200208091848.g79ImYJ07892@locust.minder.net> A non-text attachment was scrubbed... Name: not available Type: text/html Size: 5224 bytes Desc: not available URL: From adam at cypherspace.org Fri Aug 9 14:13:56 2002 From: adam at cypherspace.org (Adam Back) Date: Fri, 9 Aug 2002 22:13:56 +0100 Subject: TCPA/Palladium -- likely future implications (Re: dangers of TCPA/palladium) In-Reply-To: <20020809041533.GP23240@zork.net>; from schoen@loyalty.org on Thu, Aug 08, 2002 at 09:15:33PM -0700 References: <20020805060031.A518477@exeter.ac.uk> <200208081916.VAA02035@home.unipay.nl> <20020809041533.GP23240@zork.net> Message-ID: <20020809221356.A637432@exeter.ac.uk> On Thu, Aug 08, 2002 at 09:15:33PM -0700, Seth David Schoen wrote: > Back in the Clipper days [...] "how do we know that this > tamper-resistant chip produced by Mykotronix even implements the > Clipper spec correctly?". The picture is related but has some extra wrinkles with the TCPA/Palladium attestable donglization of CPUs. - It is always the case that targetted people can have hardware attacks perpetrated against them. (Keyboard sniffers placed during court authorised break-in as FBI has used in mob case of PGP using Mafiosa [1]). - In the clipper case people didn't need to worry much if the clipper chip had malicious deviations from spec, because Clipper had an openly stated explicit purpose to implement a government backdoor -- there's no need for NSA to backdoor the explicit backdoor. But in the TCPA/Palladium case however the hardware tampering risk you identify is as you say relevant: - It's difficult for the user to verify hardware. - Also: it wouldn't be that hard to manufacture plausibly deniable implementation "mistakes" that could equate to a backdoor -- eg the random number generators used to generate the TPM/SCP private device keys. However, beyond that there is an even softer target for would-be backdoorers: - the TCPA/Palladium's hardware manufacturers endoresment CA keys. these are the keys to the virtual kingdom formed -- the virtual kingdom by the closed space within which attested applications and software agents run. So specifically let's look at the questions arising: 1. What could a hostile entity(*) do with a copy of a selection of hardware manufacturer endorsement CA private keys? ( (*) where the hostile entity candidates would be for example be secret service agencies, law enforcement or "homeland security" agencies in western countries, RIAA/MPAA in pursuit of their quest to exercise their desire to jam and DoS peer-to-peer file sharing networks, the Chinese government, Taiwanese government (they may lots of equipment right) and so on). a. Who needs to worry -- who will be targetted? Who needs to worry about this depends on how overt third-party ownership of these keys is, and hence the pool of people who would likely be targetted. If it's very covert, it would only be used plausibly deniably and only for Nat Sec / Homeland Security purposes. It if becomse overt over time -- a publicly acknowledged, but supposedly court controlled affair like Clipper, or even more widely desired by a wide-range of entities for example: keys made available to RIAA / MPAA so they can do the hacking they have been pushing for -- well then we all need to worry. To analyse the answer to question 1, we first need to think about question 2: 2. What kinds of TCPA/Palladium integrity depending "trusted" applications are likely to be built? Given the powerful (though balance of control changing) new remotely attestable security features provided by TCPA/Palladium, all kinds of remote services become possible, for example (though all to the extent of hardware tamper-resistance and belief that your attacker doesn't have access to a hardware endorsement CA private key): - general Application Service Providers (ASPs) that you don't have to trust to read your data - less traceable peer-to-peer applications - DRM applications that make a general purpose computer secure against BORA (Break Once Run Anywhere), though of course not secure against ROCA (Rip Once Copy Everywhere) -- which will surely continue to happen with ripping shifting to hardware hackers. - general purpose unreadable sandboxes to run general purpose CPU-for-rent computing farms for hire, where the sender knows you can't read his code, you can't read his input data, or his output data, or tamper with the computation. - file-sharing while robustly hiding knowledge and traceability of content even to the node serving it -- previously research question, now easy coding problem with efficient - anonymous remailers where you have more assurance that a given node is not logging and analysing the traffic being mixed by it But of course all of these distributed applications, positive and negative (depending on your view point), are limited in their assurance of their non-cryptographically assured aspects: - to the tamper resistance of the device - to the extent of the users confidence that an entity hostile to them doesn't have the endorsement CA's private key for the respective remote servers implementing the network application they are relying on and a follow-on question to question 2: 3. Will any software companies still aim for cryptographic assurance? (cryptographic assurance means you don't need to trust someone not to reverse engineer the application -- ie you can't read the data because it is encrypted with a key derived from a password that is only stored in the users head). The extended platform allows you to build new classes of applications which aren't currently buildable to cryptographic levels of assurance. eg. It allows general purpose policies to be built just by writing policy code that sits in a Trusted Agent code compartment, without having to figure out how to do split-trust (a la mixmaster chaining), or forward-secrecy or secret-sharing or any of the other funky stuff; you can just implement some policy code and it becomes so. The danger is people will use it to build applications with squishy interiors, with no cryptographic assurance. Forward-secrecy implemented only by a policy in a Trusted Agent that sets a time-limit on access. Anonymity but only in the sense that you trust the hardware isn't tampered with, etc etc. It will be really tempting because: - it's much easier: network distributed crypto protocols are relatively complex - you can build things you can't otherwise build, the are currently unsolved problems with distributed crypto protocols - even where good crypto protocols exist, people will defend not using them by claims to paranoia: "What you think the NSA has tampered with your CPU?", or just laziness, cost of implementation etc So in short probably mostly the answer will be "No", people won't still aim for cryptographic assurance. And so a big networked world of distributed applications with a very squishy and insecure interior inside the closed world will be built. The new application spaces squishy interior -- like a corporate firewall with poor to no internal security -- could be ok if you could be sure the firewall is 100% guaranteed reliable. TCPA/Palladium proponents are effectively claiming it be an air-gap grade firewall guarding the distributed closed world application spaces squishy interior. But there is a problem: there are master keys by-passing all that -- the endorsement CA's private keys. 4. What coming political battles will result? a. If TCPA/Palladium systems get built -- and it may be politically unstoppable given the power of the distributed security paradigm it opens up -- then the battle of the coming decades will center around control of access to that squishy interior. The keys that control access to the closed world are the endoresment CA private keys. b. You will see many clipper like attempts by governments attempting to make policies surrounding conditional access to that closed world: - law enforcement access to the endorsement private CA keys controlling access, so they can setup sting operations, demand that ISPs and ASPs collaborate with virtualized versions of network services so they can trace things - NSA designed protocols to allow such things, black box mediated, court order approved, split database access to hardware manufacturers private keys c. As b. progresses RIAA/MPAA will chime in protesting that: - Kazaa2 is distributing 10 exabytes a day of ripped recent release content not based on BORA (which is now somewhat harder), but on ROCA (Rip Once Copy Anywhere) as the content rippers move into hardware hacking territory - the RIAA/MPAA can't hack, spoof or jam kazaa2 with bogus content because cypherpunks have fixed the protocols using WoT, certified content, and other crypto-fu so they can't even observe who's downloading what or who's serving what - and therefore they also demand access to the closed world so they can exert their recent legal rights to hack and DDoS the file sharing networks d. Unauthorised access to the closed environment (by hacking your own hardware) will become illegal with DMCA like restrictions (if it wouldn't already be where some relation to copyright could be drawn). e. Software companies, and OS vendors will follow Microsoft's current lead into an unholy battle with highlights such as: - undocumented APIs to gain advantage over competitors, not only hardware hacking required to discover APIs, but attestation to ensure only those companies who have licensed the right to use the API can use it - incompatible file formats to lock out competition with hardware tamper resistance levels of assurance, even file formats that must have certified documents for applications to open them, so even if you had the spec you couldn't be compatible - copyright protection with software encrypted for the CPU, so you can't even audit the static code - software renting models again enforced by hardware - whole collection of 2nd generation IP "innovations" which will be built on top of such things - charge per person you share file in a given document format; - charge per format conversion f. Lucky's Documentat Revocation lists to allow governments, companies etc to to some extent after the fact control distribution of data g. Increasingly minute enforcement of repressive levels of IP tracking, and arbitrarily user hostile, fair-use eroding document viewing and use policies 5. What could be done to protect the user? a. implement cryptographic assurance inside the closed space where possible -- that way if you are targetted by someone able to get inside it you still have the same protection as now. b. use web-of-trust techniques to provide an overlay of trust on the endorsement trust. ie users endorse their own machines to say "this is my machine" this implies that either: - it's not tampered with (presuming the user himself was not a target of some attack or investigation) - or the only tamperer is the certifying user web-of-trust overlaid on the hardware endorsement helps as: - This makes the endorsement keys less useful in a covertly obtained endorsement CA private key scenario - Even if there are court authorized law enforcement access to endorsement CA private keys, or RIAA/MPAA access to endorsement CA private keys you can to the extent of your connectivity in the web of trust, better avoid using the services of rogue agents inside the closed space. c. Demand ability to audit information in-flows into trusted agents where there are unauditable out-flows; demand that this is implemented in a way which allows code under user control to audit d. Demand the ability to audit information out-flows, where there are unauditable in-flows or sensitive user data processed by the application; similarly demand that this is implemented in a way which allows code under user control to audit e. Demand cryptographically assured anonymity protection so that there are no "trusted third parties" who can link your network usage and identify you. e. Other ideas? (Other than to lobby to prevent the building or use this model). Adam -- http://www.cypherspace.org/adam/ [1] "FBI Bugs Keyboard of PGP-Using Alleged Mafioso", 6 Dec 2000, slashdot http://slashdot.org/yro/00/12/06/0255234.shtml --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From schear at lvcm.com Fri Aug 9 23:40:28 2002 From: schear at lvcm.com (Steve Schear) Date: Fri, 09 Aug 2002 23:40:28 -0700 Subject: Thanks, Lucky, for helping to kill gnutella In-Reply-To: Message-ID: <5.1.0.14.2.20020809231553.05d53a28@pop3.lvcm.com> At 08:25 PM 8/9/2002 -0700, AARG!Anonymous wrote: >As far as Freenet and MojoNation, we all know that the latter shut down, >probably in part because the attempted traffic-control mechanisms made >the whole network so unwieldy that it never worked. I worked there and respectfully disagree. MN never gained a foothold first and foremost because of the frequent join/leave problem. This, in turn, was a direct result of insufficient resources to address automated publication of .mp3 header data. The inability of the client SW to automatically create the header data and publish directories full of .mp3 files at each client meant users had to expend more much effort to make available their content than file-oriented P2P alternatives. This hurdle, when combined with data retention problems related to other MN deficiencies, assured that little content was available for DL. New users simply abandoned the effort when they came up empty handed. The introducer problem could probably have been solved using Usenet postings. The nature of Usenet meant it could scale and was fairly resistant legal and technical attacks. Usenet might also have served for a fallback block store but neither approach was ever carefully considered, again due to resource limitations. >At least in part >this was also due to malicious clients, according to the analysis at >http://www.cs.rice.edu/Conferences/IPTPS02/188.pdf. My experience is that the malicious client problem was not a major issue. [much deleted] >Lucky can provide all this misinformation, all under the pretence, >mind you, that this *is* TCPA. He was educating the audience, mostly >people who were completely unfamiliar with the system other than some >vague rumors. And this is what he presents, a tissue of lies and >fabrications and unfounded sensationalism. At Lucky's Defcon talk he stated that he was a participant in the development of TCPA. Can't clearly recall in what capacity he served but me recollection is it was as a reviewer. steve From remailer at remailer.xganon.com Fri Aug 9 22:10:21 2002 From: remailer at remailer.xganon.com (Anonymous) Date: Sat, 10 Aug 2002 00:10:21 -0500 Subject: Signing as one member of a set of keys Message-ID: Here is the signature block from the "ring signature" program which got truncated. I'll try sending it through a few different anon remailers until it gets through. Replace the lines from the earlier posting starting with the "END PGP PUBLIC KEY BLOCK" line. -----END PGP PUBLIC KEY BLOCK----- ++multisig v1.0 pEsBwalpBRxWyJR8tkYm6qR27UW9IT6Vg8SlOHIsEkk04RJvoSy0cy4ISFCq6vDX 5ub6c+MYi/UoyR6tI7oqpMu1abcXWm2DkfDiCsD6jQddVkiiYdG7Bih8JWdWmp5l AgzqUoz14671/ezmWSrPNsTNKV96+ZLEanZsqfkpQcnZpLkWVpJzQFe0VgDQ64b2 +e2efrbknLFq0FTdX7Sh3qzAfzNYYgADmeOxDoTm9sb6T0fULf1P7mjiN2LZXuEW m/8QvksaQi9KGa/0xN2m0heNtS1cfsTa+NJz8XYyG/tnMy7+mvI3c3lrnz+6Dpyp pbNwaX+12VcqtfNec9faoq8RJgFxmSO/ZfMOGM8cFBQ75ZOaoBJP5ObHZ/63FFh5 Wh5GzwJjQs0vLwpM3iF6G+IixEqAQYisUdCopP1wXCLgltDM6l7jRlXxNDj0AXQ1 eQJolo32vemcy8Z8GAn5tpQHmJwpdzZpboWRQY53pD4mVnEMN4GBC1mhbbI2z+Oh lPglqmmy3p4D+psNU1rlNv6yH/L0PgcuW7taVpbopjl4HLuJdWcKHJlXish3D/jb eoQ856fYFZ/omGiO9x1D0BsnGFLZVWob4OIZRzO/Pc49VIhFy5NsV2zuozStId89 mAHWyZ59wWUg9UrkasOAmSd8bkGK4PxM4tWhJxoyGVHZaBHXdBl4V2H0+szRibUC OZpY9V0rkrLE5U8gmOgg/faFeInJJ09SCxtgptV8MLdzsoHXRlN1YA0Qy5NBwmuL EaGJ/iq8OLNKbVpMNqTFHccCjcUW2smduan+I9MMnNbg74dttuw1H2jAx9jbnYP4 4Nc4+TVlNAfQr3M7c4L+lfDYXSYCzN5uOHvGqOkg2+G5KCcPsaPwi2C2lC8eItti uVDqlvDylgVHaZFQIGepZ5VcDlvxYjbi8qFi9uOutfAXMfmVfoPsPPGkkigX3ypZ FLInE/vu4i3BzwYgxU0SMnv9g2R5+GhE8gqQ1x2knOo/QZ4DJnMaW4wt6wwRZPWQ YJyykW0lTD/LkmOqIeVWleXWBW8vlJ20hCP6RKMgE2tnrQBYtFwZlNW2nFPZmOqX HDvF92xHmCHRbpu/MjrxSs8ByAs4cyN77w8f1Gxph9Xcd5iKjdXmJTAs30AzE4uS UjxkAakiTtzjodYvY+fOl1ZYA2/OEGDfC73Xdib9gwD9JWEQz8sjelKIEPdqyvNH BjHTDH0VZeu3IxUFh37w2fIEehL8WrXvCoCMFnd1/bnn/qI/STXgg6as579/yBIJ nJra7Ceru4q4wUssK79T6SdOM6wcvVg96ub4UOTaPO4wYhhadCbLFpl3tPfTLceb */ From seth.johnson at realmeasures.dyndns.org Fri Aug 9 21:43:01 2002 From: seth.johnson at realmeasures.dyndns.org (Seth Johnson) Date: Sat, 10 Aug 2002 00:43:01 -0400 Subject: Thanks, Lucky, for helping to kill gnutella References: <8c25bf764b14de9e2d3d9cd24a6d49fb@aarg.net> Message-ID: <3D5499D5.6D8F8519@RealMeasures.dyndns.org> TCPA and Palladium are content control for the masses. They are an attempt to encourage the public to confuse the public interest issues of content control with the private interest issues of privacy and security. Seth Johnson -- [CC] Counter-copyright: http://cyber.law.harvard.edu/cc/cc.html I reserve no rights restricting copying, modification or distribution of this incidentally recorded communication. Original authorship should be attributed reasonably, but only so far as such an expectation might hold for usual practice in ordinary social discourse to which one holds no claim of exclusive rights. From eugen at leitl.org Fri Aug 9 15:55:21 2002 From: eugen at leitl.org (Eugen Leitl) Date: Sat, 10 Aug 2002 00:55:21 +0200 (CEST) Subject: AARG and eugene are net.loons-why signatures of binaries always change. In-Reply-To: <20020809090110.A24161@shannon.permutation.net> Message-ID: You're being quite creative with alternative spelling and punctuation. However, if you think that provides sustainable stealth cover against a competent attacker (TLA agencies must by now be really good with linguistic forensics) you're fooling yourself. For executable binary verification it is obviously necessary to use compilers/linkers which don't write crap into the binary. Speaking of which, given the size of the code blob one could as well use handcrafted assembly. Also, using a standartized build environment is not exactly rocket science, since one can checksum ISO images, too. Platinum Group Linux would be a good name for the distro. On Fri, 9 Aug 2002, cyphrpnk wrote: > Hi all, > Its obvious that some of us here are developers and still others > have never typed make or gcc in their lives. > > > -v and -V options given to various forms of ld caused the embeddment of > version information in the binary(Sunpro does this also, AND early versions > of MSC allowed embeddment of version information also.) > The fact that most environments dont link -Bstatic and instead link > -Bdynamic means that every time you attempt to produce a binary from > 2 different systems that the dynamic link information will > be different checkout link.h link_elf.h link_aout.h in /usr/include > > > in addition MOST modern developement environments include a date field > when compiled and linked in the binary > > > > sheesh > a cypherpunk > BTW. AARG and eugene are idiots nyah nyah nyah!! From remailer at remailer.xganon.com Fri Aug 9 23:10:19 2002 From: remailer at remailer.xganon.com (Anonymous) Date: Sat, 10 Aug 2002 01:10:19 -0500 Subject: Signing as one member of a set of keys Message-ID: <364bf85b104f607ec4c8ca3ce61ba2c8@remailer.xganon.com> Here are the perl scripts I cobbled together to put the ring signature at the end of the file, after a separator. I called the executable program from the earlier C source code "ringsig". I call these ringver and ringsign. I'm no perl hacker so these could undoubtedly be greatly improved. ringver === #! /usr/bin/perl # Usage: $0 pubkeyfile < filetoverify die("Usage: ringver pubkeyfile < filetoverify") if @ARGV != 1; $outfile = "/tmp/sigdata$$"; $sigfile = "/tmp/sigfile$$"; $separator = " \\+\\+multisig v1\\.0"; $pubfile=$ARGV[0]; -r $pubfile || die ("Error reading $pubfile"); open (OUTFILE, ">".$outfile) || die ("Unable to open $outfile for output"); open (SIGFILE, ">".$sigfile) || die ("Unable to open $sigfile for output"); # Skip leading blank lines on input file $_= while /^$/; # Save lines to outfile until separator print OUTFILE $_; while () { last if /$separator/; print OUTFILE $_; } die ("No signature found in input file") if !$_; # Save remaining lines ot sigfile print SIGFILE while ; close INFILE; close OUTFILE; close SIGFILE; open (SIG, "./ringsig -v $outfile $pubfile < $sigfile |") || die ("Error running verify program"); # Print output from program print while ; close SIG; unlink($sigfile); unlink($outfile); exit($?); ringsign === #! /usr/bin/perl # Usage: $0 filetosign pubkeyfile privkeyfile die("Usage: ringsign filetosign pubkeyfile privkeyfile > outfile") if @ARGV < 3; $outfile = "/tmp/sigdata$$"; $separator = " ++multisig v1.0"; open(INFILE, $ARGV[0]) || die ("Unable to open $ARGV[0] for input"); $pubfile=$ARGV[1]; $secfile=$ARGV[2]; -r $pubfile || die ("Error reading $pubfile"); -r $secfile || die ("Error reading $secfile"); open (OUTFILE, ">".$outfile) || die ("Unable to open $outfile for output"); # Skip leading blank lines on input file $_= while /^$/; # Save lines to outfile print OUTFILE $_; print OUTFILE $_ while ; close INFILE; close OUTFILE; # Re-open infile open(INFILE, $ARGV[0]) || die ("Unable to open $ARGV[0] for input"); open (SIG, "./ringsig -s $outfile $pubfile $secfile|") || die ("Error signing"); @sigs = ; close SIG; die ("Error from signature program") if ($?); # Output infile, separator, sig print while ; print $separator . "\n"; print @sigs; unlink($outfile); From swpteam at hotmail.com Sat Aug 10 00:53:18 2002 From: swpteam at hotmail.com (steve) Date: Sat, 10 Aug 2002 02:53:18 -0500 Subject: FREE REPORT: Making over half million dollars every 4 to 5 months!!! Message-ID: <200208100753.g7A7rIpU011999@ak47.algebra.com> Steven W. Pratt Ph: 610-842-6318 233 Brandywine Rd Collegeville, PA 19426 USING THE POWER OF INTERNET, READ THE FOLLOWING MESSAGE CAREFULLY AS SEEN ON NATIONAL TV: ''Making over half million dollars every 4 to 5 months from You're home for an investment of only $25 U.S. or CANADIAN Dollars expense one time'' THANKS TO THE COMPUTER AGE AND THE INTERNET! ================================================= BE A MILLIONAIRE LIKE OTHERS WITHIN A YEAR!!! Before you say ''Bull'', please read the following. This is the letter you have been hearing about on the news lately. Due to the popularity of this letter on the Internet, a national weekly news program recently devoted an entire show to the investigation of this program described below, to see if it really can make people money. The show also investigated whether or not the program was legal. Their findings proved once and for all that there are ''absolutely NO laws prohibiting the participation in the program and if people can follow the simple instructions, they are bound to make some mega bucks with only $25 out of pocket cost''. DUE TO THE RECENT INCREASE OF POPULARITY & RESPECT THIS PROGRAM HAS ATTAINED; IT IS CURRENTLY WORKING BETTER THAN EVER. This is what one had to say: ''Thanks to this profitable opportunity. I was approached many times before but each time I passed on it. I am so glad I finally joined just to see what one could expect in return for the minimal effort and money required. To my astonishment, I received total $ 610,470.00 in 21 weeks, with money still coming in''. Pam Hedland, Fort Lee, New Jersey. --------------------------------------------------- ----- **** PRINT THIS NOW FOR YOUR FUTURE REFERENCE **** $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ $$$$ If you would like to make at least $500,000 every 4 to 5 months easily and comfortably, please read the following...THEN READ IT AGAIN and AGAIN!!! $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ $$$$ FOLLOW THE SIMPLE INSTRUCTION BELOW AND YOUR FINANCIAL DREAMS WILL COME TRUE, GUARANTEED! INSTRUCTIONS: **** Order all 5 reports shown on the list below. **** For each report, send $5 CASH, THE NAME & NUMBER OF THE REPORT YOU ARE ORDERING and YOUR E- MAIL ADDRESS to the person whose name appears ON THAT LIST next to the report. MAKE SURE YOUR RETURN ADDRESS IS ON YOUR ENVELOPE TOP LEFT CORNER in case of any mail problems. **** When you place your order, make sure you order each of the 5 reports. You will need all 5 reports so that you can save them on your computer and resell them. YOUR TOTAL COST $5 X 5 = $25.00. **** Within a few days you will receive, via e- mail, each of the 5 reports from these 5 different individuals. Save them on your computer so they will be accessible for you to send to the 1,000's of people who will order them from you. Also make a floppy of these reports and keep it on your desk in case something happen to your computer. **** IMPORTANT __ DO NOT alter the names of the people who are listed next to each REPORT, or their sequence on the list, in any way other than what is instructed below in step '' 1 through 6 '' or you will loose out on majority of your profits. Once you understand the way this works, you will also see how it does not work if you change it. Remember, this method has been tested, and if you alter, it will NOT work!!! People have tried to put their friends / relatives names on all five thinking they could get all the money. But it does not work this way. Believe us, we all have tried to be greedy and then nothing happened. So Do Not try to change anything other than what is instructed. Because if you do, it will not work for you. Remember, Honesty reaps the reward!!! 1.... After you have ordered all 5 reports, take this advertisement and REMOVE the name & address of the person in REPORT #5. This person has made it through the cycle and is no doubt counting their fortune. 2. Move the name & address in REPORT #4 down TO REPORT #5 3. Move the name & address in REPORT #3 down TO REPORT #4 4. Move the name & address in REPORT #2 down TO REPORT #3 5. Move the name & address in REPORT #1 down TO REPORT #2 6. Insert YOUR name & address in the REPORT #1 Position. PLEASE MAKE SURE you copy every name & address ACCURATELY! ================================================= **** Take this entire letter, with the modified list of names, and save it on your computer. DO NOT MAKE ANY OTHER CHANGES. Save this on a disk as well just in case if you loose any data. **** To assist you with marketing your business on the Internet, the 5 reports you purchase will provide you with invaluable marketing information, which includes how to send bulk e-mails legally, where to find thousands of free classified ads and much more. There are 2 Primary methods to get this venture going: METHOD #1: BY SENDING BULK E-MAIL LEGALLY ================================================= Let's say that you decide to start small, just to see how it goes, and we will assume you and those involved send out only 5,000 e- mails each. Let's also assume that the mailing receive only a 0.2% response (the response could be much better but lets just say it is only 0.2%. Also many people will send out hundreds of thousands e-mails instead of only 5,000 each). Continuing with this example, you send out only 5,000 e- Mails. With a 0.2% response, that is only 10 orders for REPORT # 1. Those 10 people responded by sending out 5,000 e-mail each for a total of 50,000. Out of those 50,000 e-mails only 0.2% responded with orders. That's = 100 people responded and ordered REPORT # 2. Those 100 people mail out 5,000 e-mails each for a total of 500,000 e-mails. The 0.2% response to that is 1000 orders for REPORT # 3. Those 1000 people send out 5,000 e- mails each for a total of 5 million E-mails sent out. The 0.2% response to that is 10,000 orders for REPORT # 4. Those 10,000 people send out 5,000 e- mails each for a total of 50,000,000 (50 million) e-mails. The 0.2% response to that is 100,000 orders for REPORT # 5 THAT'S 100,000 ORDERS TIMES $5 EACH = $500,000.00 (half million). Your total income in this example is: 1...$50 + 2...$500 + 3...$5,000 + 4...$50,000 + 5...$500,000 Grand Total = $555,550.00 NUMBERS DO NOT LIE. GET A PENCIL & PAPER AND FIGURE OUT THE WORST POSSIBLE RESPONSES AND NO MATTER HOW YOU CALCULATE IT, YOU WILL STILL MAKE A LOT OF MONEY! --------------------------------------------------- -------- REMEMBER FRIEND, THIS IS ASSUMING ONLY 10 PEOPLE ORDERING OUT OF 5,000 YOU MAILED TO. Dare to think for a moment what would happen if everyone, or half or even one 4th of those people mailed 100,000 e-mails each or more? There are over 150 million people on the internet worldwide and counting. Believe me, any people will do just that, and more! _________________ AVAILABLE REPORTS __________________ ORDER EACH REPORT BY ITS NUMBER & NAME ONLY. Notes: Always send $5 cash (U.S. CURRENCY) or Canadian for each REPORT. Checks NOT accepted. Make sure the cash is concealed by wrapping it in at least 2 sheets of paper. On one of those Sheets of paper write the NUMBER & the NAME of the REPORT you are ordering, YOUR E-MAIL ADDRESS and your name and postal address. PLACE YOUR ORDER FOR THESE REPORTS NOW: ================================================= REPORT #1 ''The Insider's Guide to Advertising for Free on the Net'' Order REPORT #1 from: Steven Pratt 233 Brandywine Rd Collegeville, PA 19426 __ _________________________________________________ REPORT #2 ''The Insider's Guide to Sending Bulk e- mail on the Net'' Hubert Fulkerson 402 East Las Palmaritas Drive Phoenix, AZ 85020-3436 _________________________________________________ REPORT #3 ''The Secret to Multilevel marketing on the Net'' Order REPORT #3 from: Glen Kelly 890 Ravenwood Ct. Biloxi, Ms. 39532 ___________________________________________________ REPORT #4 ''How to become a millionaire utilizing MLM & the Net'' Order REPORT #4 from: C Shaw P.O. Box 468 Schomberg, Ontario Canada LOG ITO ___________________________________________________ REPORT #5 ''HOW TO SEND 1 MILLION E-MAILS FOR FREE'' Order REPORT #5 from: Elaine Rix 138 Dundas Street, West, #243 Toronto, Ontario Canada M5G 1C3 _________________________________________ $$$$$$$$$$$$ YOUR SUCCESS GUIDELINES $$$$$$$$$$$$$$ Follow these guidelines to guarantee your success: *** If you do not receive at least 10 orders for REPORT #1 within 2 weeks, continue sending e-mails until you do. *** After you have received 10 orders, 2 to 3 weeks after that you should receive 100 orders or more for REPORT #2. If you did not, continue advertising or sending e-mails until you do. *** Once you have received 100 or more orders for REPORT #2, YOU CAN RELAX, because the system is already working for you and the cash will continue to roll in! THIS IS IMPORTANT TO REMEMBER: Every time your name is moved down on the list, you are placed in front of a Different REPORT. You can KEEP TRACK of your PROGRESS by watching which REPORT people are ordering from you. IF YOU WANT TO GENERATE MORE INCOME SEND ANOTHER BATCH OF E-MAILS AND START THE WHOLE PROCESS AGAIN. There is NO LIMIT to the income you can generate from this business!!! ___________________________________________________ FOLLOWING IS A NOTE FROM THE ORIGINATOR OF THIS PROGRAM: "You have just received information that can give you financial freedom for the rest of your life, with NO RISK And JUST A LITTLE BIT OF EFFORT. You can make more money in the next few weeks and months than you have ever imagined. Follow the program EXACTLY AS INSTRUCTED. Do Not change it in any way. It works exceedingly well as it is now. Remember to e-mail a copy of this exciting REPORT after you have put your name and address in REPORT #1 and moved others to #2 ..........#5 as instructed above. One of the people you send this to may send out 100,000 or more e-mails and your name will be on everyone of them. Remember though, the more you send out the more potential customers you will reach. So my friend, I have given you the ideas, information, materials and opportunity to become financially independent. IT IS UP TO YOU NOW! **************** MORE TESTIMONIALS ***************** --------------------------------------------------- -------- ''Not being the gambling type, it took me several weeks to make up my mind to participate in this plan. But conservative that I am, I decided that the initial investment was so little that there was just no way that I wouldn't get enough orders to at least get my money back''. ''I was surprised when I found my medium size post office box crammed with orders. I made $319,210.00 in the first 12 weeks. The nice thing about this deal is that it does not matter where people live. There simply isn't a better investment with a faster return and so big''. Dan Sondstrom, Alberta, Canada --------------------------------------------------- -------- ''I had received this program before. I deleted it, but later I wondered if I should have given it a try. Of course, I had no idea who to contact to get another copy, so I had to wait until I was e-mailed again by someone else.........11 months passed then it luckily came again...... I did not delete this one! I made more than $490,000 on my first try and all the money came within 22 weeks''. Susan De Suza, New York, N.Y. --------------------------------------------------- -------- ''It really is a great opportunity to make relatively easy money with little cost to you. I followed the simple instructions carefully and within 10 days the money started to come in. My first month I made $ 20, 560.00 and by the end of third month my total cash count was $ 362,840.00. Life is beautiful, Thanx to internet''. Fred Dellaca, Westport, New Zealand --------------------------------------------------- -------- ORDER YOUR REPORTS TODAY AND GET STARTED ON YOUR ROAD TO FINANCIAL FREEDOM! ================================================== If you have any questions of the legality of this program, contact the Office of Associate Director for Marketing Practices, Federal Trade Commission, Bureau of Consumer Protection, Washington, D.C. /////////////////////////////////////////////////// //////// ONE TIME MAILING, NO NEED TO REMOVE /////////////////////////////////////////////////// //////// This message is sent in compliance of the proposed bill SECTION 301. per Section 301, Paragraph (a)(2)(C) of S. 1618. Further transmission to you by the sender of this e-mail may be stopped at no cost to you by sending a reply to youcansucceed at hotmail.com Steven W. Pratt Ph: 610-842-6318 (Please call if you have questions or concerns) 233 Brandywine Rd Collegeville, PA 19426 This message is not intended for residents in the State of Washington, screening of addresses has been done to the best of our technical ability. From gnu at toad.com Sat Aug 10 04:02:36 2002 From: gnu at toad.com (John Gilmore) Date: Sat, 10 Aug 2002 04:02:36 -0700 Subject: responding to claims about TCPA In-Reply-To: Message-ID: <200208101102.g7AB2aq30982@new.toad.com> > I asked Eric Murray, who knows something about TCPA, what he thought > of some of the more ridiculous claims in Ross Anderson's FAQ (like the > SNRL), and he didn't respond. I believe it is because he is unwilling > to publicly take a position in opposition to such a famous and respected > figure. Many of the people who "know something about TCPA" are constrained by NDA's with Intel. Perhaps that is Eric's problem -- I don't know. (I have advised Intel about its security and privacy initiatives, under a modified NDA, for a few years now. Ross Anderson has also. Dave Farber has also. It was a win-win: I could hear about things early enough to have a shot at convincing Intel to do the right things according to my principles; they could get criticized privately rather than publicly, if they actually corrected the criticized problems before publicly announcing. They consult me less than they used to, probably because I told them too many things they didn't want to hear.) One of the things I told them years ago was that they should draw clean lines between things that are designed to protect YOU, the computer owner, from third parties; versus things that are designed to protect THIRD PARTIES from you, the computer owner. This is so consumers can accept the first category and reject the second, which, if well-informed, they will do. If it's all a mishmash, then consumers will have to reject all of it, and Intel can't even improve the security of their machines FOR THE OWNER, because of their history of "security" projects that work against the buyer's interest, such as the Pentium serial number and HDCP. TCPA began in that "protect third parties from the owner" category, and is apparently still there today. You won't find that out by reading Intel's modern public literature on TCPA, though; it doesn't admit to being designed for, or even useful for, DRM. My guess is that they took my suggestion as marketing advice rather than as a design separation issue. "Pitch all your protect-third-party products as if they are protect-the-owner products" was the opposite of what I suggested, but it's the course they (and the rest of the DRM industry) are on. E.g. see the July 2002 TCPA faq at: http://www.trustedcomputing.org/docs/TPM_QA_071802.pdf 3. Is the real "goal" of TCPA to design a TPM to act as a DRM or Content Protection device? No. The TCPA wants to increase the trust ... [blah blah blah] I believe that "No" is a direct lie. Intel has removed the first public version 0.90 of the TCPA spec from their web site, but I have copies, and many of the examples in the mention DRM, e.g.: http://www.trustedcomputing.org/docs/TCPA_first_WP.pdf (still there) This TCPA white paper says that the goal is "ubiquity". Another way to say that is monopoly. The idea is to force any other choices out of the market, except the ones that the movie & record companies want. The first "scenario" (PDF page 7) states: "For example, before making content available to a subscriber, it is likely that a service provider will need to know that the remote platform is trustworthy." http://www.trustedpc.org/home/pdf/spec0818.pdf (gone now) Even this 200-page TCPA-0.90 specification, which is carefully written to be obfuscatory and misleading, leaks such gems as: "These features encourage third parties to grant access to by the platform to information that would otherwise be denied to the platform" (page 14). "The 'protected store' feature...can hold and manipulate confidential data, and will allow the release or use of that data only in the presence of a particular combination of access rghts and software environment. ... Applications that might benefit include ... delivery of digital content (such as movies and songs)." (page 15). Of course, they can't help writing in the DRM mindset regardless of their intent to confuse us. In that July 2002 FAQ again: 9. Does TCPA certify applications and OS's that utilize TPMs? No. The TCPA has no plans to create a "certifying authority" to certify OS's or applications as "trusted". The trust model the TCPA promotes for the PC is: 1) the owner runs whatever OS or applications they want; 2) The TPM assures reliable reporting of the state of the platform; and 3) the two parties engaged in the transaction determine if the other platform is trusted for the intended transaction. "The transaction"? What transaction? They were talking about the owner getting reliable reporting on the security of their applications and OS's and -- uh -- oh yeah, buying music or video over the Internet. Part of their misleading technique has apparently been to present no clear layman's explanations of the actual workings of the technology. There's a huge gap between the appealing marketing sound bites -- or FAQ lies -- and the deliberately dry and uneducational 400-page technical specs. My own judgement is that this is probably deliberate, since if the public had an accurate 20-page document that explained how this stuff works and what it is good for, they would reject the tech instantly. Perhaps we in the community should write such a document. Lucky and Adam Back seem to be working towards it. The similar document about key-escrow (that CDT published after assembling a panel of experts including me, Whit, and Matt Blaze) was quite useful in explaining to lay people and Congressmen what was wrong with it. NSA/DoJ had trouble countering it, since it was based on the published facts, and they couldn't impugn the credentials of the authors, nor the document's internal reasoning. Intel and Microsoft and anonymous chauvanists can and should criticize such a document if we write one. That will strengthen it by eliminating any faulty reasoning or errors of public facts. But they had better bring forth new exculpating facts if they expect the authors to change their conclusions. They're free to allege that "No current Microsoft products have Document Revocation Lists", but that doesn't undermine the conclusion that their architectures make it easy to secretly implement that feature, anytime they want to. John From shamrock at cypherpunks.to Sat Aug 10 05:05:21 2002 From: shamrock at cypherpunks.to (Lucky Green) Date: Sat, 10 Aug 2002 05:05:21 -0700 Subject: Signing as one member of a set of keys In-Reply-To: Message-ID: <00fd01c24066$34f9c060$6801a8c0@xpserver> Anonymous wrote: > > Here is the signature block from the "ring signature" program > which got truncated. I'll try sending it through a few > different anon remailers until it gets through. Replace the > lines from the earlier posting starting with the "END PGP > PUBLIC KEY BLOCK" line. I seem to still have problems with the signature block. If somebody on this list has a good copy, could you please place it on a web page and publish the URL? If nobody has a good copy, could perhaps Anonymous try a different method of posting, such as uuencoding? Thanks, --Lucky From adam at cypherspace.org Fri Aug 9 21:37:30 2002 From: adam at cypherspace.org (Adam Back) Date: Sat, 10 Aug 2002 05:37:30 +0100 Subject: p2p DoS resistance and network stability (Re: Thanks, Lucky, for helping to kill gnutella) In-Reply-To: ; from remailer@aarg.net on Fri, Aug 09, 2002 at 08:25:40PM -0700 References: Message-ID: <20020810053730.A640918@exeter.ac.uk> On Fri, Aug 09, 2002 at 08:25:40PM -0700, AARG!Anonymous wrote: > Several people have objected to my point about the anti-TCPA efforts of > Lucky and others causing harm to P2P applications like Gnutella. The point that a number of people made is that what is said in the article is not workable: clearly you can't ultimately exclude chosen clients on open computers due to reverse-engineering. (With TCPA/Palladium remote attestation you probably could so exclude competing clients, but this wasn't what was being talked about). The client exclusion plan is also particularly unworkable for gnutella because some of the clients are open-source, and the protocol is (now since original reverse engineering from nullsoft client) also open. With closed-source implementations there is some obfuscation barrier that can be made: Kazaa/Morpheus did succeed in frustrating competing clients due to it's closed protocols and unpublished encryption algorithm. At one point an open source group reverse-engineered the encryption algorithm, and from there the contained kazaa protocols, and built an interoperable open-source client giFT http://gift.sourceforge.net, but then FastTrack promptly changed the unpublished encryption algorithm to another one and then used remote code upgrade ability to "upgrade" all of the clients. Now the open-source group could counter-strike if they had particularly felt motivated to. For example they could (1) reverse-engineer the new unpublished encryption algorithm, and (2) the remote code upgrade, and then (3) do their own forced upgrade to an open encryption algorithm and (4) disable further forced upgrades. (giFT instead after the "ugrade" attack from FastTrack decided to implement their own open protocol "openFT" instead and compete. It also includes a general bridge between different file-sharing networks, in a somewhat gaim like way, if you are familiar with gaim.) > [Freenet and Mojo melt-downs/failures...] Both of these are object > lessons in the difficulties of successful P2P networking in the face > of arbitrary client attacks. I grant you that making simultaneously DoS resistant, scalable and anonymous peer-to-peer networks is a Hard Problem. Even removing the anonymous part it's still a Hard Problem. Note both Freenet and Mojo try to tackle the harder of those two problems and have aspects of publisher and reader anonymity, so that they are doing less well than Kazaa, gnutella and others is partly because they are more ambitious and tackling a harder problem. Also the anonymity aspect possibly makes abuse more likely -- ie the attacker is provided as part of the system tools to obscure his own identity in attacking the system. DoSers of Kazaa or gnutella would likely be more easily identified which is some deterrence. I also agree that the TCPA/Palladium attested closed world computing model could likely more simply address some of these problems. (Lucky slide critique in another post). Adam -- http://www.cypherspace.org/adam/ --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From popkin at nym.alias.net Fri Aug 9 22:50:19 2002 From: popkin at nym.alias.net (D.Popkin) Date: 10 Aug 2002 05:50:19 -0000 Subject: Challenge to David Wagner on TCPA References: Message-ID: <20020810055019.730.qmail@nym.alias.net> -----BEGIN PGP SIGNED MESSAGE----- AARG! Anonymous writes: > Lucky Green wrote: > > Ray wrote: > > > If I buy a lock I expect that by demonstrating ownership I > > > can get a replacement key or have a locksmith legally open it. > > It appears the days when this was true are waning. At least in the PC > > platform domain. > We have had other systems which work like this for a long while. > Many consumer devices are sealed such that if you open them you void > the warranty. This is to your advantage as a consumer; ... There is exactly one person in the world qualified to decide what's to the advantage of that consumer, and it's not AARG! Anonymous. -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: noconv iQBVAwUBPVRO0PPsjZpmLV0BAQEwrQH/eXqkJVmXYmqNtweg6246KMXmCGekK/h6 HNmnd65WeR2A84pJdJFb8jZ2CX6bJ+XrboaDv8klJCo21xTkFxWIuA== =DL2o -----END PGP SIGNATURE----- From jigwig501325503 at hotmail.com Sat Aug 10 04:34:55 2002 From: jigwig501325503 at hotmail.com (Susan) Date: Sat, 10 Aug 2002 07:34:55 -0400 Subject: Cover your butt on the Internet Message-ID: <200208101142.g7ABgqpU024395@ak47.algebra.com> A non-text attachment was scrubbed... Name: not available Type: text/html Size: 2296 bytes Desc: not available URL: From schear at lvcm.com Sat Aug 10 09:06:26 2002 From: schear at lvcm.com (Steve Schear) Date: Sat, 10 Aug 2002 09:06:26 -0700 Subject: responding to claims about TCPA In-Reply-To: <200208101102.g7AB2aq30982@new.toad.com> References: Message-ID: <5.1.0.14.2.20020810085922.045fd480@pop3.lvcm.com> At 04:02 AM 8/10/2002 -0700, John Gilmore wrote: >"The transaction"? What transaction? They were talking about the >owner getting reliable reporting on the security of their applications >and OS's and -- uh -- oh yeah, buying music or video over the Internet. > >Part of their misleading technique has apparently been to present no >clear layman's explanations of the actual workings of the technology. >There's a huge gap between the appealing marketing sound bites -- or >FAQ lies -- and the deliberately dry and uneducational 400-page >technical specs. My own judgement is that this is probably >deliberate, since if the public had an accurate 20-page document that >explained how this stuff works and what it is good for, they would >reject the tech instantly. > >Perhaps we in the community should write such a document. Lucky and >Adam Back seem to be working towards it. The similar document about >key-escrow (that CDT published after assembling a panel of experts >including me, Whit, and Matt Blaze) was quite useful in explaining to >lay people and Congressmen what was wrong with it. NSA/DoJ had >trouble countering it, since it was based on the published facts, and >they couldn't impugn the credentials of the authors, nor the >document's internal reasoning. Indeed. Another item I recall from Lucky's Defcon talk is that (I assume) Intel are back at it when it comes to obfuscated crypto. Like the Pentium RNG before it, the TPCA HW will only expose a whitened version making independent analysis difficult-impossible. steve From eugen at leitl.org Sat Aug 10 00:15:28 2002 From: eugen at leitl.org (Eugen Leitl) Date: Sat, 10 Aug 2002 09:15:28 +0200 (CEST) Subject: Thanks, Lucky, for helping to kill gnutella (fwd) In-Reply-To: Message-ID: I don't try to filter, but to join several sources. Anonymous is an idiot, but at least an intelligent one. I can't leave him out without creating a skewed picture of what is going on. On Fri, 9 Aug 2002, R. A. Hettinga wrote: > At 1:03 AM +0200 on 8/10/02, Some anonymous, and now apparently > innumerate, idiot in my killfile got himself forwarded to Mr. Leitl's > cream of cypherpunks list: From ocaoha at yahoo.com Sat Aug 10 07:24:57 2002 From: ocaoha at yahoo.com (Send) Date: Sat, 10 Aug 2002 09:24:57 -0500 Subject: Responsive Emails, Help with Sending. Message-ID: <200208101424.g7AEOsR10584@waste.minder.net> A non-text attachment was scrubbed... Name: not available Type: text/html Size: 4433 bytes Desc: not available URL: From remailer at aarg.net Sat Aug 10 11:40:14 2002 From: remailer at aarg.net (AARG! Anonymous) Date: Sat, 10 Aug 2002 11:40:14 -0700 Subject: responding to claims about TCPA Message-ID: AARG! wrote: > I asked Eric Murray, who knows something about TCPA, what he thought > of some of the more ridiculous claims in Ross Anderson's FAQ (like the > SNRL), and he didn't respond. I believe it is because he is unwilling > to publicly take a position in opposition to such a famous and respected > figure. John Gilmore replied: > > Many of the people who "know something about TCPA" are constrained > by NDA's with Intel. Perhaps that is Eric's problem -- I don't know. Maybe, but he could reply just based on public information. Despite this he was unable or unwilling to challenge Ross Anderson. > One of the things I told them years ago was that they should draw > clean lines between things that are designed to protect YOU, the > computer owner, from third parties; versus things that are designed to > protect THIRD PARTIES from you, the computer owner. This is so > consumers can accept the first category and reject the second, which, > if well-informed, they will do. I don't agree with this distinction. If I use a smart card chip that has a private key on it that won't come off, is that protecting me from third parties, or vice versa? If I run a TCPA-enhanced Gnutella that keeps the RIAA from participating and easily finding out who is running supernodes (see http://slashdot.org/article.pl?sid=02/08/09/2347245 for the latest crackdown), I benefit, even though the system technically is protecting the data from me. I wrote earlier that if people were honest, trusted computing would not be necessary, because they would keep their promises. Trusted computing allows people to prove to remote users that they will behave honestly. How does that fit into your dichotomy? Society has evolved a myriad mechanisms to allow people to give strong evidence that they will keep their word; without them, trade and commerce would be impossible. By your logic, these protect third parties from you, and hence should be rejected. You would discard the economic foundation for our entire world. > TCPA began in that "protect third parties from the owner" category, > and is apparently still there today. You won't find that out by > reading Intel's modern public literature on TCPA, though; it doesn't > admit to being designed for, or even useful for, DRM. My guess is > that they took my suggestion as marketing advice rather than as a > design separation issue. "Pitch all your protect-third-party products > as if they are protect-the-owner products" was the opposite of what I > suggested, but it's the course they (and the rest of the DRM industry) > are on. E.g. see the July 2002 TCPA faq at: > > http://www.trustedcomputing.org/docs/TPM_QA_071802.pdf > > 3. Is the real "goal" of TCPA to design a TPM to act as a DRM or > Content Protection device? > No. The TCPA wants to increase the trust ... [blah blah blah] > > I believe that "No" is a direct lie. David Grawrock of Intel has an interesting slide presentation on TCPA at http://www.intel.com/design/security/tcpa/slides/index.htm. His slide 3 makes a good point: "All 5 members had very different ideas of what should and should not be added." It's possible that some of the differences in perspective and direction on TCPA are due to the several participants wanting to move in different ways. Some may have been strictly focused on DRM; others may have had a more expansive vision of how trust can benefit all kinds of distributed applications. So it's not clear that you can speak of the "real goal" of TCPA, when there are all these different groups with different ideas. > Intel has removed the first > public version 0.90 of the TCPA spec from their web site, but I have > copies, and many of the examples in the mention DRM, e.g.: > > http://www.trustedcomputing.org/docs/TCPA_first_WP.pdf (still there) > > This TCPA white paper says that the goal is "ubiquity". Another way to > say that is monopoly. Nonsense. The web is ubiquitous, but is not a monopoly. > The idea is to force any other choices out of > the market, except the ones that the movie & record companies want. > The first "scenario" (PDF page 7) states: "For example, before making > content available to a subscriber, it is likely that a service > provider will need to know that the remote platform is trustworthy." That same language is in the Credible Interoperability document presently on the web site at http://www.trustedcomputing.org/docs/Credible_Interoperability_020702.pdf. So I don't think there is necessarily any kind of a cover-up here. > http://www.trustedpc.org/home/pdf/spec0818.pdf (gone now) > > Even this 200-page TCPA-0.90 specification, which is carefully written > to be obfuscatory and misleading, leaks such gems as: "These features > encourage third parties to grant access to by the platform to > information that would otherwise be denied to the platform" (page 14). > "The 'protected store' feature...can hold and manipulate confidential > data, and will allow the release or use of that data only in the > presence of a particular combination of access rghts and software > environment. ... Applications that might benefit include ... delivery > of digital content (such as movies and songs)." (page 15). Yes, DRM can clearly benefit from TCPA/Palladium. And you might be right that they are downplaying that now. But the reason could be that people have focused too much on it as the only purpose for TCPA, just as you have done here. So they are trying to play up the other possibilities so as to get some balance in the discussion. > Of course, they can't help writing in the DRM mindset regardless of > their intent to confuse us. In that July 2002 FAQ again: > > 9. Does TCPA certify applications and OS's that utilize TPMs? > > No. The TCPA has no plans to create a "certifying authority" to > certify OS's or applications as "trusted". The trust model the TCPA > promotes for the PC is: 1) the owner runs whatever OS or > applications they want; 2) The TPM assures reliable reporting of the > state of the platform; and 3) the two parties engaged in the > transaction determine if the other platform is trusted for the > intended transaction. > > "The transaction"? What transaction? They were talking about the > owner getting reliable reporting on the security of their applications > and OS's and -- uh -- oh yeah, buying music or video over the Internet. You are reading an awful lot into this one word "transaction". That doesn't necessarily mean buying digital content. In the abstract sense "transaction" is sometimes used to refer to any exchange of information in a protocol. Even if we do stick to its commercial meaning, it can mean a B2B exchange or any of a wide range of other e-commerce activities. It's not specific to DRM by any means. > Part of their misleading technique has apparently been to present no > clear layman's explanations of the actual workings of the technology. > There's a huge gap between the appealing marketing sound bites -- or > FAQ lies -- and the deliberately dry and uneducational 400-page > technical specs. My own judgement is that this is probably > deliberate, since if the public had an accurate 20-page document that > explained how this stuff works and what it is good for, they would > reject the tech instantly. I agree that the documentation is a problem, but IMO it probably reflects lack of resources rather than obfuscation. I believe that TCPA has many more applications than you and other critics are giving it credit for, and that a good, clear explanation of what it could do would actually gain it support. Do a blog search at daypop.com to see what people are really thinking about TCPA. They read Ross Anderson's TCPA FAQ and take it for gospel. They believe TCPA has serial number revocations and all these other features that are not described in any documents I have seen. A good clear TCPA description could only improve its reputation, which certainly can't go any lower than it is. > Perhaps we in the community should write such a document. Lucky and > Adam Back seem to be working towards it. The similar document about > key-escrow (that CDT published after assembling a panel of experts > including me, Whit, and Matt Blaze) was quite useful in explaining to > lay people and Congressmen what was wrong with it. NSA/DoJ had > trouble countering it, since it was based on the published facts, and > they couldn't impugn the credentials of the authors, nor the > document's internal reasoning. I agree in principle, but I am appalled that you believe that Lucky in particular is heading in the right direction. Adam on the other hand has at least begun to study TCPA and was asking good questions about Palladium before Peter Biddle flew the coop. Will this document say that TCPA is designed to support intelligence agency access to computers? to kill free software? and other such claims from Lucky's presentation? If so, you will only hurt your cause. On the other hand, if you do come up with factual and unbiased information showing both good and bad aspects of TCPA, as I think Adam has come close to doing a few times, then it could be a helpful document. > Intel and Microsoft and anonymous chauvanists can and should criticize > such a document if we write one. That will strengthen it by > eliminating any faulty reasoning or errors of public facts. But they > had better bring forth new exculpating facts if they expect the > authors to change their conclusions. Conclusions should be based on technology. TCPA can be rightly criticized for weak protections of privacy, for ultimately depending on the security of a few central keys and of possibly-weak hardware, and on other technical grounds. But you should not criticize it for supporting DRM, or for making reverse engineering more difficult, because people are under no obligation to give their creative works away for free, or to make it easy for other people to copy their software. Leave your values at home and just present the facts. > They're free to allege that "No > current Microsoft products have Document Revocation Lists", but that > doesn't undermine the conclusion that their architectures make it easy > to secretly implement that feature, anytime they want to. No one has made any such allegation, although presumably it happens to be true. The point in contention is whether TCPA has DRLs! Lucky has claimed this, and Ross claimed the related serial number revocation list, SNRL. Both of them have linked this technology to TCPA/Palladium. Yet as Ross admitted in http://www.chiark.greenend.org.uk/pipermail/ukcrypto/2002-June/019463.html, SNRL's do not need TCPA! In fact, you are perfectly correct that Microsoft architectures would make it easy at any time to implement DRL's or SNRL's. They could do that tomorrow! They don't need TCPA. So why blame TCPA for this feature? TCPA is a technology. You can't take every bad thing Microsoft ever will do and say that TCPA is at fault. I don't even see that TCPA would particularly help with a SNRL, except insofar as TCPA can generally strengthen security in all respects. But remote attestation and sealing, the core TCPA technologies, don't have anything to do with SNRLs. The association of TCPA with SNRLs is a perfect example of the bias and sensationalism which has surrounded the critical appraisals of TCPA. I fully support John's call for a fair and accurate evaluation of this technology by security professionals. But IMO people like Ross Anderson and Lucky Green have disqualified themselves by virtue of their wild and inaccurate public claims. Anyone who says that TCPA has SNRLs is making a political statement, not a technical one. For a credible evaluation, you need people who have no track record of bias with regard to the technology. From mdpopescu at subdimension.com Sat Aug 10 01:49:14 2002 From: mdpopescu at subdimension.com (Marcel Popescu) Date: Sat, 10 Aug 2002 11:49:14 +0300 Subject: It won't happen here (was Re: TCPA/Palladium -- likely future implications) References: <09128eee2dde41bc96cae43940d56ab1@aarg.net> Message-ID: <002a01c2404a$cdd28a40$a36e9cd9@mark> From: "AARG! Anonymous" > Think about it: this one innocuous little box holding the TPME key could > ultimately be the root of trust for the entire world. IMO we should > spare no expense in guarding it and making sure it is used properly. > With enough different interest groups keeping watch, we should be able > to keep it from being used for anything other than its defined purpose. Now I know the general opinion of AARG, and I can't say I much disagree. But I want to comment on something else here, which I find to be a common trait with US citizens: "it can't happen here". The Chinese gov't can do anything they like, because any citizen who would try to "keep watch" would find himself shot. What basic law of the universe says that this can't happen in the US? What exactly will prevent them, 10 years from now, to say "compelling state interests require that we get to do whatever we want with the little box"? You already have an official "gov't against 1st ammendment" policy, from what I've read. Mark From ravage at einstein.ssz.com Sat Aug 10 11:14:11 2002 From: ravage at einstein.ssz.com (Jim Choate) Date: Sat, 10 Aug 2002 13:14:11 -0500 (CDT) Subject: Challenge to David Wagner on TCPA In-Reply-To: <15694.32620.956826.906819@desk.crynwr.com> Message-ID: On Mon, 5 Aug 2002, Russell Nelson wrote: > AARG!Anonymous writes: > > So don't read too much into the fact that a bunch of anonymous postings > > have suddenly started appearing from one particular remailer. For your > > information, I have sent over 400 anonymous messages in the past year > > to cypherpunks, coderpunks, sci.crypt and the cryptography list (35 > > of them on TCPA related topics). > > We have, of course, no way to verify this fact, since your messages > are not cryptographically signed. For someone who claims to be > knowledgable about cryptography, this seems like a suspicious omission. Bullshit Russ, plausable deniability alone justifies such behaviour. Who sent them is irrelevant except to cultists of personality (eg CACL adherents). Base your analysis on facts and experiment. -- ____________________________________________________________________ Conform and be dull......J. Frank Dobie ravage at ssz.com www.ssz.com jchoate at open-forge.org www.open-forge.org -------------------------------------------------------------------- From ray at unipay.nl Sat Aug 10 05:08:21 2002 From: ray at unipay.nl (R. Hirschfeld) Date: Sat, 10 Aug 2002 14:08:21 +0200 Subject: Thanks, Lucky, for helping to kill gnutella In-Reply-To: (message from AARG!Anonymous on Fri, 9 Aug 2002 20:25:40 -0700) References: Message-ID: <200208101208.OAA01653@home.unipay.nl> > Date: Fri, 9 Aug 2002 20:25:40 -0700 > From: AARG!Anonymous > Right, as if my normal style has been so effective. Not one person has > given me the least support in my efforts to explain the truth about TCPA > and Palladium. Hal, I think you were right on when you wrote: But feel free to make whatever assumptions you like about my motives. All I ask is that you respond to my facts. I, for one, support your efforts, even though I don't agree with some of your conclusions. It is clear that you hold a firm opinion that differs from what many others here believe, so in making your points you can expect objections to be raised. You will be more convincing (at least to me) if you continue to respond to these dispassionately on the basis of facts and reasoned opinions (your "normal style"?). Calling Lucky a liar is no more illuminating than others calling you an idiot. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From udhay at pobox.com Sat Aug 10 01:57:58 2002 From: udhay at pobox.com (Udhay Shankar N) Date: Sat, 10 Aug 2002 14:27:58 +0530 Subject: Utilizing Palladium against software piracy In-Reply-To: <001b01c23f29$c959f4c0$6801a8c0@xpserver> Message-ID: <5.1.0.14.2.20020810142459.03016a90@bgl.vsnl.net.in> At 03:20 PM 8/8/02 -0700, Lucky Green wrote: >I, on the other hand, am able to think of several methods in which >Palladium or operating systems built on top of TCPA can be used to >assist in the enforcement of software licenses and the fight against >software piracy. I therefore, over the course of the night, wrote - >and my patent agent filed with the USPTO earlier today - an >application for an US Patent covering numerous methods by which >software applications can be protected against software piracy on a >platform offering the >features that are slated to be provided by Palladium. I can't think why there has been no reaction to this bit yet onlist. Lucky, could you keep us posted on the progress of this effort, and what your intentions are (should it be successful), please? Udhay --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From hothoney_1 at eudoramail.com Fri Aug 9 23:30:52 2002 From: hothoney_1 at eudoramail.com (Wilson Gottlieb) Date: Sat, 10 Aug 2002 14:30:52 +0800 Subject: ibp,Natural Bust - Amazing Breast Enhancing Capsules Message-ID: <200208101256.g7ACuPpU029533@ak47.algebra.com> ================================= Guaranteed to increase, lift and firm your breasts in 60 days or your money back!! 100% herbal and natural. Proven formula since 1996. Increase your bust by 1 to 3 sizes within 30-60 days and be all natural. Click here: http://64.123.160.91:81/li/wangyan/ http://202.101.163.34:81/li/wangyan/ Absolutely no side effects! Be more self confident! Be more comfortable in bed! No more need for a lift or support bra! 100% GUARANTEED AND FROM A NAME YOU KNOW AND TRUST! ************************************************** You are receiving this email as a double opt-in subscriber to the Standard Affiliates Mailing List. To remove yourself from all related email lists, just click here: http://64.123.160.91:81/li/gg/unsubscriber.asp?userid=ibp at pioneernet.net From jamesd at echeque.com Sat Aug 10 14:34:53 2002 From: jamesd at echeque.com (James A. Donald) Date: Sat, 10 Aug 2002 14:34:53 -0700 Subject: Thanks, Lucky, for helping to kill gnutella (fwd) In-Reply-To: References: Message-ID: <3D55248D.8701.15065A8@localhost> -- On 10 Aug 2002 at 16:25, R. A. Hettinga wrote: > [Ob Cypherpunks: Seriously, folks. How clueful can someone be > who clearly doesn't know how to use more than one remailer hop, > as proven by the fact that he's always coming out of the *same* > remailer all the time? The fact that he uses a constant exit remailer does not show that he is using a single hop. I always come out of the same remailer at the end, even though I always use about three randomly selected remailers between myself and the constant exit remailer. I always select the same end remailer to avoid confusing the audience, and I selected a less used exit remailer for the same reason. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG c3w9s36+CG9NnfBCbV9lBPm1GKPtff16r/hBMRj2 2ZIqRKb9UCTCvlWhGVeGUb1eknPEG0ynX12OrTTXM From nelson at crynwr.com Sat Aug 10 12:02:54 2002 From: nelson at crynwr.com (Russell Nelson) Date: Sat, 10 Aug 2002 15:02:54 -0400 (EDT) Subject: Challenge to David Wagner on TCPA In-Reply-To: References: <15694.32620.956826.906819@desk.crynwr.com> Message-ID: <15701.25201.823580.29518@desk.crynwr.com> Jim Choate writes: > > On Mon, 5 Aug 2002, Russell Nelson wrote: > > > AARG!Anonymous writes: > > > So don't read too much into the fact that a bunch of anonymous postings > > > have suddenly started appearing from one particular remailer. For your > > > information, I have sent over 400 anonymous messages in the past year > > > to cypherpunks, coderpunks, sci.crypt and the cryptography list (35 > > > of them on TCPA related topics). > > > > We have, of course, no way to verify this fact, since your messages > > are not cryptographically signed. For someone who claims to be > > knowledgable about cryptography, this seems like a suspicious omission. > > Bullshit Russ, plausable deniability alone justifies such behaviour. > > Who sent them is irrelevant except to cultists of personality (eg CACL > adherents). I agree that it's irrelevant. So why is he trying to argue from authority (always a fallacy anyway) without *even* having any way to prove that he is that authority? Fine, let him desire plausible deniability. I plausibly deny his appeal to (self-)authority as being completely without merit. -- -russ nelson http://russnelson.com | Crynwr sells support for free software | PGPok | businesses persuade 521 Pleasant Valley Rd. | +1 315 268 1925 voice | governments coerce Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From shamrock at cypherpunks.to Sat Aug 10 15:13:49 2002 From: shamrock at cypherpunks.to (Lucky Green) Date: Sat, 10 Aug 2002 15:13:49 -0700 Subject: FAQ: How will Microsoft respond to Lucky's patent application? Message-ID: <012001c240bb$36f28280$6801a8c0@xpserver> I have received numerous questions in conversations and interviews over the last few days as to what I believe Microsoft's response will be to my recent patent application for methods that utilize Palladium and operating systems built on top of TCPA to assist in the fight against software piracy. Rather than continuing to repeat the same answers in conversations, I will simply make the answers available to the lists. Obviously, the following is my personal opinion. I don't profess to speak for Microsoft. Allow me to first outline some principles of how patents work in the U.S. Note that I am not a member of the federal Patent Bar and as such the following is simply my limited understanding of the process and should not be construed as legal advice. For a patent to be valid in the U.S., the idea to be patented must offer utility, be novel, and be non-obvious. I will address the three requirements as I believe they apply to my patent application in turn: Utility: According to the Business Software Alliance's website, in the financial loss to U.S. society due to software piracy in the year 2000 alone amounted to a staggering USD 7.2 billion. I therefore don't believe it can be reasonably argued that methods that may help reduce the level of software piracy lack utility. In particular, I don't anticipate Microsoft to argue that protections against software piracy that assist in the enforcement of licensing agreements lack utility. Novelty: As I mentioned in my earlier post, Peter Biddle, Product Unit Manager for Palladium, very publicly and unambiguously stated during Wednesday's panel at the USENIX Security conference that the Palladium team, despite having been asked by Microsoft's anti-piracy groups for methods by which Palladium could assist in the fight against software piracy, knows of no way in which Palladium can be utilized to assist this end. Peter after the panel asked Brian LaMacchia, a well-known security expert with Microsoft, who was present but not on the panel, if he knew of a way to utilize Palladium to assist in the enforcement of software licenses. Brian did not respond with a solution. (At that time I briefly mentioned to both one of the methods in which I believe Palladium can be used to assist in the fight against software piracy). Peter, who obviously would have been aware of all such methods were they known to the Palladium team, struck me as a forthcoming guy. While I will readily admit that the impression I gained of the person over the two hours I interacted with Peter may carry little weight with those that consider the words Microsoft and honesty to be mutually exclusive, I would like to point out the following: If Microsoft, after so publicly denying any knowledge of ways to use Palladium to assist in the enforcement of application software licenses to an audience representing a veritable who's who of computer security and related public policy (the attendees ranged from Whit Diffie to Pam Samuelson), were to - after my filing for a patent - suddenly assert prior art, neither the attendees, nor the press, nor the public would take kindly to having been so deliberately misled by Microsoft. The likely result would be that Palladium will lose what limited support the initiative may have at this time. I suspect that even somebody that may have a low opinion of Microsoft will agree that Microsoft is not as stupid as to play such a dangerous and losing game. I was asked the next day at USENIX if Microsoft could not simply claim prior art when in fact they had none at the time my invention was made. I would like to reiterate my points made above and add that such claims would need to be filed under oath. Whatever one's opinion of Microsoft may be, I doubt that the salaries paid in Redmond are sufficiently large to goad a mid-level employee into committing perjury. Lastly, it does not matter for the above analysis if any supposed prior art were to be claimed to be created by Microsoft or third parties. It is simply inconceivable that the scientific members of the Palladium team would have been unaware of any such prior art given the their many years on the project and the thorough research they engaged in as evidenced by the lengthy DRM OS patent. If prior art existed, the Palladium team would unquestionably have known about it and thus been able to tell their anti-piracy group and the attendees at USENIX about methods to utilize Palladium as a tool in the fight against software piracy. Since they did not, the reasonable conclusion is that no such prior art exists. Obviousness: In the interest of brevity, I will simply state that if the Palladium team has not thought of such methods in the years they worked the project every day, the methods mentioned in my patent application cannot conceivably be considered obvious. In summary, at this time I am not aware of any grounds on which Microsoft could challenge my patent once/if it will be issued. I therefore currently do not anticipate that Microsoft will challenge the patent. Lastly, I feel obliged to mention that it is quite irrelevant what I, Microsoft, or the subscribers to this list believe to be the case with respect to my patent application. All that matters is what the patent examiner at the USPTO believes. Unless one of the subscribers to this list happens to work as a patent examiner. --Lucky Green --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From remailer at aarg.net Sat Aug 10 15:15:07 2002 From: remailer at aarg.net (AARG!Anonymous) Date: Sat, 10 Aug 2002 15:15:07 -0700 Subject: Seth on TCPA at Defcon/Usenix Message-ID: Seth Schoen of the EFF has a good blog entry about Palladium and TCPA at http://vitanuova.loyalty.org/2002-08-09.html. He attended Lucky's presentation at DEF CON and also sat on the TCPA/Palladium panel at the USENIX Security Symposium. Seth has a very balanced perspective on these issues compared to most people in the community. It makes me proud to be an EFF supporter (in fact I happen to be wearing my EFF T-shirt right now). His description of how the Document Revocation List could work is interesting as well. Basically you would have to connect to a server every time you wanted to read a document, in order to download a key to unlock it. Then if "someone" decided that the document needed to un-exist, they would arrange for the server no longer to download that key, and the document would effectively be deleted, everywhere. I think this clearly would not be a feature that most people would accept as an enforced property of their word processor. You'd be unable to read things unless you were online, for one thing. And any document you were relying on might be yanked away from you with no warning. Such a system would be so crippled that if Microsoft really did this for Word, sales of "vi" would go through the roof. It reminds me of an even better way for a word processor company to make money: just scramble all your documents, then demand ONE MILLION DOLLARS for the keys to decrypt them. The money must be sent to a numbered Swiss account, and the software checks with a server to find out when the money has arrived. Some of the proposals for what companies will do with Palladium seem about as plausible as this one. Seth draws an analogy with Acrobat, where the paying customers are actually the publishers, the reader being given away for free. So Adobe does have incentives to put in a lot of DRM features that let authors control publication and distribution. But he doesn't follow his reasoning to its logical conclusion when dealing with Microsoft Word. That program is sold to end users - people who create their own documents for the use of themselves and their associates. The paying customers of Microsoft Word are exactly the ones who would be screwed over royally by Seth's scheme. So if we "follow the money" as Seth in effect recommends, it becomes even more obvious that Microsoft would never force Word users to be burdened with a DRL feature. And furthermore, Seth's scheme doesn't rely on TCPA/Palladium. At the risk of aiding the fearmongers, I will explain that TCPA technology actually allows for a much easier implementation, just as it does in so many other areas. There is no need for the server to download a key; it only has to download an updated DRL, and the Word client software could be trusted to delete anything that was revoked. But the point is, Seth's scheme would work just as well today, without TCPA existing. As I quoted Ross Anderson saying earlier with regard to "serial number revocation lists", these features don't need TCPA technology. So while I have some quibbles with Seth's analysis, on the whole it is the most balanced that I have seen from someone who has no connection with the designers (other than my own writing, of course). A personal gripe is that he referred to Lucky's "critics", plural, when I feel all alone out here. I guess I'll have to start using the royal "we". But he redeemed himself by taking mild exception to Lucky's slide show, which is a lot farther than anyone else has been willing to go in public. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From ben at algroup.co.uk Sat Aug 10 07:46:03 2002 From: ben at algroup.co.uk (Ben Laurie) Date: Sat, 10 Aug 2002 15:46:03 +0100 Subject: Challenge to David Wagner on TCPA References: <004601c23d28$791bb3c0$6801a8c0@xpserver> Message-ID: <3D55272B.6060906@algroup.co.uk> Lucky Green wrote: > Ray wrote: > >>>From: "James A. Donald" >>>Date: Tue, 30 Jul 2002 20:51:24 -0700 >> >>>On 29 Jul 2002 at 15:35, AARG! Anonymous wrote: >>> >>>>both Palladium and TCPA deny that they are designed to restrict >>>>what applications you run. The TPM FAQ at >>>>http://www.trustedcomputing.org/docs/TPM_QA_071802.pdf reads >>>>.... >>> >>>They deny that intent, but physically they have that capability. >> >>To make their denial credible, they could give the owner >>access to the private key of the TPM/SCP. But somehow I >>don't think that jibes with their agenda. > > > Probably not surprisingly to anybody on this list, with the exception of > potentially Anonymous, according to the TCPA's own TPM Common Criteria > Protection Profile, the TPM prevents the owner of a TPM from exporting > the TPM's internal key. The ability of the TPM to keep the owner of a PC > from reading the private key stored in the TPM has been evaluated to E3 > (augmented). For the evaluation certificate issued by NIST, see: > > http://niap.nist.gov/cc-scheme/PPentries/CCEVS-020016-VR-TPM.pdf Obviously revealing the key would defeat any useful properties of the TPM/SCP. However, unless the machine refuses to run stuff unless signed by some other key, its a matter of choice whether you run an OS that has the aforementioned properties. Of course, its highly likely that if you want to watch products of Da Mouse on your PC, you will be obliged to choose a certain OS. In order to avoid more sinister uses, it makes sense to me to ensure that at least one free OS gets appropriate signoff (and no, that does not include a Linux port by HP). At least, it makes sense to me if I assume that the certain other OS will otherwise become dominant. Which seems likely. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ Available for contract work. "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From derek at ihtfp.com Sat Aug 10 12:51:26 2002 From: derek at ihtfp.com (Derek Atkins) Date: 10 Aug 2002 15:51:26 -0400 Subject: responding to claims about TCPA In-Reply-To: References: Message-ID: AARG!Anonymous writes: > I don't agree with this distinction. If I use a smart card chip that > has a private key on it that won't come off, is that protecting me from > third parties, or vice versa? If I run a TCPA-enhanced Gnutella that Who owns the key? If you bought the smartcard, you generated the key yourself on the smartcard, and you control it, then it is probably benefitting you. If the smartcard came preprogrammed with a certificate from the manufacturer, then I would say that it is protecting the third party from you. > I wrote earlier that if people were honest, trusted computing would not > be necessary, because they would keep their promises. Trusted computing > allows people to prove to remote users that they will behave honestly. > How does that fit into your dichotomy? Society has evolved a myriad The difference is proving that you are being honest to someone else vs. an application proving to YOU that it is being honest. Again, it is a question of ownership. There is the DRM side (you proving to someone else that you are being honest) vs. Virus Protection (an application proving to _you_ that it is being honest). -derek -- Derek Atkins Computer and Internet Security Consultant derek at ihtfp.com www.ihtfp.com --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From ravage at einstein.ssz.com Sat Aug 10 14:04:27 2002 From: ravage at einstein.ssz.com (Jim Choate) Date: Sat, 10 Aug 2002 16:04:27 -0500 (CDT) Subject: Challenge to David Wagner on TCPA In-Reply-To: <15701.25201.823580.29518@desk.crynwr.com> Message-ID: On Sat, 10 Aug 2002, Russell Nelson wrote: > I agree that it's irrelevant. So why is he trying to argue from > authority (always a fallacy anyway) without *even* having any way to > prove that he is that authority? What has 'authority' got to do with it? Arguments from authority are -worthless-. Make up your own mind as to its validity, who cares about their 'proof'. -Who- is irrelevant. What damns his argument -is- his appeal to -authority-. Anyone who bases their argument on 'He said...' has already lost the discussion and invalidated any point they might make. It's one of the primary fallacies of (for example) Tim May and his consistent appeal to who he knows or what 'they' said. We agree, what I don't understand is why you keep expecting that dead horse to get up...keep asking those damning questions!!!! ;) -- ____________________________________________________________________ Conform and be dull......J. Frank Dobie ravage at ssz.com www.ssz.com jchoate at open-forge.org www.open-forge.org -------------------------------------------------------------------- From rah at shipwright.com Sat Aug 10 13:25:17 2002 From: rah at shipwright.com (R. A. Hettinga) Date: Sat, 10 Aug 2002 16:25:17 -0400 Subject: Thanks, Lucky, for helping to kill gnutella (fwd) In-Reply-To: References: Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 At 9:15 AM +0200 on 8/10/02, Eugen Leitl wrote: > I don't try to filter, but to join several sources. Anonymous is an > idiot, but at least an intelligent one. I can't leave him out > without creating a skewed picture of what is going on. No offense meant, of course. To make sure I don't miss stuff like that is why I subscribe to your list anyway, even though I'm also subscribed to most of your sources. It is also why I was glad you caught something he said that confirmed, precisely, why he's still in my killfile. :-). I don't need to raise my blood pressure more than necessary. [Ob Cypherpunks: Seriously, folks. How clueful can someone be who clearly doesn't know how to use more than one remailer hop, as proven by the fact that he's always coming out of the *same* remailer all the time? Even more important, nobody *else* uses that remailer, which is why killfiling the idiot works so well to begin with...] Anyway, on this list in particular, I've found that what any number of smart people say about what the idiot du jour says is much more interesting than what the actual idiot says himself, which is why he can safely reside in a killfile. (Having said more than my share of stupid things here myself in 8 years here, and being no stranger to the odd killfile myself :-), I'm sure lots of peoples' irony meters are pegged, but, by definition, those folks can go fuck themselves, I figure. :-).) Cheers, RAH -----BEGIN PGP SIGNATURE----- Version: PGP 7.5 iQA/AwUBPVV2YsPxH8jf3ohaEQI0mQCeIvBppfM6c2HfCQAyjlLn3w0UCfkAoIA8 NObxG1Bk8BPLraIx3LrjnJbL =dg+p -----END PGP SIGNATURE----- -- ----------------- R. A. Hettinga The Internet Bearer Underwriting Corporation 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire' From ray at unipay.nl Sat Aug 10 07:33:30 2002 From: ray at unipay.nl (R. Hirschfeld) Date: Sat, 10 Aug 2002 16:33:30 +0200 Subject: Challenge to TCPA/Palladium detractors In-Reply-To: <9a9b042036dae4dc85cd793e52375ec5@aarg.net> (message from AARG!Anonymous on Fri, 9 Aug 2002 19:30:09 -0700) References: <9a9b042036dae4dc85cd793e52375ec5@aarg.net> Message-ID: <200208101433.QAA02032@home.unipay.nl> > Date: Fri, 9 Aug 2002 19:30:09 -0700 > From: AARG!Anonymous > Re the debate over whether compilers reliably produce identical object > (executable) files: > > The measurement and hashing in TCPA/Palladium will probably not be done > on the file itself, but on the executable content that is loaded into > memory. For Palladium it is just the part of the program called the > "trusted agent". So file headers with dates, compiler version numbers, > etc., will not be part of the data which is hashed. > > The only thing that would really break the hash would be changes to the > compiler code generator that cause it to create different executable > output for the same input. This might happen between versions, but > probably most widely used compilers are relatively stable in that > respect these days. Specifying the compiler version and build flags > should provide good reliability for having the executable content hash > the same way for everyone. A trivial observation: this cannot be true across hardware platforms. TCPA claims to be "platform and OS agnostic", but Palladium does not. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From eugen at leitl.org Sat Aug 10 07:42:52 2002 From: eugen at leitl.org (Eugen Leitl) Date: Sat, 10 Aug 2002 16:42:52 +0200 (CEST) Subject: Thanks, Lucky, for helping to kill gnutella In-Reply-To: <200208101208.OAA01653@home.unipay.nl> Message-ID: On Sat, 10 Aug 2002, R. Hirschfeld wrote: > Calling Lucky a liar is no more illuminating than others calling you > an idiot. You're confusing a classification for an argument. The argument is over. You can read it up in the archives. If you think there's still anything left to discuss, I've got these plans of the Death Star I could sell you... From eugen at leitl.org Sat Aug 10 07:53:30 2002 From: eugen at leitl.org (Eugen Leitl) Date: Sat, 10 Aug 2002 16:53:30 +0200 (CEST) Subject: Challenge to TCPA/Palladium detractors In-Reply-To: <200208101433.QAA02032@home.unipay.nl> Message-ID: On Sat, 10 Aug 2002, R. Hirschfeld wrote: > A trivial observation: this cannot be true across hardware platforms. Untrue, just use a VM. Open Boot Forth would do nicely. > TCPA claims to be "platform and OS agnostic", but Palladium does not. Have fun in that there tarpit. From rah at shipwright.com Sat Aug 10 14:06:26 2002 From: rah at shipwright.com (R. A. Hettinga) Date: Sat, 10 Aug 2002 17:06:26 -0400 Subject: On the outright laughability of internet "democracy" In-Reply-To: <012101c2405c$2595fa30$def61dd4@internetkmfcrr> References: <20020809162254.59170.qmail@web9208.mail.yahoo.com> <012101c2405c$2595fa30$def61dd4@internetkmfcrr> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 (was Re: [dgc.chat] Re: [e-gold-list] Re: Thanks to Ragnar/Planetgold and Stefan/TGC) At 12:53 PM +0200 on 8/10/02, Arik Schenkler wrote: > Internet voting, IMHO, will bring true democracy rather than a > representatives democracy. Well, that's just plain wrong. Go look up discussions on google about cryptographic protocols for internet voting. It just ain't possible without the most strict, obscene, biometric, draconian, "is a person", non-anonymous methods you ever saw. Lions, tigers, and precious bodily fluids, boys and girls. The point to democracy, in the industrial/agricultural political sense, is one man, one vote. One *anonymous* vote. On the net, paradoxically, that is completely impossible. Votes can be sold. If you fix it so that you can't sell votes without forgoing your identity -- and thus your freedom -- and physically showing up somewhere to vote, or at least proving that you have a device that identifies you as a voter in the most immediate terms possible, you can sell your vote, anonymously, on the net, for whatever the market will bear, and *that* person can *re*sell your vote, and so on, just like it was voting rights to a share of stock. That bit of cryptographic mobiosity is probably down at the semantic level of consistency versus completeness. Somewhere, Goedel and Russell are laughing. The net result, of course, of any kind of truly anonymous internet voting, is anarchocapitalism, where people sell their voting control over assets, including political "assets", over and over in secondary markets, on a continuing basis, in real-time. No political small-d democrat (or small-r republican, or small-l libertarian, whatever) I've ever heard of would call that a "true" democracy. That particular prospect has anarchocapitalists, and crypto-anarchists, out at the bar, buying both Herr Professor Goedel and Lord Russell a beer or two... Cheers, RAH -----BEGIN PGP SIGNATURE----- Version: PGP 7.5 iQA/AwUBPVWANsPxH8jf3ohaEQLSXwCg7ohcz+ZCxGsX86HQSXFJHK3OOD8AoJAW 8doH9VU+LyGdpZ4x6zmz74Bv =G4Fp -----END PGP SIGNATURE----- -- ----------------- R. A. Hettinga The Internet Bearer Underwriting Corporation 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire' From jeroen at vangelderen.org Sat Aug 10 14:42:31 2002 From: jeroen at vangelderen.org (Jeroen C.van Gelderen) Date: Sat, 10 Aug 2002 17:42:31 -0400 Subject: Thanks, Lucky, for helping to kill gnutella In-Reply-To: <8c25bf764b14de9e2d3d9cd24a6d49fb@aarg.net> Message-ID: <12CE629E-ACAA-11D6-A080-000393754B1C@vangelderen.org> On Friday, Aug 9, 2002, at 13:05 US/Eastern, AARG!Anonymous wrote: > If only... Luckily the cypherpunks are doing all they can to make sure > that no such technology ever exists. They will protect us from being > able > to extend trust across the network. They will make sure that any open > network like Gnutella must forever face the challenge of rogue clients. > They will make sure that open source systems are especially vulnerable > to rogues, helping to drive these projects into closed source form. This argument is a straw man but to be fair: I am looking forward to your detailed proof that the only way to protect a Gnutella-like network from rogue clients is a Palladium-like system. You are so adamant that I have to assume you have such proof sitting right on your desk. Please share it with us. -J --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From Pete.Chown at skygate.co.uk Sat Aug 10 11:34:18 2002 From: Pete.Chown at skygate.co.uk (Pete Chown) Date: 10 Aug 2002 19:34:18 +0100 Subject: Thanks, Lucky, for helping to kill gnutella In-Reply-To: References: Message-ID: <1029004458.1452.71.camel@yeltsin.mthink> Anonymous wrote: > As far as Freenet and MojoNation, we all know that the latter shut down, > probably in part because the attempted traffic-control mechanisms made > the whole network so unwieldy that it never worked. Right, so let's solve this problem. Palladium/TCPA solves the problem in one sense, but in a very inconvenient way. First of all, they stop you running a client which has been modified in any way -- not just a client which has been modified to be selfish. Secondly, they facilitate the other bad things which have been raised on this list. > Right, as if my normal style has been so effective. Not one person has > given me the least support in my efforts to explain the truth about TCPA > and Palladium. The reason for that is that we all disagree with you. I'm interested to read your opinions, but I will argue against you. I'm not interested in reading flames at all. -- Pete From anonymous at remailer.havenco.com Sat Aug 10 13:01:09 2002 From: anonymous at remailer.havenco.com (Anonymous User) Date: Sat, 10 Aug 2002 20:01:09 +0000 (UTC) Subject: Signing as one member of a set of keys Message-ID: <364bf85b104f607ec4c8ca3ce61ba2c8@remailer.havenco.com> Here are the perl scripts I cobbled together to put the ring signature at the end of the file, after a separator. I called the executable program from the earlier C source code "ringsig". I call these ringver and ringsign. I'm no perl hacker so these could undoubtedly be greatly improved. ringver === #! /usr/bin/perl # Usage: $0 pubkeyfile < filetoverify die("Usage: ringver pubkeyfile < filetoverify") if @ARGV != 1; $outfile = "/tmp/sigdata$$"; $sigfile = "/tmp/sigfile$$"; $separator = " \\+\\+multisig v1\\.0"; $pubfile=$ARGV[0]; -r $pubfile || die ("Error reading $pubfile"); open (OUTFILE, ">".$outfile) || die ("Unable to open $outfile for output"); open (SIGFILE, ">".$sigfile) || die ("Unable to open $sigfile for output"); # Skip leading blank lines on input file $_= while /^$/; # Save lines to outfile until separator print OUTFILE $_; while () { last if /$separator/; print OUTFILE $_; } die ("No signature found in input file") if !$_; # Save remaining lines ot sigfile print SIGFILE while ; close INFILE; close OUTFILE; close SIGFILE; open (SIG, "./ringsig -v $outfile $pubfile < $sigfile |") || die ("Error running verify program"); # Print output from program print while ; close SIG; unlink($sigfile); unlink($outfile); exit($?); ringsign === #! /usr/bin/perl # Usage: $0 filetosign pubkeyfile privkeyfile die("Usage: ringsign filetosign pubkeyfile privkeyfile > outfile") if @ARGV < 3; $outfile = "/tmp/sigdata$$"; $separator = " ++multisig v1.0"; open(INFILE, $ARGV[0]) || die ("Unable to open $ARGV[0] for input"); $pubfile=$ARGV[1]; $secfile=$ARGV[2]; -r $pubfile || die ("Error reading $pubfile"); -r $secfile || die ("Error reading $secfile"); open (OUTFILE, ">".$outfile) || die ("Unable to open $outfile for output"); # Skip leading blank lines on input file $_= while /^$/; # Save lines to outfile print OUTFILE $_; print OUTFILE $_ while ; close INFILE; close OUTFILE; # Re-open infile open(INFILE, $ARGV[0]) || die ("Unable to open $ARGV[0] for input"); open (SIG, "./ringsig -s $outfile $pubfile $secfile|") || die ("Error signing"); @sigs = ; close SIG; die ("Error from signature program") if ($?); # Output infile, separator, sig print while ; print $separator . "\n"; print @sigs; unlink($outfile); From bram at gawth.com Sat Aug 10 21:15:00 2002 From: bram at gawth.com (Bram Cohen) Date: Sat, 10 Aug 2002 21:15:00 -0700 (PDT) Subject: Thanks, Lucky, for helping to kill gnutella In-Reply-To: Message-ID: AARG!Anonymous wrote: > I will just point out that it was not my idea, but rather that Salon > said that the Gnutella developers were considering moving to authorized > clients. According to Eric, those developers are "fundamentally stupid." > According to Bram, the Gnutella developers don't understand their > own protocol, and they are supporting an idea which will not help. > Apparently their belief that clients like Qtrax are hurting the system > is totally wrong, and keeping such clients off the system won't help. You can try running a sniffer on it yourself. Gnutella traffic is almost all search queries. > As far as Freenet and MojoNation, we all know that the latter shut down, > probably in part because the attempted traffic-control mechanisms made > the whole network so unwieldy that it never worked. Mojo Nation actually had a completely excessive amount of bandwidth donated to it. There was a problem that people complained of losing mojo when running a server due to the total amount of upload being greater than the total amount of download. The main user experience disaster in Mojo Nation was that the retrieval rate for files was very bad, mostly due to the high peer churn rate. > At least in part this was also due to malicious clients, according to > the analysis at http://www.cs.rice.edu/Conferences/IPTPS02/188.pdf. Oh gee, that paper mostly talks about high churn rate too. In fact, I was one of the main developers of Mojo Nation, and based on lessons learned from that figured out how to build a system which can cope with very high churn rates and has good leech resistance. It is now mature and has had several quite successful deployments. http://bitconjurer.org/BitTorrent/ Not only are the algorithms used good for leech resistance, they are also very good at being robust under normal variances in net conditions - in fact, the decentralized greedy approach to resource allocation outperforms any known centralized method. The TCPA, even if it some day works perfectly (which I seriously doubt it will) would just plain not help with any of the immediate problems in Gnutella, BitTorrent, or Mojo Nation. I would guess the same is true for most, if not all other p2p systems. -Bram Cohen "Markets can remain irrational longer than you can remain solvent" -- John Maynard Keynes --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From ray at unipay.nl Sat Aug 10 12:25:02 2002 From: ray at unipay.nl (R. Hirschfeld) Date: Sat, 10 Aug 2002 21:25:02 +0200 Subject: Thanks, Lucky, for helping to kill gnutella In-Reply-To: (message from Eugen Leitl on Sat, 10 Aug 2002 16:42:52 +0200 (CEST)) References: Message-ID: <200208101925.VAA02695@home.unipay.nl> > Date: Sat, 10 Aug 2002 16:42:52 +0200 (CEST) > From: Eugen Leitl > > > Calling Lucky a liar is no more illuminating than others calling you > > an idiot. > > You're confusing a classification for an argument. The argument is over. > You can read it up in the archives. If you think there's still anything > left to discuss, I've got these plans of the Death Star I could sell > you... I took a look at the archives as you suggested. If it matters to you, I wasn't referring to your classification of Anonymous as an idiot (which I hadn't seen because it wasn't sent to the cryptography list), but rather to an earlier comment ("Wow. You must really be an idiot.") from somebody else. Looking back at that message, it appears that it was sent to the cryptography list but not to cypherpunks. Discussion about TCPA/Pd continues, and I hope that disagreements needn't degenerate into name-calling. From darren at tao.ca Sat Aug 10 21:43:01 2002 From: darren at tao.ca (darren at tao.ca) Date: Sat, 10 Aug 2002 21:43:01 -0700 Subject: No subject Message-ID: unsubscribe From darren at tao.ca Sat Aug 10 21:43:09 2002 From: darren at tao.ca (darren at tao.ca) Date: Sat, 10 Aug 2002 21:43:09 -0700 Subject: No subject Message-ID: unsubscribe From ashwood at msn.com Sat Aug 10 21:46:12 2002 From: ashwood at msn.com (Joseph Ashwood) Date: Sat, 10 Aug 2002 21:46:12 -0700 Subject: Seth on TCPA at Defcon/Usenix References: Message-ID: <011c01c240f2$27fab400$6601a8c0@none> ----- Original Message ----- From: "AARG! Anonymous" [brief description of Document Revocation List] >Seth's scheme doesn't rely on TCPA/Palladium. Actually it does, in order to make it valuable. Without a hardware assist, the attack works like this: Hack your software (which is in many ways almost trivial) to reveal it's private key. Watch the protocol. Decrypt protocol Grab decryption key use decryption key problem solved With hardware assist, trusted software, and a trusted execution environment it (doesn't) work like this: Hack you software. DOH!!!!! the software won't run revert back to the stored software. Hack the hardware (extremely difficult). Virtualize the hardware at a second layer, using the grabbed private key Hack the software Watch the protocol. Decrypt protocol Grab decryption key use decryption key Once the file is released the server revokes all trust in your client, effectively removing all files from your computer that you have not decrypted yet problem solved? only for valuable files Of course if you could find some way to disguise which source was hacked, things change. Now about the claim that MS Word would not have this "feature." It almost certainly would. The reason being that business customers are of particular interest to MS, since they supply a large portion of the money for Word (and everything else). Businesses would want to be able to configure their network in such a way that critical business information couldn't be leaked to the outside world. Of course this removes the advertising path of conveniently leaking carefully constructed documents to the world, but for many companies that is a trivial loss. Joe --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From lynn.wheeler at firstdata.com Sat Aug 10 22:40:00 2002 From: lynn.wheeler at firstdata.com (lynn.wheeler at firstdata.com) Date: Sat, 10 Aug 2002 23:40:00 -0600 Subject: Challenge to TCPA/Palladium detractors Message-ID: oops, finger slip that should be http://www.garlic.com/~lynn/2001h.html#61 security proportional to risk aka 2001h.html not 2002h.html .... lynn.wheeler at firstdata.com on 8/10/2002 11:25 pm wrote: small discussion of security proportional to risk: http://www.garlic.com/~lynn/2002h.html#61 security proportional to risk From nelson at crynwr.com Sat Aug 10 22:01:29 2002 From: nelson at crynwr.com (Russell Nelson) Date: Sun, 11 Aug 2002 01:01:29 -0400 (EDT) Subject: Challenge to TCPA/Palladium detractors In-Reply-To: References: Message-ID: <15701.60947.440939.749927@desk.crynwr.com> AARG!Anonymous writes: > I'd like the Palladium/TCPA critics to offer an alternative proposal > for achieving the following technical goal: > > Allow computers separated on the internet to cooperate and share data > and computations such that no one can get access to the data outside > the limitations and rules imposed by the applications. Can't be done. I don't have time to go into ALL the reasons. Fortunately for me, any one reason is sufficient. #1: it's all about the economics. You have failed to specify that the cost of breaking into the data has to exceed the value of the data. But even if you did that, you'd have to assume that the data was never worth more than that to *anyone*. As soon as it was worth that, they could break into the data, and data is, after all, just data. Ignore economics at your peril. -- -russ nelson http://russnelson.com | Crynwr sells support for free software | PGPok | businesses persuade 521 Pleasant Valley Rd. | +1 315 268 1925 voice | governments coerce Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | From john.m.madsen at gmx.net Sat Aug 10 16:10:52 2002 From: john.m.madsen at gmx.net (John Madsen) Date: Sun, 11 Aug 2002 01:10:52 +0200 Subject: This MAY be a spam e-mail, but if so it's a REALLY good one! Message-ID: <4157-220028610231052742@event-horizon> My apologies for sending an unsolicited message, but if you like games, play on the stockmarket or you just wouldn't mind earning a few extra bucks, quid or whatever, I recommend you take a look at this website: World Games Inc is a fairly new thing to the net and is to date only really popular in Australia and here in Norway. It looks a bit like one of the tired, old pyramid games at first glance, but differs from those in that there is no sending money upwards through the levels, no buying stuff every week/month or you lose your place, or anything like that. Your only outlay is an initial $195 or equivalent and a further $8 or so every week after 4 weeks. I won't bother with a detailed explanation here, as the website sets out the system very well. There's also a PowerPoint presentation you can download and browse through at your leisure. The system will also feature various games like blackjack, poker and sports betting, which will be implemented in the future. This is no "get rich real quick" scheme, but rather a system which will reward those who are willing to put in a little bit of work now and then over time and, of course, the more effort, the greater the rewards. The bonus for all those who join now, is that the game is really only beginning to spread throughout the rest of the world (there are a very few players in Sweden, the UK, Denmark and the US so far) and getting in early is a definite advantage. My own personal experience so far is very limited, as I held off joining in order to see how my friends did (most of them joined right away) but now I've jumped on the bandwagon myself, since the most industrious of them earn around $200/week (after about 6 weeks). Like I said - no-one is claiming you'll be able to quit your job in six months and move to the Bahamas, but you're just about guaranteed to get your money back and more besides if you can find two people who'll join up below you. My reason for writing this is, of course, almost entirely self-serving. I need more members to join below me, in order that I earn more money. However, any money I earn WILL NOT come out of your money, so it's entirely in your interest too. Spend a few minutes of your time checking it out and you'll see what I mean - it may pay off very handsomely indeed. If you're interested or have any questions, just mail me and I'll get back to you as soon as possible. John M. Madsen (john.m.madsen at gmx.net) From rah at shipwright.com Sat Aug 10 22:55:34 2002 From: rah at shipwright.com (R. A. Hettinga) Date: Sun, 11 Aug 2002 01:55:34 -0400 Subject: Thanks, Lucky, for helping to kill gnutella (fwd) In-Reply-To: References: Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 At 4:12 AM +0000 on 8/11/02, David Wagner wrote: > I hope I don't need to point out that always using the same exit > remailer does *not* prove that he is using just one hop. One can > hold the exit remailer fixed while varying other hops in the path. > Your question seems to be based on a mistaken assumption about how > remailers work. Sorry to give that impression, and, as much as I respect you, and James Donald, who also makes the same assertion about me, both of you would be wrong in assuming that I don't know how remailers work, at least in principle. While I haven't ever built a remailer, I *have* used them on occasion, and I did edit Sameer Parekh's excellent introduction to anonymous remailers for one of the first issues of First Monday, when I was on the editorial board there in the middle 1990's. That said, I would be willing to bet a (very :-)) nominal amount that the esteemed Mr. AAARG! is, or was, in fact, using one hop, at most, though to prove the bet out would be difficult thing to do. In fact, to add further insult to his street cred, or at least kick some dust on his patent-leather penny-loafers, I wouldn't be surprised if the remailer is his own, though that would probably be too stupid even for him to do, and I'm not going to waste my time rooting out, even at a first pass, who runs the AAARG! remailer. I just say I wouldn't be surprised, is all. :-). At the foundation, then, my point is still the same one that I started with: the same, well, idiots, tend use the same outbound remailer hops, usually to the exclusion of all other remailer nodes, and, oddly enough, to the exclusion of all other users of that particular remailer. It becomes quite easy then to filter them out, which is, frankly, nice, at least as far as I'm concerned. Besides Mr. AAARG!, another user of a certain Austrian remailer node comes to mind. Both of those gentlemen, if I were to only charitably call them such, do not vary their output remailers, much less do other potentially clueful things, like actually sign their messages, for instance. Obviously all this might have to do with finding enough working remailers to string together, and, of course, the lack of genuinely any easy to use mixmaster clients out there, even now, and not for actually trying, using a whole bunch of money in a couple of cases. I suppose, given the use of lots of remailers as a platform to heckle ostensibly reasonable discussion from the back benches, if not to actually stalk online and send poison-pen email, it's easy to find their difficulty of use a blessing; though like most people who care about such things, it doesn't help the cause of ubiquitous internet privacy too much. Maybe we need cash, or something. Someday. :-). Ultimately, I think it boils down to genuine gall. If someone like Mr. AAARG! would actually endeavor to instruct the residents of the cryptography list, or even cypherpunks :-), of the utility of shoving a particularly egregious bit of technological emetic down our collective throats, or even the throat of the general public, one would think he would have a better clue about remailer hygiene when he treated us to his current round of venturi-vaporised drivel. So, Mr. AARG! is, probably, just some advanced-degree moke who works at Intel, or is a Waveoid, or other such Wintel digital "rights" "management" IP-control fellow traveller, and, given the paucity of his nocturnal emissions from behind the Great Oz's Green Velvet Curtain, or, better, the elementary answers people here are forced to use to explain more rudimentary things than remailer operations to him, probably helps me, just a smidge, with my assertion about his probable clueless use of the remailer network. Cheers, RAH -----BEGIN PGP SIGNATURE----- Version: PGP 7.5 iQA/AwUBPVX8J8PxH8jf3ohaEQJ0MgCgv3PLVPALWxBzYhkTfINn8jC3WkoAoJ+g nkXbBBPv5oaQVL4qTSP+T0Fu =zqRj -----END PGP SIGNATURE----- -- ----------------- R. A. Hettinga The Internet Bearer Underwriting Corporation 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire' From jtrjtrjtr2001 at yahoo.com Sun Aug 11 02:53:05 2002 From: jtrjtrjtr2001 at yahoo.com (gfgs pedo) Date: Sun, 11 Aug 2002 02:53:05 -0700 (PDT) Subject: Doubt on O notation. Message-ID: <20020811095305.58406.qmail@web21201.mail.yahoo.com> hi, I have problem understanding time complexity for the following problem I need to check if two strings are equal let string one s1=aaabbb and string two s2=aaabbb We place it on a single tape turing machine aaabbb aaabbb the book says it takes roughly 2n steps to match corresponding alphabet of s1 with s2,that much i understand. therefore the whole computation takes O(n^2) time. how is that,should n't be O(2n) the same if placed on a two tape turing machine is as shown tape 1: aaabbb tape2 : aaabbb and they are compared simultaneouly and have a time complexity of O(n) which is understandable. How ever i didnt get how we get O(n^2) in the previous case. In automata the number of sentential forms cannot exceed M=|p|+ |p^2| + ...+ |p|^(2|w|) where w is the length of the input string.p is the finite set of productions. I dont see how it is applicable here. pls help.Thank you. Regards Data. __________________________________________________ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com From rah at shipwright.com Sun Aug 11 00:33:37 2002 From: rah at shipwright.com (R. A. Hettinga) Date: Sun, 11 Aug 2002 03:33:37 -0400 Subject: [dgc.chat] free? Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 At 3:36 PM +1000 8/11/02, David Hillary wrote: > I think that tax havens such as the Cayman Islands should be ranked > among the freest in the world. No taxes on business or individuals > for a start. Great environment for banking and commerce. Good > protection of property rights. Small non-interventionist > government. Clearly you've never met "Triumph", the Fabulous Crotch-Sniffing Caymanian Customs Wonder Dog at extreme close range, or heard the story about the expat's college age kid, actually born on Cayman, who was literally exiled from the island when the island constabulary "discovered" a marijuana seed or three in his summer-break rental car a few years back. I mean, his old man was some senior cheese at Global Crossing at the time, but this was back when they could do no wrong. If that's what they did to *his* kid, imagine what some poor former junk-bond-hustler might have to deal with someday for, say, the odd unauthorized Cuban nightlife excursion. A discretely folded twenty keeps the stamp off your passport on the ground in Havana, and a bottle of Maker's Mark goes a long way towards some interesting nocturnal diversion when you get there and all, but still, you can't help thinking that Uncle's going to come a-knockin', and that Cayman van's going to stop rockin' some day, and when it does, it ain't gonna be pretty. Closer to home, conceptually at least, a couple of cryptogeeken were hustled off and strip-searched, on the spot, when they landed on Grand Cayman for the Financial Cryptography conference there a couple of years ago. Like lots of cypherpunks, these guys were active shooters in the Bay Area, and they had stopped in Jamaica, Mon, for a few days on the way to Grand Cayman. Because they, and their stuff, reeked on both counts, they were given complementary colorectal examinations and an entertaining game of 20 questions, or two, courtesy of the Caymanian Federales, after the obligatory fun and games with a then-snarling Crotch-Sniffing Caymanian Wonder Dog. Heck, I had to completely unpack *all* my stuff for a nice, well-fed Caymanian customs lady just to get *out* of the country when I left. Besides, tax havens are being increasingly constrained as to their activities these days, because they cost the larger nation-states too much in the way of "escaped" "revenue", or at least the perception of same in the local "free" press. Obviously, if your money "there" isn't exchangeable into your money "here", it kind of defeats the purpose of keeping your money "there" in the first place, giving folks like FinCEN lots of leverage when financial treaties come up for renegotiation due to changes in technology, like on-line credit-card and securities clearing, or the odd governmental or quango re-org, like they are wont to do increasingly in the EU, and the US. As a result, the veil of secrecy went in Switzerland quite a while ago. The recent holocaust deposit thing was just the bride and groom on that particular wedding-cake, and, as goes Switzerland, so goes Luxembourg, and of course Lichtenstein, which itself is usually accessible only through Switzerland. Finally, of course, the Caymans themselves will cough up depositor lists whenever Uncle comes calling about one thing or another on an increasingly longer list of fishing pretexts. At this point, the "legal", state-backed pecuniary privacy pickings are kind of thin on the ground. I mean, I'm not sure I'd like to keep my money in, say, Vanuatu. Would you? Remember, this is a place where a bandana hanging on a string across an otherwise public road will close it down until the local erst-cannibal hunter-gatherer turned statutorily-permanent landowner figures out just what his new or imagined property rights are this afternoon. The point is, any cypherpunk worth his salt will tell you that only solution to financial or any other, privacy, is to make private transactions on the net, cheaper, and more secure, than "transparent" transactions currently are in meatspace. Then things get *real* interesting, and financial privacy -- and considerably more personal freedom -- will just be the icing on the wedding cake. Bride and groom action figures sold separately, of course. Cheers, RAH (Who went to FC2K at the Grand Cayman Marriott in February that year. Nice place, I liked Anguilla better though, at least at the time, and I haven't been back to either since. The beaches are certainly better in Anguilla, and the "private" banking system there is probably just as porous as Cayman's is, by this point. If I were to pick up and move Somewhere Free outside Your Friendly Neighborhood Unipolar Superpower, New Zealand is somewhere near the top of my list, and Chile would be next, though things change quickly out there in ballistic-missile flyover country. In that vein, who knows, maybe we're in for some kind of latter-day Peloponnesian irony, and *Russia* will end up the freest place on earth someday. Stranger things have happened in the last couple of decades, yes?) -----BEGIN PGP SIGNATURE----- Version: PGP 7.5 iQA/AwUBPVYS48PxH8jf3ohaEQKwtgCgw/XSwzauabEP/8jDvUVk/rgFdroAn0xf Owk90GoK+X5Pv+bGoKXCwzBK =1w9d -----END PGP SIGNATURE----- -- ----------------- R. A. Hettinga The Internet Bearer Underwriting Corporation 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire' subscribe: send blank email to dgcchat-join at lists.goldmoney.com unsubscribe: send blank email to dgcchat-leave at lists.goldmoney.com digest: send an email to dgcchat-request at lists.goldmoney.com with "set yourname at yourdomain.com digest=on" in the message body --- end forwarded text -- ----------------- R. A. Hettinga The Internet Bearer Underwriting Corporation 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire' From jtrjtrjtr2001 at yahoo.com Sun Aug 11 08:13:54 2002 From: jtrjtrjtr2001 at yahoo.com (gfgs pedo) Date: Sun, 11 Aug 2002 08:13:54 -0700 (PDT) Subject: [CI] Re: Turing thesis(Incompleteness theorom) In-Reply-To: Message-ID: <20020811151354.32309.qmail@web21210.mail.yahoo.com> hi, thank you Mr. Jim,one more query, regarding Godel's incompleteness theorom. with reference to http://www.miskatonic.org/godel.html " G�del asks for the program and the circuit design of the UTM. The program may be complicated, but it can only be finitely long. Call the program P(UTM) for Program of the Universal Truth Machine. " we know that there are unprovable and provable statements and there is no way to distinguish all solvabe problems from unsolvable ones as you said below. > > > Also have can we distinguish between provable and > unprovable statements. > > That is an unsolvable problem if you are looking for > a general approach to > -any- statement, that -is- Godel's. > In godel's theorom,above mentioned,it says circuit design and programme must be finitely long. Is that necessary?we can't say for sure,right?Isn't it an unprovable statement which is made or more likely an assumption. if we say other wise,why has the programme to be finite? Thank you very much. Regards Data. __________________________________________________ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com From mv at cdc.gov Sun Aug 11 09:12:43 2002 From: mv at cdc.gov (Major Variola (ret)) Date: Sun, 11 Aug 2002 09:12:43 -0700 Subject: Pakis needing killing Message-ID: <3D568CFB.E419335F@cdc.gov> "If somebody cannot produce some form of identification, he can't use the Internet. It's in the interest of law and order, and stopping terrorism," said Shahzada Alam, chairman of the Pakistan Telecommunications Authority, which regulates the Internet in Pakistan. http://story.news.yahoo.com/news?tmpl=story&u=/ap/20020805/ap_wo_en_po/pakistan_forbidden_internet_3 From gnu at toad.com Sun Aug 11 11:15:28 2002 From: gnu at toad.com (John Gilmore) Date: Sun, 11 Aug 2002 11:15:28 -0700 Subject: Seth on TCPA at Defcon/Usenix In-Reply-To: Message-ID: <200208111815.g7BIFSq11030@new.toad.com> > It reminds me of an even better way for a word processor company to make > money: just scramble all your documents, then demand ONE MILLION DOLLARS > for the keys to decrypt them. The money must be sent to a numbered > Swiss account, and the software checks with a server to find out when > the money has arrived. Some of the proposals for what companies will > do with Palladium seem about as plausible as this one. Isn't this how Windows XP and Office XP work? They let you set up the system and fill it with your data for a while -- then lock up and won't let you access your locally stored data, until you put the computer on the Internet and "register" it with Microsoft. They charge less than a million dollars to unhand your data, but otherwise it looks to me like a very similar scheme. There's a first-person report about how Office XP made the computers donated for the 9/11 missing persons database useless after several days of data entry -- so the data was abandoned, and re-entered into a previous (non-DRM) Microsoft word processor. The report came through this very mailing list. See: http://www.mail-archive.com/cryptography at wasabisystems.com/msg02134.html This scenario of word processor vendors denying people access to their own documents until they do something to benefit the vendor is not just "plausible" -- it's happening here and now. John From paul at ciphergoth.org Sun Aug 11 03:38:06 2002 From: paul at ciphergoth.org (Paul Crowley) Date: 11 Aug 2002 11:38:06 +0100 Subject: Thanks, Lucky, for helping to kill gnutella In-Reply-To: AARG!Anonymous's message of "Fri, 9 Aug 2002 10:05:15 -0700" References: <8c25bf764b14de9e2d3d9cd24a6d49fb@aarg.net> Message-ID: <87adntllyp.fsf@saltationism.subnet.hedonism.cluefactory.org.uk> AARG!Anonymous writes: > Be sure and send a note to the Gnutella people reminding them of all > you're doing for them, okay, Lucky? Do the Gnutella people share your feelings on this matter? I'd be surprised. -- __ Paul Crowley \/ o\ sig at paul.ciphergoth.org /\__/ http://www.ciphergoth.org/ From rah at shipwright.com Sun Aug 11 09:31:56 2002 From: rah at shipwright.com (R. A. Hettinga) Date: Sun, 11 Aug 2002 12:31:56 -0400 Subject: [dgc.chat] free? Message-ID: --- begin forwarded text From sws at cs.dartmouth.edu Sun Aug 11 09:35:12 2002 From: sws at cs.dartmouth.edu (Sean Smith) Date: Sun, 11 Aug 2002 12:35:12 -0400 Subject: Thanks, Lucky, for helping to kill gnutella In-Reply-To: Your message of "Fri, 09 Aug 2002 10:05:15 PDT." <8c25bf764b14de9e2d3d9cd24a6d49fb@aarg.net> Message-ID: <200208111635.g7BGZCk01872@chipotle.cs.dartmouth.edu> Actually, our group at Dartmouth has an NSF "Trusted Computing" grant to do this, using the IBM 4758 (probably with a different OS) as the hardware. We've been calling the project "Marianas", since it involves a chain of islands. --Sean >If only there were a technology in which clients could verify and yes, >even trust, each other remotely. Some way in which a digital certificate >on a program could actually be verified, perhaps by some kind of remote, >trusted hardware device. This way you could know that a remote system was >actually running a well-behaved client before admitting it to the net. >This would protect Gnutella from not only the kind of opportunistic >misbehavior seen today, but the future floods, attacks and DOSing which >will be launched in earnest once the content companies get serious about >taking this network down. -- Sean W. Smith, Ph.D. sws at cs.dartmouth.edu http://www.cs.dartmouth.edu/~sws/ (has ssl link to pgp key) Department of Computer Science, Dartmouth College, Hanover NH USA --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From juicy at melontraffickers.com Sun Aug 11 12:51:05 2002 From: juicy at melontraffickers.com (A.Melon) Date: Sun, 11 Aug 2002 12:51:05 -0700 (PDT) Subject: On the outright laughability of internet "democracy" Message-ID: <7b1f2493990e67b10132b177228f1a1a@melontraffickers.com> On Sun, 11 Aug 2002 13:22:15 -0400, you wrote: > > At 4:35 PM +0200 on 8/11/02, Anonymous wrote: > > > > Next, the "internet" boogeyman. > > Nope. Just the clueless "only knows one austrian remailer" boogeyman. Watch > me make him go away: > > <*Plonk!*> Based on your inability or unwillingness to address the issues identified specifically, that is pretty good course of action on your part. I would think you might be interested in going deeper, as "Blind signatures for untraceable payments" is directly applicable to both digital settlement and digital voting. See http://www.acm.org/crossroads/xrds2-4/voting.html for an interesting little article of introduction about the topic. And there are many others more current and deep. Those issues, remaining unaddressed by you, include: "The "sold vote" boogeyman". You need to submit evidence that "anonymous" "internet" voting is more likely to be fraudulent than paper, voter-present by mail voting. You have submitted none, and the "cryptography" word is insufficient to scare me off. The "bogus digital voter registration" boogeyman. You may also wish to show how digital voter registration cards would be more likely to be bogus than "Motor Voter, no-id required" registration cards. Good luck. The "crypto" boogeyman. I challenge you to show that current, published crypto voting protocols cannot accomplish the following: 1. one digital sig, one vote, the first one, and the others are discarded 2. no dig signature, no vote 3. no dig voter registration, no dig sig 4. anonymity, i.e., no connectibility between the voter's choice and his identity. 5. auditability, i.e., connection between each voting "lever throw" and a dig sig for the current vote. Next, the "internet" boogeyman. It's just a pipe/wire/whatever. Bits. Don't be afraid. If the bits are properly signed, no problem and whether "internet" bits or voter-machine-punched-paper-tape-bits is irrelevant." They are not strengthened or weakened by the mail server applied to their transmission, by the way. Cheers! From rah at shipwright.com Sun Aug 11 10:22:15 2002 From: rah at shipwright.com (R. A. Hettinga) Date: Sun, 11 Aug 2002 13:22:15 -0400 Subject: On the outright laughability of internet "democracy" In-Reply-To: <34859a787b1b29f3ea1528ba4e452fdb@remailer.privacy.at> References: <34859a787b1b29f3ea1528ba4e452fdb@remailer.privacy.at> Message-ID: At 4:35 PM +0200 on 8/11/02, Anonymous wrote: > Next, the "internet" boogeyman. Nope. Just the clueless "only knows one austrian remailer" boogeyman. Watch me make him go away: <*Plonk!*> Cheers, RAH -- ----------------- R. A. Hettinga The Internet Bearer Underwriting Corporation 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire' From rah at shipwright.com Sun Aug 11 10:30:46 2002 From: rah at shipwright.com (R. A. Hettinga) Date: Sun, 11 Aug 2002 13:30:46 -0400 Subject: Thanks, Lucky, for helping to kill gnutella In-Reply-To: <200208111635.g7BGZCk01872@chipotle.cs.dartmouth.edu> References: <200208111635.g7BGZCk01872@chipotle.cs.dartmouth.edu> Message-ID: I'm genuinely sorry, but I couldn't resist this... At 12:35 PM -0400 on 8/11/02, Sean Smith wrote: > Actually, our group at Dartmouth has an NSF "Trusted Computing" > grant to do this, using the IBM 4758 (probably with a different > OS) as the hardware. > > We've been calling the project "Marianas", since it involves a > chain of islands. ...and not the world's deepest hole, sitting right next door? ;-) Cheers, RAH > --Sean > >>If only there were a technology in which clients could verify and >>yes, even trust, each other remotely. Some way in which a digital >>certificate on a program could actually be verified, perhaps by >>some kind of remote, trusted hardware device. This way you could >>know that a remote system was actually running a well-behaved >>client before admitting it to the net. This would protect Gnutella >>from not only the kind of opportunistic misbehavior seen today, but >>the future floods, attacks and DOSing which will be launched in >>earnest once the content companies get serious about taking this >>network down. -- ----------------- R. A. Hettinga The Internet Bearer Underwriting Corporation 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire' --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From ben at algroup.co.uk Sun Aug 11 08:03:54 2002 From: ben at algroup.co.uk (Ben Laurie) Date: Sun, 11 Aug 2002 16:03:54 +0100 Subject: dangers of TCPA/palladium References: Message-ID: <3D567CDA.40709@algroup.co.uk> AARG!Anonymous wrote: > Adam Back writes: > > >>- Palladium is a proposed OS feature-set based on the TCPA hardware >>(Microsoft) > > > Actually there seem to be some hardware differences between TCPA and > Palladium. TCPA relies on a TPM, while Palladium uses some kind of > new CPU mode. Palladium also includes some secure memory, a concept > which does not exist in TCPA. This is correct. Palladium has "ring -1", and memory that is only accessible to ring -1 (or I/O initiated by ring -1). Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ Available for contract work. "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From ben at algroup.co.uk Sun Aug 11 08:10:44 2002 From: ben at algroup.co.uk (Ben Laurie) Date: Sun, 11 Aug 2002 16:10:44 +0100 Subject: dangers of TCPA/palladium References: Message-ID: <3D567E74.90701@algroup.co.uk> Mike Rosing wrote: >>Why exactly is this so much more of a threat than, say, flash BIOS >>upgrades? The BIOS has a lot more power over your machine than the >>TPM does. > > > The difference is fundamental: I can change every bit of flash in my BIOS. > I can not change *anything* in the TPM. *I* control my BIOS. IF, and > only IF, I can control the TPM will I trust it to extend my trust to > others. The purpose of TCPA as spec'ed is to remove my control and > make the platform "trusted" to one entity. That entity has the master > key to the TPM. > > Now, if the spec says I can install my own key into the TPM, then yes, > it is a very useful tool. It would be fantastic in all the portables > that have been stolen from the FBI for example. Assuming they use a > password at turn on, and the TPM is used to send data over the net, > then they'd know where all their units are and know they weren't > compromised (or how badly compromised anyway). > > But as spec'ed, it is very seriously flawed. Although the outcome _may_ be like this, your understanding of the TPM is seriously flawed - it doesn't prevent your from running whatever you want, but what it does do is allow a remote machine to confirm what you have chosen to run. It helps to argue from a correct starting point. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ Available for contract work. "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff From sws at cs.dartmouth.edu Sun Aug 11 13:17:34 2002 From: sws at cs.dartmouth.edu (Sean Smith) Date: Sun, 11 Aug 2002 16:17:34 -0400 Subject: Thanks, Lucky, for helping to kill gnutella In-Reply-To: Your message of "Sun, 11 Aug 2002 13:30:46 EDT." Message-ID: <200208112017.g7BKHYE02439@chipotle.cs.dartmouth.edu> i guess it's appropriate that the world's deepest hole is next to something labelled a "trust territory" :) --Sean :) --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From rah at shipwright.com Sun Aug 11 13:18:32 2002 From: rah at shipwright.com (R. A. Hettinga) Date: Sun, 11 Aug 2002 16:18:32 -0400 Subject: On the outright laughability of internet "democracy" In-Reply-To: <7b1f2493990e67b10132b177228f1a1a@melontraffickers.com> References: <7b1f2493990e67b10132b177228f1a1a@melontraffickers.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 At 12:51 PM -0700 on 8/11/02, A.Austrian.Idiot single hops yet another remailer and wrote: > I would think you might be interested in going deeper, as "Blind > signatures for untraceable payments" is directly applicable to > both digital settlement and digital voting. Yes. Of course. And, if you actually read it, or even just thought about it instead of spewing oppositional bullshit to everything you disagree with politically, :-), you'd soon realize that you can't actually control an truly anonymous voting scheme any more than you can control a truly anonymous bearer asset. Like equity, an anonymous vote is completely salable. In short, sir, please to fuck off, until you actually know what you're talking about. Cheers, RAH -----BEGIN PGP SIGNATURE----- Version: PGP 7.5 iQA/AwUBPVbGfsPxH8jf3ohaEQKaCACg5imhi38mKjBmPiX1uo4V2l77PiQAoK4K Md2o5nPZy57vzqZNFDuJdFcP =4bGV -----END PGP SIGNATURE----- -- ----------------- R. A. Hettinga The Internet Bearer Underwriting Corporation 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire' From rah at shipwright.com Sun Aug 11 13:22:07 2002 From: rah at shipwright.com (R. A. Hettinga) Date: Sun, 11 Aug 2002 16:22:07 -0400 Subject: Thanks, Lucky, for helping to kill gnutella In-Reply-To: <200208112017.g7BKHYE02439@chipotle.cs.dartmouth.edu> References: <200208112017.g7BKHYE02439@chipotle.cs.dartmouth.edu> Message-ID: At 4:17 PM -0400 on 8/11/02, Sean Smith wrote: > i guess it's appropriate that the world's deepest > hole is next to something labelled a "trust territory" :) Tears run down my face, I laughed so much. My cheeks hurt, I'm smiling so hard... Cheers, RAH -- ----------------- R. A. Hettinga The Internet Bearer Underwriting Corporation 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire' From remailer at xganon.com Sun Aug 11 14:33:28 2002 From: remailer at xganon.com (xganon) Date: Sun, 11 Aug 2002 16:33:28 -0500 Subject: On the outright laughability of internet "democracy" Message-ID: On Sun, 11 Aug 2002 16:18:32 -0400, you wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > At 12:51 PM -0700 on 8/11/02, A.Austrian.Idiot single hops yet > another remailer and wrote: Namecalling. Possibly your strongest argumentation? > > I would think you might be interested in going deeper, as "Blind > > signatures for untraceable payments" is directly applicable to > > both digital settlement and digital voting. > > Yes. Of course. And, if you actually read it, or even just thought > about it instead of spewing oppositional bullshit to everything you > disagree with politically, :-), Must have touched quite a raw nerve here. My thanks for your not "spewing oppositional bullshit". And what, pray tell, am I disagreeing with "politically"? > you'd soon realize that you can't > actually control an truly anonymous voting scheme any more than you > can control a truly anonymous bearer asset. Like equity, an anonymous > vote is completely salable. Read first, spew later. > > In short, sir, please to fuck off, until you actually know what > you're talking about. Another of your better argumentation. It is difficult to choose between your vulgar manner or your avoidance of facts, as the better explanation of the failure of your "Internet Bearer Underwriting" ventures. Cheers! From nobody at remailer.privacy.at Sun Aug 11 07:35:08 2002 From: nobody at remailer.privacy.at (Anonymous) Date: Sun, 11 Aug 2002 16:35:08 +0200 (CEST) Subject: On the outright laughability of internet "democracy" Message-ID: <34859a787b1b29f3ea1528ba4e452fdb@remailer.privacy.at> On Sat, 10 Aug 2002 17:06:26 -0400, you wrote: > Go look up discussions on google about cryptographic protocols for > internet voting. It just ain't possible without the most strict, > obscene, biometric, draconian, "is a person", non-anonymous methods > you ever saw. Sure it is. The measures, if any, taken to insure that the "person" being granted a "digital voter registration card" is a "qualified voter" can be as lax or as stringent as the issuer may require. There is no reason that they would need be more stringent than current process, which, in the US, prohibit voter registration staff from requiring verification of identity. See the "Motor Voter" law. > > The point to democracy, in the industrial/agricultural political > sense, is one man, one vote. One *anonymous* vote. Except in Chicago, etc., etc. > On the net, > paradoxically, that is completely impossible. Votes can be sold. No different from the current arrangement. Voting in many jurisdictions can be done today by mail. How would a digital vote, using cryptographic protocols to insure anonymity, and authenticity (the registered person who was issued the digital voter registration has digitally signed the vote) be less likely to be "sold" than a mailed in vote? And pardon the political comment, but almost all votes are sold now, as in the United States the democratic custom has declined to using votes essentially to transfer wealth from earners to voting blocs. > If > you fix it so that you can't sell votes without forgoing your > identity -- and thus your freedom -- and physically showing up > somewhere to vote, or at least proving that you have a device that > identifies you as a voter in the most immediate terms possible, you > can sell your vote, anonymously, on the net, for whatever the market > will bear, and *that* person can *re*sell your vote, and so on, just > like it was voting rights to a share of stock. It is quite simpler to do such fraud with mail in votes, or even "buy me a drink and I'll vote however you'd like", or "yes, this is my pictureless voter registration card, and I'm here to vote". > That bit of > cryptographic mobiosity is probably down at the semantic level of > consistency versus completeness. Somewhere, Goedel and Russell are > laughing. A laugh a day keeps the economists away. > > The net result, of course, of any kind of truly anonymous internet > voting, is anarchocapitalism, where people sell their voting control > over assets, including political "assets", over and over in secondary > markets, on a continuing basis, in real-time. No political small-d > democrat (or small-r republican, or small-l libertarian, whatever) > I've ever heard of would call that a "true" democracy. The "sold vote" boogeyman". You need to submit evidence that "anonymous" "internet" voting is more likely to be fraudulent than paper, voter-present by mail voting. You have submitted none, and the "cryptography" word is insufficient to scare me off. The "bogus digital voter registration" boogeyman. You may also wish to show how digital voter registration cards would be more likely to be bogus than "Motor Voter, no-id required" registration cards. Good luck. The "crypto" boogeyman. I challenge you to show that current, published crypto voting protocols cannot accomplish the following: 1. one digital sig, one vote, the first one, and the others are discarded 2. no dig signature, no vote 3. no dig voter registration, no dig sig 4. anonymity, i.e., no connectibility between the voter's choice and his identity. 5. auditability, i.e., connection between each voting "lever throw" and a dig sig for the current vote. Next, the "internet" boogeyman. It's just a pipe/wire/whatever. Bits. Don't be afraid. If the bits are properly signed, no problem and whether "internet" bits or voter-machine-punched-paper-tape-bits is irrelevant. From mburns at tamerlane.ca Sun Aug 11 15:08:00 2002 From: mburns at tamerlane.ca (Mark) Date: Sun, 11 Aug 2002 18:08:00 -0400 Subject: On alliances and enemies. References: Message-ID: <006e01c24183$930fc280$0300a8c0@smith> Jim Choate said: > > > > I don't see Stalin/Hitler, I see; > > > > > > > > Standard Oil/ > > > > Department of Transporation/ > > > > Interstate Commerce Commission) > > > > General Motors/ > > > > Ford/ > > > > and so forth. > > > > > > You draw a false distinction. And what is your position on IBM, Hitler, their interaction during WWII, etc? From zenadsl6186 at zen.co.uk Sun Aug 11 11:09:22 2002 From: zenadsl6186 at zen.co.uk (Peter Fairbrother) Date: Sun, 11 Aug 2002 19:09:22 +0100 Subject: TCPA/Palladium -- likely future implications (Re: dangers of TCPA/palladium) In-Reply-To: <20020809221356.A637432@exeter.ac.uk> Message-ID: Adam Back wrote: [...] > - It is always the case that targetted people can have hardware > attacks perpetrated against them. (Keyboard sniffers placed during > court authorised break-in as FBI has used in mob case of PGP using > Mafiosa [1]). [...] > [1] "FBI Bugs Keyboard of PGP-Using Alleged Mafioso", 6 Dec 2000, > slashdot That was a software keylogger (actually two software keyloggers), not hardware. (IMO Scarfo's lawyers should never have dealt, assuming the evidence was necessary for a conviction, but the FBI statement about the techniques used was probably too obfuscated for them - it took me a good week to understand it. I emailed them, but got no reply. Incidently, Nicky Scarfo used his father's prison number for the password, so a well researched directed dictionary attack would have worked anyway.) The FBI reputedly can (usually, on Windows boxen) now install similar software keyloggers remotely, without needing to break in. -- Peter Fairbrother --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From beemermail at yahoo.com Sun Aug 11 21:38:11 2002 From: beemermail at yahoo.com (Eric Beemer) Date: Sun, 11 Aug 2002 21:38:11 -0700 Subject: OPPORTUNITY KNOCKS!!! Message-ID: <200208120438.g7C4c2R21505@waste.minder.net> Your new job: Stop losing all your money to the house and BECOME THE HOUSE!!! This new revolutionary casino allows the players to deal the games. Get the house odds in your favor. You can deal blackjack, roulette, slots, video poker, pai gow poker, caribbean poker, baccarat, or war. For a limited time, you can now get a 200% credits bonus by signing up! Even if you only want to be a player, you are assured the casino has no interest in who wins. This is because you will be playing against other players. What better way to be assured a fair game! DOWNLOAD NOW or get MORE CASINO INFO by going to: *** www.PlayersDeal.com *** This message is sent in compliance of the new e-mail bill: section 301. Per section 301, Paragraph (a)(2)(C) of S. 1618, further transmissions to you by the sender of this e-mail may be stopped at no cost to you by sending a reply to this e-mail address with the word "remove" in the subject line. From adam at homeport.org Sun Aug 11 18:58:26 2002 From: adam at homeport.org (Adam Shostack) Date: Sun, 11 Aug 2002 21:58:26 -0400 Subject: Signing as one member of a set of keys In-Reply-To: <20020809201115.A643604@exeter.ac.uk>; from adam@cypherspace.org on Fri, Aug 09, 2002 at 08:11:15PM +0100 References: <20020809201115.A643604@exeter.ac.uk> Message-ID: <20020811215826.A51796@lightship.internal.homeport.org> Of course, the paranoid amonsgt us now believe that Mr. Back wrote the code, and is engaging in a little misdirection below. "Thanks for making the analysis easy!" ;) On Fri, Aug 09, 2002 at 08:11:15PM +0100, Adam Back wrote: | Very nice. | | Nice plausible set of candidate authors also: | | pub 1022/5AC7B865 1992/12/01 loki at obscura.com | pub 1024/2B48F6F5 1996/04/10 Ian Goldberg | pub 1024/97558A1D 1994/01/10 Pr0duct Cypher | pub 1024/2719AF35 1995/05/13 Ben Laurie | pub 1024/58214C37 1992/09/08 Hal Finney <74076.1041 at compuserve.com> | pub 1024/C8002BD1 1997/03/04 Eric Young | pub 1024/FBBB8AB1 1994/05/07 Colin Plumb | | Wonder if we can figure out who is most likely author based on coding | style from such a small set. | | It has (8 char) TABs but other wise BSD indentation style (BSD | normally 4 spaces). Also someone who likes triply indirected pointers | ***blah in there. Has local variables inside even *if code blocks* | eg, inside main() (most people avoid that, preferring to declare | variables at the top of a function, and historically I think some | older gcc / gdb couldn't debug those variables if I recall). Very | funky use of goto in getpgppkt, hmmm. Somewhat concise coding and | variable names. | | Off the cuff guess based on coding without looking at samples of code | to remind, probably Colin or Ian. | | Of course (Lance Cottrell/Ian Goldberg/Pr0duct Cypher/Ben Laurie/Hal | Finney/Eric Young/Colin Plumb) possibly deviated or mimicked one of | their coding styles. Kind of interesting to see a true nym in there | also. | | Also the Cc -- Coderpunks lives? I think the Cc coderpunks might be a | clue also, I think some of these people would know it died. I think | that points more at Colin. | | Other potential avenue might be implementation mistake leading to | failure of the scheme to robustly make undecidable which of the set is | the true author, given alpha code. | | Adam | | On Fri, Aug 09, 2002 at 03:52:56AM +0000, Anonymous User wrote: | > This program can be used by anonymous contributors to release partial | > information about their identity - they can show that they are someone | > from a list of PGP key holders, without revealing which member of the | > list they are. Maybe it can help in the recent controvery over the | > identity of anonymous posters. It's a fairly low-level program that | > should be wrapped in a nicer UI. I'll send a couple of perl scripts | > later that make it easier to use. | -- "It is seldom that liberty of any kind is lost all at once." -Hume From rah at shipwright.com Sun Aug 11 19:07:11 2002 From: rah at shipwright.com (R. A. Hettinga) Date: Sun, 11 Aug 2002 22:07:11 -0400 Subject: On the outright laughability of internet "democracy" In-Reply-To: References: Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 At 4:33 PM -0500 on 8/11/02, the Austrian one-hop-wonder changed remailers again, jumped out of the kill-file, followed me around the mail list and started humping my leg with: > Namecalling. Possibly your strongest argumentation? Not at all. I really do believe the word "idiot" is most appropriate to your level of intelligence, and that makes it merely an observation of fact on my part. However, to honor your persistence, I will call you names later, since you really want it so bad. But, first... > Must have touched quite a raw nerve here. My thanks for your not > "spewing oppositional bullshit". And what, pray tell, am I > disagreeing with "politically"? You are clearly a statist. In my autodydactic but still fairly practiced opinion, an idiot statist. "Statist" because apparently you've never seen a nation-state you didn't want to suck up to. "Idiot", because when someone makes a statement of fact, like I did several times in a row in this thread, you refute it with something other than reason. Usually a repetition of the same thing over and over, even when it clearly doesn't work for you. Certainly the very definition of lunacy, if it's not actual idiocy. There. How's that for a characterization of your disagreeable politics? >> you'd soon realize that you can't >> actually control an truly anonymous voting scheme any more than >> you can control a truly anonymous bearer asset. Like equity, an >> anonymous vote is completely salable. > > Read first, spew later. [This is, ladies, and gentlemen, exactly what *I* would call "oppositional bullshit". Notice that he merely said the logical equivalent of "I know you are, but what am I?" Oppositional. And Bullshit. Check, and Check. Notice he says nothing, including his previously ignored and recursively regurgitated "refutation" of that claim at the beginning of the thread, that actually counters what I've said all along, copied above in the interest of completeness, if not consistency, above. But enough of that, well, idiocy. Now, boys and girls, let's have some fun, shall we? He thinks I'm insulting. Clearly he hasn't been here long enough. :-) First a, um, warm-up. Where were we. Oh, yes. Here we are...] > Read first, spew later. Cranky, Mr. One-Hop? Whatsa matter? Your ancient mother give you a friction burn in the sack last night? K-Y's cheap, you know. You should try it. I hear it even, um, comes in flavors these days... [...and, as promised, the main event...] >> In short, sir, please to fuck off, until you actually know what >> you're talking about. > > Another of your better argumentation. It is difficult to choose > between your vulgar manner or your avoidance of facts, Allow me to argue even better then, in a matter you seem to appreciate most. You, sir, are an imbecile. A Poltroon. A Spittlelicker and a toady [Thanks to Patrick O'Brien...]. [Postmodern anti-imperialist] A statist lackey (sorry Ryan :-)). A straw-felching pederast [my apologies to all felchers, straw-using, and otherwise, and, of course, to pederasts everywhere...] Ah, the pain of monolinguality. You've said it yourself, haven't you? I really should learn to use other languages, as my life would be so much richer. In that, um, vein, and in your multilingual honor, I hope I'm forgiven if I got some help,. The following are compliments of the good folks at : Yiddish -- Yutz. Putz. (I'm sorry you'd don't qualify for "Schmuck", Mr. One-Hop, much less "Schlong", but, by the way you acquit yourself here on cypherpunks, that would be off by an order or two of magnitude. Or, heh, three. :-). Maybe it got dwarfed by friction burn, or something. Better put some ice on that?) Schlemeil, Schlmazel, [I feel like Laverne and Shirley, here...] Mishugena. Gayn Cacken Ofn yam. French -- Lhche mon cul. [I think that one says it all, don't you think? The French have *such* a classy expression for *everything*.] German -- Depp (sound familiar?), Arschgesicht, Leck mich am Arsch [there's an echo in here...], Hosenscheisser, and, probably most applicable to your career and qualifications, Arschkriecher [cf "Toady", above]. Afrikaans [vaguely brutal, and to the point] -- Poephol. Japanese [cute, in a "Hello Kitty" kind of way] -- kisama. Cantonese [phonetic] -- lay da yuen fay gay mm sai sou. Mandarin [also phonetic] -- Liu mang. Finnish [in honor of Linus] -- Ditisi nai poroja! Dutch [as one would expect :-), they're particularly creative, but I like a little irony, myself] -- droogkloot. And, finally, Latin [a classic, rendered in a classic tongue, and in memory of your aforementioned chronic lack of nightly lubrication]-- tua mater. > as the better explanation of the failure of your "Internet Bearer > Underwriting" ventures. We'll see, I suppose. At least I haven't quit yet. Nonetheless, it's a safe bet that as much as I'm too stupid to quit trying to make IBUC work, you will *always* be more stupid than I am. Now, somehow, I really feel like I got the better deal, here. Tell ya what, One-Hop: if I do get IBUC's arm out of the shark and sewn back on, I'll send you a little remuneration for all the entertainment you've provided all of us this evening. So, if and when IBUC actually *does* work, and given your ironic predilection for book-entry transactions and the use of violent government enforcement of non-repudiation, where, exactly, do you want me to send the check, and who do I make it out to? ;-) Cheers, RAH -----BEGIN PGP SIGNATURE----- Version: PGP 7.5 iQA/AwUBPVcYR8PxH8jf3ohaEQKzRwCg3RlP5nZu/rxRBX566zl/wAEOt7wAoItU PC5f0dwMuWUKnYLJ3EnGLAbi =O6Z1 -----END PGP SIGNATURE----- -- ----------------- R. A. Hettinga The Internet Bearer Underwriting Corporation 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire' From bal at farcaster.com Mon Aug 12 00:27:22 2002 From: bal at farcaster.com (Brian A. LaMacchia) Date: Mon, 12 Aug 2002 00:27:22 -0700 Subject: Challenge to David Wagner on TCPA References: <004601c23d28$791bb3c0$6801a8c0@xpserver> Message-ID: <007101c241d2$487aa510$0400010a@bal600> I just want to point out that, as far as Palladium is concerned, we really don't care how the keys got onto the machine. Certain *applications* written on top of Palladium will probably care, but all the hardware & the security kernel really care about is making sure that secrets are only divulged to the code that had them encrypted in the first place. It's all a big trust management problem (or a series of trust management problems) -- applications that are going to rely on SCP keys to protect secrets for them are going to want some assurances about where the keys live and whether there's a copy outside the SCP. I can certainly envision potential applications that would want guarantees that the key was generated on the SCP & never left, and I can see other applications that want guarantees that the key has a copy sitting on another SCP on the other side of the building. So the complexity isn't in how the keys get initialized on the SCP (hey, it could be some crazy little hobbit named Mel who runs around to every machine and puts them in with a magic wand). The complexity is in the keying infrastructure and the set of signed statements (certificates, for lack of a better word) that convey information about how the keys were generated & stored. Those statements need to be able to represent to other applications what protocols were followed and precautions taken to protect the private key. Assuming that there's something like a cert chain here, the root of this chain chould be an OEM, an IHV, a user, a federal agency, your company, etc. Whatever that root is, the application that's going to divulge secrets to the SCP needs to be convinced that the key can be trusted (in the security sense) not to divulge data encrypted to it to third parties. Palladium needs to look at the hardware certificates and reliably tell (under user control) what they are. Anyone can decide if they trust the system based on the information given; Palladium simply guarantees that it won't tell anyone your secrets without your explicit request.. --bal P.S. I'm not sure that I actually *want* the ability to extract the private key from an SCP after it's been loaded, because presumably if I could ask for the private key then a third party doing a black-bag job on my PC could also ask for it. I think what I want is the ability to zeroize the SCP, remove all state stored within it, and cause new keys to be generated on-chip. So long as I can zero the chip whenever I want (or zero part of it, or whatever) I can eliminate the threat posed by the manufacturer who initialized the SCP in the first place. Lucky Green wrote: > Ray wrote: >> >>> From: "James A. Donald" >>> Date: Tue, 30 Jul 2002 20:51:24 -0700 >> >>> On 29 Jul 2002 at 15:35, AARG! Anonymous wrote: >>>> both Palladium and TCPA deny that they are designed to restrict >>>> what applications you run. The TPM FAQ at >>>> http://www.trustedcomputing.org/docs/TPM_QA_071802.pdf reads >>>> .... >>> >>> They deny that intent, but physically they have that capability. >> >> To make their denial credible, they could give the owner >> access to the private key of the TPM/SCP. But somehow I >> don't think that jibes with their agenda. > > Probably not surprisingly to anybody on this list, with the exception > of potentially Anonymous, according to the TCPA's own TPM Common > Criteria Protection Profile, the TPM prevents the owner of a TPM from > exporting the TPM's internal key. The ability of the TPM to keep the > owner of a PC from reading the private key stored in the TPM has been > evaluated to E3 (augmented). For the evaluation certificate issued by > NIST, see: > > http://niap.nist.gov/cc-scheme/PPentries/CCEVS-020016-VR-TPM.pdf > >> If I buy a lock I expect that by demonstrating ownership I >> can get a replacement key or have a locksmith legally open it. > > It appears the days when this was true are waning. At least in the PC > platform domain. > > --Lucky > > > --------------------------------------------------------------------- > The Cryptography Mailing List > Unsubscribe by sending "unsubscribe cryptography" to > majordomo at wasabisystems.com From anonymous at cotsebay.cotse.net Sun Aug 11 20:15:13 2002 From: anonymous at cotsebay.cotse.net (Niemand Nirgendwo) Date: 12 Aug 2002 03:15:13 -0000 Subject: On the outright laughability of internet "democracy" Message-ID: On Sun, 11 Aug 2002 22:07:11 -0400, R. A. Hettinga wrote: 160 lines, 1,150 words, 6,393 characters, all insisting on describing his being guthooked, sinker eating, line chewing and flopping up into the greasy bilge, furiously spewing offense and defense, in serious, righteous and angry pursuit of the diaphanous illusion of anoned bait-spilth, becoming clearly the easiest, but also the lowest calorie catch o' the day. Back over the side with you, little fellow. Good fish. Thank you for playing. From starrgazerr at earthlink.net Mon Aug 12 06:09:34 2002 From: starrgazerr at earthlink.net (amanda stone) Date: Mon, 12 Aug 2002 09:09:34 -0400 Subject: joining Message-ID: <000801c24201$866bafc0$0201a8c0@0016223629> i would like to join your club my name is amanda stone d.o.b. 11-2-74 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/html Size: 384 bytes Desc: not available URL: From schear at lvcm.com Mon Aug 12 10:20:43 2002 From: schear at lvcm.com (Steve Schear) Date: Mon, 12 Aug 2002 10:20:43 -0700 Subject: BIND-PE Message-ID: <5.1.0.14.2.20020812101523.04526050@pop3.lvcm.com> BIND-PE is a "personal use" automatically installed DNS (Domain Name System) caching only name server. Similar to (but more efficient) than using your default ISP DNS servers. BIND-PE is a complete DNS Server based on the "ISC BIND 9.2.1" engine. BIND-PE once installed will act as a fully recursive and caching multi-threaded DNS Server (default), with persistent cache capabilities (cache will be maintained between reboots), this will speed up your Internet resolving queries and make name resolutions much more reliable. BIND-PE Version 1.0 distro is aimed at home/SOHO users on WinNT4 SP6, Win2000 and WinXP workstations. BIND-PE simplifies the task of installing and correctly configuring the DNS service using a completely custom BIND compile for WinNT Operating Systems with an automated "One-Click" setup process for Dial-up, Cable modem, and DSL networks for workstations. Post-install manual changes to configurations are compatible with the standard ISC BIND 9 configuration syntax and examples. For your convenience, a Control Panel similar to BIND 8 versions is active and included with on screen data details (instead of write to file). All standard as well as new TLD's (.aero etc.) are included and accessible for DNS name resolutions and browsing. Alternate TLD's like http://BBC.news and http://Atlantic.Ocean (almost 200 additional TLD's) websites which were not normally available in Legacy setups will now be viewable in browsers. http://ntcanuck.com/ From declan at well.com Mon Aug 12 07:29:32 2002 From: declan at well.com (Declan McCullagh) Date: Mon, 12 Aug 2002 10:29:32 -0400 Subject: Washington DC evacuation plan... for federal employees Message-ID: <5.1.1.6.0.20020812102921.01cad0f0@mail.well.com> 1. Government creates new Washington evacuation plan By Jason Peckenpaugh The federal government has created a new procedure for evacuating federal employees in Washington in the case of possible terrorist attacks on the nation's capital. The protocol, which took effect in May, tells who can decide to evacuate federal employees from agencies and how the government will communicate the decision to employees and to city and state agencies that would be affected by a mass exodus of civil servants from Washington. It is an attempt to improve on the ad hoc process used on Sept. 11, when the Office of Personnel Management closed federal agencies without first notifying state and transit officials in the Washington area. "Basically the only emergency plan that was available that this area had [on Sept. 11] was the snow emergency plan," said Scott Hatch, OPM's director of communications. The new protocol was designed to handle federal evacuations in Washington, but could be used to make evacuation decisions for civil servants in other cities, he said. Full story: http://www.govexec.com/dailyfed/0802/080902p1.htm Return to Top From remailer at aarg.net Mon Aug 12 10:55:19 2002 From: remailer at aarg.net (AARG! Anonymous) Date: Mon, 12 Aug 2002 10:55:19 -0700 Subject: Palladium: technical limits and implications Message-ID: <699bcf9a15f57cec8e85fb08c0c02652@aarg.net> Adam Back writes: > +---------------+------------+ > | trusted-agent | user mode | > | space | app space | > | (code +------------+ > | compartment) | supervisor | > | | mode / OS | > +---------------+------------+ > | ring -1 / TOR | > +----------------------------+ > | hardware / SCP key manager | > +----------------------------+ I don't think this works. According to Peter Biddle, the TOR can be launched even days after the OS boots. It does not underly the ordinary user mode apps and the supervisor mode system call handlers and device drivers. +---------------+------------+ | trusted-agent | user mode | | space | app space | | (code +------------+ | compartment) | supervisor | | | mode / OS | +---+ +---------------+------------+ |SCP|---| ring -1 / TOR | +---+ +---------------+ This is more how I would see it. The SCP is more like a peripheral device, a crypto co-processor, that is managed by the TOR. Earlier you quoted Seth's blog: | The nub is a kind of trusted memory manager, which runs with more | privilege than an operating system kernel. The nub also manages access | to the SCP. as justification for putting the nub (TOR) under the OS. But I think in this context "more privilege" could just refer to the fact that it is in the secure memory, which is only accessed by this ring--1 or ring-0 or whatever you want to call it. It doesn't follow that the nub has anything to do with the OS proper. If the OS can run fine without it, as I think you agreed, then why would the entire architecture have to reorient itself once the TOR is launched? In other words, isn't my version simpler, as it adjoins the column at the left to the pre-existing column at the right, when the TOR launches, days after boot? Doesn't it require less instantaneous, on-the-fly, reconfiguration of the entire structure of the Windows OS at the moment of TOR launch? And what, if anything, does my version fail to accomplish that we know that Palladium can do? > Integrity Metrics in a given level are computed by the level below. > > The TOR starts Trusted Agents, the Trusted Agents are outside the OS > control. Therefore a remote application based on remote attestation > can know about the integrity of the trusted-agent, and TOR. > > ring -1/TOR is computed by SCP/hardware; Trusted Agent is computed by > TOR; I had thought the hardware might also produce the metrics for trusted agents, but you could be right that it is the TOR which does so. That would be consistent with the "incremental extension of trust" philosophy which many of these systems seem to follow. > The parallel stack to the right: OS is computed by TOR; Application is > computed OS. No, that doesn't make sense. Why would the TOR need to compute a metric of the OS? Peter has said that Palladium does not give information about other apps running on your machine: : Note that in Pd no one but the user can find out the totality of what SW is : running except for the nub (aka TOR, or trusted operating root) and any : required trusted services. So a service could say "I will only communicate : with this app" and it will know that the app is what it says it is and : hasn't been perverted. The service cannot say "I won't communicate with this : app if this other app is running" because it has no way of knowing for sure : if the other app isn't running. > So for general applications you still have to trust the OS, but the OS > could itself have it's integrity measured by the TOR. Of course given > the rate of OS exploits especially in Microsoft products, it seems > likley that the aspect of the OS that checks integrity of loaded > applications could itself be tampered with using a remote exploit. Nothing Peter or anyone else has said indicates that this is a property of Palladium, as far as I can remember. > Probably the latter problem is the reason Microsoft introduced ring -1 > in palladium (it seems to be missing in TCPA). No, I think it is there to prevent debuggers and supervisor-mode drivers from manipulating secure code. TCPA is more of a whole-machine spec dealing with booting an OS, so it doesn't have to deal with the question of running secure code next to insecure code. From remailer at aarg.net Mon Aug 12 11:15:10 2002 From: remailer at aarg.net (AARG! Anonymous) Date: Mon, 12 Aug 2002 11:15:10 -0700 Subject: dangers of TCPA/palladium Message-ID: <93b2dd7731fbd09e50dd760ee716afb9@aarg.net> Mike Rosing wrote: > The difference is fundamental: I can change every bit of flash in my BIOS. > I can not change *anything* in the TPM. *I* control my BIOS. IF, and > only IF, I can control the TPM will I trust it to extend my trust to > others. The purpose of TCPA as spec'ed is to remove my control and > make the platform "trusted" to one entity. That entity has the master > key to the TPM. > > Now, if the spec says I can install my own key into the TPM, then yes, > it is a very useful tool. It would be fantastic in all the portables > that have been stolen from the FBI for example. Assuming they use a > password at turn on, and the TPM is used to send data over the net, > then they'd know where all their units are and know they weren't > compromised (or how badly compromised anyway). > > But as spec'ed, it is very seriously flawed. Ben Laurie replied: > Although the outcome _may_ be like this, your understanding of the TPM > is seriously flawed - it doesn't prevent your from running whatever you > want, but what it does do is allow a remote machine to confirm what you > have chosen to run. David Wagner commented: > I don't understand your objection. It doesn't look to me like Rosing > said anything incorrect. Did I miss something? > > It doesn't look like he ever claimed that TCPA directly prevents one from > running what you want to; rather, he claimed that its purpose (or effect) > is to reduce his control, to the benefit of others. His claims appear > to be accurate, according to the best information I've seen. I don't believe that is an accurate paraphrase of what Mike Rosing said. He said the purpose (not effect) was to remove (not reduce) his control, and make the platform trusted to one entity (not "for the benefit of others"). Unless you want to defend the notion that the purpose of TCPA is to *remove* user control of his machine, and make it trusted to only *one other entity* (rather than a general capability for remote trust), then I think you should accept that what he said was wrong. And Mike said more than this. He said that if he could install his own key into the TPM that would make it a very useful tool. This is wrong; it would completely undermine the trust guarantees of TCPA, make it impossible for remote observers to draw any useful conclusions about the state of the system, and render the whole thing useless. He also talked about how this could be used to make systems "phone home" at boot time. But TCPA has nothing to do with any such functionality as this. In contrast, Ben Laurie's characterization of TCPA is 100% factual and accurate. Do you at least agree with that much, even if you disagree with my criticism of Mike Rosing's comments? From remailer at aarg.net Mon Aug 12 11:15:17 2002 From: remailer at aarg.net (AARG!Anonymous) Date: Mon, 12 Aug 2002 11:15:17 -0700 Subject: responding to claims about TCPA Message-ID: David Wagner wrote: > To respond to your remark about bias: No, bringing up Document Revocation > Lists has nothing to do with bias. It is only right to seek to understand > the risks in advance. I don't understand why you seem to insinuate > that bringing up the topic of Document Revocation Lists is an indication > of bias. I sincerely hope that I misunderstood you. I believe you did, because if you look at what I actually wrote, I did not say that "bringing up the topic of DRLs is an indication of bias": > The association of TCPA with SNRLs is a perfect example of the bias and > sensationalism which has surrounded the critical appraisals of TCPA. > I fully support John's call for a fair and accurate evaluation of this > technology by security professionals. But IMO people like Ross Anderson > and Lucky Green have disqualified themselves by virtue of their wild and > inaccurate public claims. Anyone who says that TCPA has SNRLs is making > a political statement, not a technical one. My core claim is the last sentence. It's one thing to say, as you are, that TCPA could make applications implement SNRLs more securely. I believe that is true, and if this statement is presented in the context of "dangers of TCPA" or something similar, it would be appropriate. But even then, for a fair analysis, it should make clear that SNRLs can be done without TCPA, and it should go into some detail about just how much more effective a SNRL system would be with TCPA. (I will write more about this in responding to Joseph Ashwood.) And to be truly unbiased, it should also talk about good uses of TCPA. If you look at Ross Anderson's TCPA FAQ at http://www.cl.cam.ac.uk/~rja14/tcpa-faq.html, he writes (question 4): : When you boot up your PC, Fritz takes charge. He checks that the boot : ROM is as expected, executes it, measures the state of the machine; : then checks the first part of the operating system, loads and executes : it, checks the state of the machine; and so on. The trust boundary, of : hardware and software considered to be known and verified, is steadily : expanded. A table is maintained of the hardware (audio card, video card : etc) and the software (O/S, drivers, etc); Fritz checks that the hardware : components are on the TCPA approved list, that the software components : have been signed, and that none of them has a serial number that has : been revoked. He is not saying that TCPA could make SNRLs more effective. He says that "Fritz checks... that none of [the software components] has a serial number that has been revoked." He is flatly stating that the TPM chip checks a serial number revocation list. That is both biased and factually untrue. Ross's whole FAQ is incredibly biased against TCPA. I don't see how anyone can fail to see that. If it were titled "FAQ about Dangers of TCPA" at least people would be warned that they were getting a one-sided presentation. But it is positively shameful for a respected security researcher like Ross Anderson to pretend that this document is giving an unbiased and fair description. I would be grateful if someone who disagrees with me, who thinks that Ross's FAQ is fair and even-handed, would speak up. It amazes me that people can see things so differently. And Lucky's slide presentation, http://www.cypherpunks.to, is if anything even worse. I already wrote about this in detail so I won't belabor the point. Again, I would be very curious to hear from someone who thinks that his presentation was unbiased. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From miser at yahoo.com Mon Aug 12 04:36:20 2002 From: miser at yahoo.com (Dawnetta Aceuedo) Date: 12 Aug 02 11:36:20 -0000 Subject: Life Insurance Price Wars 840 Message-ID: <200208121036.g7CAZgsZ030300@sgk.sgk.pl> A non-text attachment was scrubbed... Name: not available Type: text/html Size: 1708 bytes Desc: not available URL: From aleph1 at securityfocus.com Mon Aug 12 10:45:26 2002 From: aleph1 at securityfocus.com (aleph1 at securityfocus.com) Date: Mon, 12 Aug 2002 11:45:26 -0600 Subject: Implementation of Chosen-Ciphertext Attacks against PGP and GnuPG Message-ID: Implementation of Chosen-Ciphertext Attacks against PGP and GnuPG K. Jallad, J. Katz, and B. Schneier We recently noted that PGP and other e-mail encryption protocols are, in theory, highly vulnerable to chosen-ciphertext attacks in which the recipient of the e-mail acts as an unwitting "decryption oracle." We argued further that such attacks are quite feasible and therefore represent a serious concern. Here, we investigate these claims in more detail by attempting to implement the suggested attacks. On one hand, we are able to successfully implement the described attacks against PGP and GnuPG (two widely-used software packages) in a number of different settings. On the other hand, we show that the attacks largely fail when data is compressed before encryption. Interestingly,the attacks are unsuccessful for largely fortuitous reasons; resistance to these attacks does not seem due to any conscious effort made to prevent them. Based on our work, we discuss those instances in which chosen-ciphertext attacks do indeed represent an important threat and hence must be taken into account in order to maintain confidentiality. We also recommend changes in the OpenPGP standard to reduce the effectiveness of our attacks in these settings. http://www.counterpane.com/pgp-attack.pdf http://www.counterpane.com/pgp-attack.ps.zip -- Elias Levy Symantec Alea jacta est ----- End forwarded message ----- From bill.stewart at POBOX.COM Mon Aug 12 12:06:20 2002 From: bill.stewart at POBOX.COM (Bill Stewart) Date: Mon, 12 Aug 2002 12:06:20 -0700 Subject: FAQ: How will Microsoft respond to Lucky's patent application? In-Reply-To: <012001c240bb$36f28280$6801a8c0@xpserver> Message-ID: <5.1.1.6.2.20020812120531.04566950@idiom.com> At 03:13 PM 08/10/2002 -0700, Lucky Green wrote: >Lastly, I feel obliged to mention that it is quite irrelevant what I, >Microsoft, or the subscribers to this list believe to be the case with >respect to my patent application. >All that matters is what the patent examiner at the USPTO believes. Those guys'll believe anything :-) From rah at shipwright.com Mon Aug 12 09:17:29 2002 From: rah at shipwright.com (R. A. Hettinga) Date: Mon, 12 Aug 2002 12:17:29 -0400 Subject: On the outright laughability of internet "democracy" In-Reply-To: References: Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 At 4:20 PM +0200 on 8/12/02, Nomen Nescio wrote, in excruciating, hilarious and even elegant detail: <...all about how I was trolled. :-).> > Good fish. Thank you for playing. LOL... You're welcome. Guilty as charged. I admit to being absolutely trollable about some things. It's even fun on occasion. As always, you know where the 'd' key is. Or, apparently, I can also tell you where to find it in several languages. I love the net... Meaning that, as it always has been, since people began repeating themselves about six months out from its founding, this list is just a watering hole, and not a salon. That, and you never really know how exactly you're going to get your kicks next. :-). However, if I may be permitted to flop back into the bilge a little while to add *some* content to the discussion again, my point -- well, two, actually -- still holds. 1.) You cannot have truly anonymous voting on the net without also being perfectly free to sell your vote. In short, the only voting that matters on the net is *financial* voting -- voting your control, total or fractional, of an asset of some kind. Don't take my word for it. Look it up. Read the protocols. Figure it out for yourself. It's impossible. And, in so doing you will discover something that I've also said said too much before, also to the consternation of folks like you: 2.) Financial cryptography is the *only* cryptography that matters. [If you respond to a patently content-free fulmination by an obviously trollee with another troll of your own, what, exactly, does that make you, troller -- or trollee? :-)] Cheers, RAH -----BEGIN PGP SIGNATURE----- Version: PGP 7.5 iQA/AwUBPVffd8PxH8jf3ohaEQId/gCg8bSQsIpLv67eVoLDwO8YSTL1S7UAnRA3 rpyy0mOPtS0ydZLaPz7DCyT3 =g1DF -----END PGP SIGNATURE----- -- ----------------- R. A. Hettinga The Internet Bearer Underwriting Corporation 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire' From eresrch at eskimo.com Mon Aug 12 12:41:44 2002 From: eresrch at eskimo.com (Mike Rosing) Date: Mon, 12 Aug 2002 12:41:44 -0700 (PDT) Subject: dangers of TCPA/palladium In-Reply-To: <93b2dd7731fbd09e50dd760ee716afb9@aarg.net> Message-ID: On Mon, 12 Aug 2002, AARG! Anonymous wrote: > I don't believe that is an accurate paraphrase of what Mike Rosing said. > He said the purpose (not effect) was to remove (not reduce) his control, > and make the platform trusted to one entity (not "for the benefit of > others"). Unless you want to defend the notion that the purpose of TCPA > is to *remove* user control of his machine, and make it trusted to only > *one other entity* (rather than a general capability for remote trust), > then I think you should accept that what he said was wrong. That does seem to be the purpose - but may not be what was planned - it could simply be a "fortuitous accident". There are way too many unknowns really, so conjecture is all we've got to go on. So far we know that the guys writing Palldium are not happy with TCPA - it doesn't solve their problems the way they like. We know less about the TPM. What's "right" or "wrong" about vaporware is kind of hard to pin down. There are some basic conceptual things we do know, and we know there are already commercial solutions to problems that TCPA claims to attempt to solve. I'm working from what I know about those existing devices and project that onto TCPA. I may well be wrong, and hopefully somebody who's actually building TCPA and TPM can give us concrete answers. > And Mike said more than this. He said that if he could install his own > key into the TPM that would make it a very useful tool. This is wrong; > it would completely undermine the trust guarantees of TCPA, make it > impossible for remote observers to draw any useful conclusions about the > state of the system, and render the whole thing useless. He also talked > about how this could be used to make systems "phone home" at boot time. > But TCPA has nothing to do with any such functionality as this. I have to disagree. If I control the content of the TPM, *I* can trust it, and anybody who trusts *me* can trust it too. What other remote observers of my system are there than the ones *I* trust? Or to put in another way - I only want remote observers that I trust to have the ability to check my TPM. This is what it all boils down to - "who is in charge of what?" If I create a fixed key, I can authenticate myself via multiple channels and build trust to multiple and independent parties. That is how TPM becomes useful. If somebody else controls the TPM, they may well *not* trust me, and they may put my computer to work doing something I don't like. In that case, I can not trust my computer, because my computer does not trust me. (I said may, just because it's possible doesn't mean it will happen.) What started this very long and interesting discussion was the fear that TCPA is going to be mandated by law. That is a very bad idea, and as long as the fear is real, we need some very good arguments to prevent it from happening. The main one is economic, the secondary one is that we don't need it - you can buy hardware that does the same thing off the shelf and plug it in to any generic PC. If the authors of Palladium want their software to work, they should look at the commercial hardware security computing platforms already available and get their stuff to work with it. Ditch TCPA and get your stuff on the market now, and see how people really deal with it. It will be an interesting experiment. Patience, persistence, truth, Dr. mike From sunder at sunder.net Mon Aug 12 10:46:04 2002 From: sunder at sunder.net (Sunder) Date: Mon, 12 Aug 2002 13:46:04 -0400 (edt) Subject: Thanks, Lucky, for helping to kill gnutella In-Reply-To: <8c25bf764b14de9e2d3d9cd24a6d49fb@aarg.net> Message-ID: Ok Mr. Smarty Pants Aarg! Anonymous remailer user, you come up with such a method. Cypherpunsk write code, yes? So write some code. Meanwhile, this is why it can't be done: If you have a client that sends a signature of it's binary back to it's mommy, you can also have a rogue client that sends the same signature back to it's mommy, but is a different binary. So how does mommy know which is the real client, and which is the rogue client? After all, the rogue could simply keep a copy of the real client's binary, and send the checksum/hash for the real copy, but not run it. If you embedd one half of a public key in the real client, what's to stop the attacker from reverse engineering the real client and extracting the key, then sign/encrypt things with that half of the key? Or to patch the client using a debugger so it does other things also? Or runs inside an emulator where every operation it does is logged - so that a new rogue can be built that does the same? Or runs under an OS whose kernel is patched to allow another process to access your client's memory and routines? Or has modded dynamic libraries which your client depends on to do the same, etc. Show us the code instead of asking us to write it for you. I say, you can't do it. Prove me wrong. As long as you do not have full exclusive control of the client hardware, you can't do what you ask with any degree of confidence beyond what security through obscurity buys you. In the end, if someone cares enough, they will break it. All this pointless bickering has already been discussed: A long while ago, Dennis Ritchie of K&R discussed how he introduced a backdoor into login.c, then modified the C compiler to recognize when login.c was compiled, and had it inject the back door, then removed the changes to login.c. How do you propose to have a client run in a hostile environment and securely authenticate itself without allowing rogues to take over it's function or mimic it? Either propose a way to do what you're asking us to do - which IMHO is impossible without also having some sort of cop out such as having trusted hardware, or go away and shut the fuck up. ----------------------Kaos-Keraunos-Kybernetos--------------------------- + ^ + :NSA got $20Bill/year|Passwords are like underwear. You don't /|\ \|/ :and didn't stop 9-11|share them, you don't hang them on your/\|/\ <--*-->:Instead of rewarding|monitor, or under your keyboard, you \/|\/ /|\ :their failures, we |don't email them, or put them on a web \|/ + v + :should get refunds! |site, and you must change them very often. --------_sunder_ at _sunder_._net_------- http://www.sunder.net ------------ On Fri, 9 Aug 2002, AARG! Anonymous wrote: > If only there were a technology in which clients could verify and yes, > even trust, each other remotely. Some way in which a digital certificate > on a program could actually be verified, perhaps by some kind of remote, > trusted hardware device. This way you could know that a remote system was > actually running a well-behaved client before admitting it to the net. > This would protect Gnutella from not only the kind of opportunistic > misbehavior seen today, but the future floods, attacks and DOSing which > will be launched in earnest once the content companies get serious about > taking this network down. From ben at algroup.co.uk Mon Aug 12 05:52:39 2002 From: ben at algroup.co.uk (Ben Laurie) Date: Mon, 12 Aug 2002 13:52:39 +0100 Subject: Palladium: technical limits and implications References: <51678c581368e18c35beca5d8665c528@aarg.net> Message-ID: <3D57AF97.2090501@algroup.co.uk> AARG!Anonymous wrote: > Adam Back writes: > >>I have one gap in the picture: >> >>In a previous message in this Peter Biddle said: >> >> >>>In Palladium, SW can actually know that it is running on a given >>>platform and not being lied to by software. [...] (Pd can always be >>>lied to by HW - we move the problem to HW, but we can't make it go >>>away completely). >> > > Obviously no application can reliably know anything if the OS is hostile. > Any application can be meddled with arbitrarily by the OS. In fact > every bit of the app can be changed so that it does something entirely > different. So in this sense it is meaningless to speak of an app that > can't be lied to by the OS. > > What Palladium can do, though, is arrange that the app can't get at > previously sealed data if the OS has meddled with it. The sealing > is done by hardware based on the app's hash. So if the OS has changed > the app per the above, it won't be able to get at old sealed data. I don't buy this: how does Palladium know what an app is without the OS' help? Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ Available for contract work. "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff From morlockelloi at yahoo.com Mon Aug 12 15:03:17 2002 From: morlockelloi at yahoo.com (Morlock Elloi) Date: Mon, 12 Aug 2002 15:03:17 -0700 (PDT) Subject: BIND-PE In-Reply-To: <5.1.0.14.2.20020812101523.04526050@pop3.lvcm.com> Message-ID: <20020812220317.96897.qmail@web13207.mail.yahoo.com> > All standard as well as new TLD's (.aero etc.) are included and accessible > for DNS name resolutions and browsing. Alternate TLD's like http://BBC.news > and http://Atlantic.Ocean (almost 200 additional TLD's) websites which were > not normally available in Legacy setups will now be viewable in browsers. May I guess ... it's also easy to switch to alternate root servers ... I always wanted icann.org ===== end (of original message) Y-a*h*o-o (yes, they scan for this) spam follows: HotJobs - Search Thousands of New Jobs http://www.hotjobs.com From tim at dierks.org Mon Aug 12 12:28:15 2002 From: tim at dierks.org (Tim Dierks) Date: Mon, 12 Aug 2002 15:28:15 -0400 Subject: Palladium: technical limits and implications In-Reply-To: <20020812193000.A844266@exeter.ac.uk> References: <699bcf9a15f57cec8e85fb08c0c02652@aarg.net> <699bcf9a15f57cec8e85fb08c0c02652@aarg.net> Message-ID: <5.1.0.14.2.20020812150745.03d70748@dierks.org> At 07:30 PM 8/12/2002 +0100, Adam Back wrote: >(Tim Dierks: read the earlier posts about ring -1 to find the answer >to your question about feasibility in the case of Palladium; in the >case of TCPA your conclusions are right I think). The addition of an additional security ring with a secured, protected memory space does not, in my opinion, change the fact that such a ring cannot accurately determine that a particular request is consistant with any definable security policy. I do not think it is technologically feasible for ring -1 to determine, upon receiving a request, that the request was generated by trusted software operating in accordance with the intent of whomever signed it. Specifically, let's presume that a Palladium-enabled application is being used for DRM; a secure & trusted application is asking its secure key manager to decrypt a content encryption key so it can access properly licensed code. The OS is valid & signed and the application is valid & signed. How can ring -1 distinguish a valid request from one which has been forged by rogue code which used a bug in the OS or any other trusted entity (the application, drivers, etc.)? I think it's reasonable to presume that desktop operating systems which are under the control of end-users cannot be protected against privilege escalation attacks. All it takes is one sound card with a bug in a particular version of the driver to allow any attacker to go out and buy that card & install that driver and use the combination to execute code or access data beyond his privileges. In the presence of successful privilege escalation attacks, an attacker can get access to any information which can be exposed to any privilige level he can escalate to. The attacker may not be able to access raw keys & other information directly managed by the TOR or the key manager, but those keys aren't really interesting anyway: all the interesting content & transactions will live in regular applications at lower security levels. The only way I can see to prevent this is for the OS to never transfer control to any software which isn't signed, trusted and intact. The problem with this is that it's economically infeasible: it implies the death of small developers and open source, and that's a higher price than the market is willing to bear. - Tim PS - I'm looking for a job in or near New York City. See my resume at --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From remailer at aarg.net Mon Aug 12 15:50:48 2002 From: remailer at aarg.net (AARG! Anonymous) Date: Mon, 12 Aug 2002 15:50:48 -0700 Subject: Seth on TCPA at Defcon/Usenix Message-ID: <5d30bc880936d7ce49185c1d9d42cceb@aarg.net> In discussing how TCPA would help enforce a document revocation list (DRL) Joseph Ashwood contrasted the situation with and without TCPA style hardware, below. I just want to point out that his analysis of the hardware vs software situation says nothing about DRL's specifically; in fact it doesn't even mention them. His analysis actually applies to a wide range of security features, such as the examples given earlier: secure games, improved P2P, distributed computing as Adam Back suggested, DRM of course, etc.. TCPA is a potentially very powerful security enhancement, so it does make sense that it can strengthen all of these things, and DRLs as well. But I don't see that it is fair to therefore link TCPA specifically with DRLs, when there are any number of other security capabilities that are also strengthened by TCPA. Joseph Ashwood wrote: > Actually it does, in order to make it valuable. Without a hardware assist, > the attack works like this: > Hack your software (which is in many ways almost trivial) to reveal it's > private key. > Watch the protocol. > Decrypt protocol > Grab decryption key > use decryption key > problem solved It's not always as easy as you make it sound here. Adam Back wrote Saturday about the interesting history of the giFT project, which reverse-engineered the Kazaa file-sharing protocol. That was a terrific effort that required considerable cryptographic know-how as well as supreme software reverse engineering skills. But then Kazaa changed the protocol, and giFT never managed to become compatible with the new one. I'm not sure whether it was lack of interest or just too difficult, but in any case the project failed (as far as creating an open Kazaa compatible client). It is clear that software hacking is far from "almost trivial" and you can't assume that every software-security feature can and will be broken. Furthermore, even when there is a break, it won't be available to everyone. Ordinary people aren't clued in to the hacker community and don't download all the latest patches and hacks to disable security features in their software. Likewise for business customers. In practice, if Microsoft wanted to implement a global, facist DRL, while some people might be able to patch around it, probably 95%+ of ordinary users would be stuck with it. Therefore a DRL in software would be far from useless, and if there truly was a strong commercial need for such a solution then chances are it would be there today. I might mention BTW that for email there is such a product, disappearingink.com, which works along the lines Seth suggested, I believe. It encrypts email with a centralized key, and when that email needs to be deleted, the key is destroyed. This allows corporations to implement a "document retention policy" (which is of course a euphemism for a document destruction policy) to help reduce their vulnerability to lawsuits and fishing expeditions. I don't recall anyone getting up in arms over the disappearingink.com technology or claiming that it was a threat, in the same way that DRLs and SNRLs are being presented in the context of Palladium. > With hardware assist, trusted software, and a trusted execution environment > it (doesn't) work like this: > Hack you software. > DOH!!!!! the software won't run > revert back to the stored software. > Hack the hardware (extremely difficult). > Virtualize the hardware at a second layer, using the grabbed private key > Hack the software > Watch the protocol. > Decrypt protocol > Grab decryption key > use decryption key > Once the file is released the server revokes all trust in your client, > effectively removing all files from your computer that you have not > decrypted yet > problem solved? only for valuable files First, as far as this last point, you acknowledge that if they can't tell where it came from, your hacked hardware can be an ongoing source of un-DRL'd documents. But watermarking technology so far has been largely a huge failure, so it is likely that someone clueful enough to hack his TPM could also strip away any identifying markings. Second, given that you do hack the hardware, you may not actually need to do that much in terms of protocol hacking. If you can watch the data going to and from the TPM you can extract keys directly, and that may be enough to let you decrypt the "sealed" data. (The TPM does only public key operations; the symmetric crypto is all done by the app. I don't know if Palladium will work that way or not.) Third, if a document is "liberated" via this kind of hack, it can then be distributed everywhere, outside the "secure trust perimeter" enforced by TCPA/Palladium. We are still in a "break once read anywhere" situation with documents, and any attempt to make one disappear is not going to be very successful, even with TCPA in existence. In short, while TCPA could increase the effectiveness of global DRLs, they wouldn't be *that* much more effective. Most users will neither hack their software nor their hardware, so the hardware doesn't make any difference for them. Hackers will be able to liberate documents completely from DRL controls, whether they use hardware or software to do it. The only difference is that there will be fewer hackers, if hardware is used, because it is more difficult. Depending on the rate at which important documents go on DRLs, that may not make any difference at all. > Now about the claim that MS Word would not have this "feature." It almost > certainly would. The reason being that business customers are of particular > interest to MS, since they supply a large portion of the money for Word (and > everything else). Businesses would want to be able to configure their > network in such a way that critical business information couldn't be leaked > to the outside world. Of course this removes the advertising path of > conveniently leaking carefully constructed documents to the world, but for > many companies that is a trivial loss. I agree that providing an option to store documents in restricted form could be a desirable feature for businesses. And having the ability to delete documents on a company-wide basis, a la disappearingink.com, could make sense as well. I don't know that there is a huge market for this capability, or I suspect we'd see it already. But it does make sense as an auxiliary part of a business document product. But to me this points to a localized DRL, part of a document-management library that is used solely for documents within the company. The company would want to control the administration of its documents. I don't see this leading to the kind of centralized, global system which I think opponents of TCPA are attempting to invoke when they talk about it allowing DRLs, and which is the kind of thing I was talking about above. From nobody at dizum.com Mon Aug 12 07:20:10 2002 From: nobody at dizum.com (Nomen Nescio) Date: Mon, 12 Aug 2002 16:20:10 +0200 (CEST) Subject: On the outright laughability of internet "democracy" Message-ID: On Sun, 11 Aug 2002 22:07:11 -0400, R. A. Hettinga wrote: 160 lines, 1,150 words, 6,393 characters, all insisting on describing his being guthooked, sinker eating, line chewing and flopping up into the greasy bilge, furiously spewing offense and defense, in serious, righteous and angry pursuit of the diaphanous illusion of anoned bait-spilth, becoming clearly the easiest, but also the lowest calorie catch o' the day. Back over the side with you, little fellow. Good fish. Thank you for playing. From tim at dierks.org Mon Aug 12 13:32:05 2002 From: tim at dierks.org (Tim Dierks) Date: Mon, 12 Aug 2002 16:32:05 -0400 Subject: trade-offs of secure programming with Palladium (Re: Palladium: technical limits and implications) In-Reply-To: <20020812210759.A846822@exeter.ac.uk> References: <5.1.0.14.2.20020812150745.03d70748@dierks.org> <699bcf9a15f57cec8e85fb08c0c02652@aarg.net> <699bcf9a15f57cec8e85fb08c0c02652@aarg.net> <20020812193000.A844266@exeter.ac.uk> <5.1.0.14.2.20020812150745.03d70748@dierks.org> Message-ID: <5.1.0.14.2.20020812161317.03e05818@dierks.org> At 09:07 PM 8/12/2002 +0100, Adam Back wrote: >At some level there has to be a trade-off between what you put in >trusted agent space and what becomes application code. If you put the >whole application in trusted agent space, while then all it's >application logic is fully protected, the danger will be that you have >added too much code to reasonably audit, so people will be able to >gain access to that trusted agent via buffer overflow. I agree; I think the system as you describe it could work and would be secure, if correctly executed. However, I think it is infeasible to generally implement commercially viable software, especially in the consumer market, that will be secure under this model. Either the functionality will be too restricted to be accepted by the market, or there will be a set of software flaws that allow the system to be penetrated. The challenge is to put all of the functionality which has access to content inside of a secure perimeter, while keeping the perimeter secure from any data leakage or privilege escalation. The perimeter must be very secure and well-understood from a security standpoint; for example, it seems implausible to me that any substantial portion of the Win32 API could be used from within the perimeter; thus, all user interface aspects of the application must be run through a complete security analysis with the presumption that everything outside of the perimeter is compromised and cannot be trusted. This includes all APIs & data. I think we all know how difficult it is, even for security professionals, to produce correct systems that enforce any non-trivial set of security permissions. This is true even when the items to be protected and the software functionality are very simple and straightforward (such as key management systems). I think it entirely implausible that software developed by multimedia software engineers, managing large quantities of data in a multi-operation, multi-vendor environment, will be able to deliver a secure environment. This is even more true when the attacker (the consumer) has control over the hardware & software environment. If a security bug is found & patched, the end user has no direct incentive to upgrade their installation; in fact, the most concerning end users (e.g., pirates) have every incentive to seek out and maintain installations with security faults. While a content or transaction server could refuse to conduct transactions with a user who has not upgraded their software, such a requirement can only increase the friction of commerce, a price that vendors & consumers might be quite unwilling to pay. I'm sure that the whole system is secure in theory, but I believe that it cannot be securely implemented in practice and that the implied constraints on use & usability will be unpalatable to consumers and vendors. - Tim PS - I'm looking for a job in or near New York City. See my resume at --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From adam at cypherspace.org Mon Aug 12 09:14:42 2002 From: adam at cypherspace.org (Adam Back) Date: Mon, 12 Aug 2002 17:14:42 +0100 Subject: Palladium: technical limits and implications In-Reply-To: <3D57AF97.2090501@algroup.co.uk>; from ben@algroup.co.uk on Mon, Aug 12, 2002 at 01:52:39PM +0100 References: <51678c581368e18c35beca5d8665c528@aarg.net> <3D57AF97.2090501@algroup.co.uk> Message-ID: <20020812171442.A829213@exeter.ac.uk> On Mon, Aug 12, 2002 at 01:52:39PM +0100, Ben Laurie wrote: > AARG!Anonymous wrote: > > [...] > > What Palladium can do, though, is arrange that the app can't get at > > previously sealed data if the OS has meddled with it. The sealing > > is done by hardware based on the app's hash. So if the OS has changed > > the app per the above, it won't be able to get at old sealed data. > > I don't buy this: how does Palladium know what an app is without the OS' > help? Here's a slightly updated version of the diagram I posted earlier: +---------------+------------+ | trusted-agent | user mode | | space | app space | | (code +------------+ | compartment) | supervisor | | | mode / OS | +---------------+------------+ | ring -1 / TOR | +----------------------------+ | hardware / SCP key manager | +----------------------------+ Integrity Metrics in a given level are computed by the level below. The TOR starts Trusted Agents, the Trusted Agents are outside the OS control. Therefore a remote application based on remote attestation can know about the integrity of the trusted-agent, and TOR. ring -1/TOR is computed by SCP/hardware; Trusted Agent is computed by TOR; The parallel stack to the right: OS is computed by TOR; Application is computed OS. So for general applications you still have to trust the OS, but the OS could itself have it's integrity measured by the TOR. Of course given the rate of OS exploits especially in Microsoft products, it seems likley that the aspect of the OS that checks integrity of loaded applications could itself be tampered with using a remote exploit. Probably the latter problem is the reason Microsoft introduced ring -1 in palladium (it seems to be missing in TCPA). Adam -- http://www.cypherspace.org/adam/ --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From adam at cypherspace.org Mon Aug 12 11:30:00 2002 From: adam at cypherspace.org (Adam Back) Date: Mon, 12 Aug 2002 19:30:00 +0100 Subject: Palladium: technical limits and implications In-Reply-To: <699bcf9a15f57cec8e85fb08c0c02652@aarg.net>; from remailer@aarg.net on Mon, Aug 12, 2002 at 10:55:19AM -0700 References: <699bcf9a15f57cec8e85fb08c0c02652@aarg.net> Message-ID: <20020812193000.A844266@exeter.ac.uk> Peter Biddle, Brian LaMacchia or other Microsoft employees could short-cut this guessing game at any point by coughing up some details. Feel free guys... enciphering minds want to know how it works. (Tim Dierks: read the earlier posts about ring -1 to find the answer to your question about feasibility in the case of Palladium; in the case of TCPA your conclusions are right I think). On Mon, Aug 12, 2002 at 10:55:19AM -0700, AARG!Anonymous wrote: > Adam Back writes: > > +---------------+------------+ > > | trusted-agent | user mode | > > | space | app space | > > | (code +------------+ > > | compartment) | supervisor | > > | | mode / OS | > > +---------------+------------+ > > | ring -1 / TOR | > > +----------------------------+ > > | hardware / SCP key manager | > > +----------------------------+ > > I don't think this works. According to Peter Biddle, the TOR can be > launched even days after the OS boots. I thought we went over this before? My hypothesis is: I presumed there would be a stub TOR loaded bvy the hardware. The hardware would allow you to load a new TOR (presumably somewhat like loading a new BIOS -- the TOR and hardware has local trusted path to some IO devices). > It does not underly the ordinary user mode apps and the supervisor > mode system call handlers and device drivers. I don't know what leads you to this conclusion. > +---------------+------------+ > | trusted-agent | user mode | > | space | app space | > | (code +------------+ > | compartment) | supervisor | > | | mode / OS | > +---+ +---------------+------------+ > |SCP|---| ring -1 / TOR | > +---+ +---------------+ How would the OS or user mode apps communicate with trusted agents with this model? The TOR I think would be the mediator of these communications (and of potential communications between trusted agents). Before loading a real TOR, the stub TOR would not implement talking to trusted agents. I think this is also more symmstric and therefore more likely. The trusted agent space is the same as supervisor mode that the OS runs in. It's like virtualization in OS360: there are now multiple "OSes" operating under a micro-kernel (the TOR in ring -1): the real OS and the multiple trusted agents. The TOR is supposed to be special purpose, simple and small enough to be audited as secure and stand a chance of being so. The trusted agents are the secure parts of applications (dealing with sealing, remote attestation, DRM, authenticated path to DRM implementing graphics cards, monitors, sound cards etc; that kind of thing). Trusted agents should also be small, simple special purpose to avoid them also suffering from remote compromise. There's limited point putting a trusted agent in a code compartment if it becomes a full blown complex application like MS word, because then the trusted agent would be nearly as likely to be remotely exploited as normal OSes. > [...] It doesn't follow that the nub has anything to do with the OS > proper. If the OS can run fine without it, as I think you agreed, > then why would the entire architecture have to reorient itself once > the TOR is launched? trusted-agents will also need to use OS services, the way you have it they can't. > In other words, isn't my version simpler, as it adjoins the column at > the left to the pre-existing column at the right, when the TOR launches, > days after boot? Doesn't it require less instantaneous, on-the-fly, > reconfiguration of the entire structure of the Windows OS at the moment > of TOR launch? I don't think it's a big problem to replace a stub TOR with a given TOR sometime after OS boot. It's analogous to modifying kernel code with a kernel module, only a special purpose micro-kernel in ring -1 instead of ring 0. No big deal. > > The parallel stack to the right: OS is computed by TOR; Application is > > computed OS. > > No, that doesn't make sense. Why would the TOR need to compute a metric > of the OS? In TCPA which does not have a ring -1, this is all the TPM does (compute metrics on the OS, and then have the OS compute metrics on applications. While Trusted Agent space is separate and better protected as there are fewer lines of code that a remote exploit has to be found in to compromise one of them, I hardly think Palladium would discard the existing windows driver signing, code signing scheme. It also seems likely therefore that even though it offers lower assurance the code signing would be extended to include metrics and attestation for the OS, drivers and even applications. > Peter has said that Palladium does not give information about other > apps running on your machine: I take this to mean that as stated somewhere in the available docs the OS can not observe or even know how many trusted agents are running. So he's stating that they've made OS design decisions such that the OS could not refuse to run some code on the basis that a given Trusted Agent is running. This functionality however could be implemented if so desired in the TOR. Adam -- http://www.cypherspace.org/adam/ From mattlaclear at core.com Mon Aug 12 17:07:52 2002 From: mattlaclear at core.com (Lead Generation) Date: Mon, 12 Aug 2002 20:07:52 -0400 Subject: Lead Generation Message-ID: <200208130002.g7D02eD6026339@ak47.algebra.com> A non-text attachment was scrubbed... Name: not available Type: text/html Size: 2622 bytes Desc: not available URL: From eresrch at eskimo.com Mon Aug 12 20:38:01 2002 From: eresrch at eskimo.com (Mike Rosing) Date: Mon, 12 Aug 2002 20:38:01 -0700 (PDT) Subject: Seth on TCPA at Defcon/Usenix In-Reply-To: <5d30bc880936d7ce49185c1d9d42cceb@aarg.net> Message-ID: On Mon, 12 Aug 2002, AARG! Anonymous wrote: > It is clear that software hacking is far from "almost trivial" and you > can't assume that every software-security feature can and will be broken. Anyone doing "security" had better assume software can and will be broken. That's where you *start*. > Furthermore, even when there is a break, it won't be available to > everyone. Ordinary people aren't clued in to the hacker community > and don't download all the latest patches and hacks to disable > security features in their software. Likewise for business customers. > In practice, if Microsoft wanted to implement a global, facist DRL, > while some people might be able to patch around it, probably 95%+ of > ordinary users would be stuck with it. Yes, this the problem with security today. That's why lots of people are advocating that the OS should be built from the ground up with security as the prime goal rather than ad hoc addons as it is now. Nobody wants to pay for it tho :-) > In short, while TCPA could increase the effectiveness of global DRLs, > they wouldn't be *that* much more effective. Most users will neither > hack their software nor their hardware, so the hardware doesn't make > any difference for them. Hackers will be able to liberate documents > completely from DRL controls, whether they use hardware or software > to do it. The only difference is that there will be fewer hackers, > if hardware is used, because it is more difficult. Depending on the > rate at which important documents go on DRLs, that may not make any > difference at all. So what's the point of TCPA if a few hackers can steal the most expensive data? Are you now admitting TCPA is broken? You've got me very confused now! I'm actually really confused about the whole DRM business anyway. It seems to me that any data available to human perceptions can be duplicated. Period. The idea of DRM (as I understand it) is that you can hand out data to people you don't trust, and they can't copy it. To me, DRM seems fundamentally impossible. Patience, persistence, truth, Dr. mike From adam at cypherspace.org Mon Aug 12 13:07:59 2002 From: adam at cypherspace.org (Adam Back) Date: Mon, 12 Aug 2002 21:07:59 +0100 Subject: trade-offs of secure programming with Palladium (Re: Palladium: technical limits and implications) In-Reply-To: <5.1.0.14.2.20020812150745.03d70748@dierks.org>; from tim@dierks.org on Mon, Aug 12, 2002 at 03:28:15PM -0400 References: <699bcf9a15f57cec8e85fb08c0c02652@aarg.net> <699bcf9a15f57cec8e85fb08c0c02652@aarg.net> <20020812193000.A844266@exeter.ac.uk> <5.1.0.14.2.20020812150745.03d70748@dierks.org> Message-ID: <20020812210759.A846822@exeter.ac.uk> I think you are making incorrect presumptions about how you would use Palladium hardware to implement a secure DRM system. If used as you suggest it would indeed suffer the vulnerabilities you describe. The difference between an insecure DRM application such as you describe and a secure DRM application correctly using the hardware security features is somewhat analogous to the current difference between an application that relies on not being reverse engineered for it's security vs one that encrypts data with a key derived from a user password. In a Palladium DRM application done right everything which sees keys and plaintext content would reside inside Trusted Agent space, inside DRM enabled graphics cards which retrict access to video RAM, and later DRM enabled monitors with encrypted digital signal to the monitor, and DRM enabled soundcards, encrypted content to speakers. (The encrypted contentt to media related output peripherals is like HDCP, only done right with non-broken crypto). Now all that will be in application space that you can reverse engineer and hack on will be UI elements and application logic that drives the trusted agent, remote attesation, content delivery and hardware. At no time will keys or content reside in space that you can virtualize or debug. In the short term it may be that some of these will be not fully implemented so that content does pass through OS or application space, or into non DRM video cards and non DRM monitors, but the above is the end-goal as I understand it. As you can see there is still the limit of the non-remote exploitability of the trusted agent code, but this is within the control of the DRM vendor. If he does a good job of making a simple software architecture and avoiding potential for buffer overflows he stands a much better chance of having a secure DRM platofrm than if as you describe exploited OS code or rogue driver code can subvert his application. There is also I suppose possibility to push content decryption on to the DRM video card so the TOR does little apart from channel key exchange messages from the SCP to the video card, and channel remote attestation and key exchanges between the DRM license server and the SCP. The rest would be streaming encrypted video formats such as CSS VOB blocks (only with good crypto) from the network or disk to the video card. Similar kinds of arguments about the correct break down between application logic and placement of security policy enforcing code in Trusted Agent space apply to general applications. For example you could imagine a file sharing application which hid the data the users machine was serving from the user. If you did it correctly, this would be secure to the extent of the hardware tamper resistance (and the implementers ability to keep the security policy enforcing code line-count down and audit it well). At some level there has to be a trade-off between what you put in trusted agent space and what becomes application code. If you put the whole application in trusted agent space, while then all it's application logic is fully protected, the danger will be that you have added too much code to reasonably audit, so people will be able to gain access to that trusted agent via buffer overflow. So therein lies the crux of secure software design in the Palladium style secure application space: choosing a good break-down between security policy enforcement, and application code. There must be a balance, and what makes sense and is appropriate depends on the application and the limits of the ingenuity of the protocol designer in coming up with clever designs that cover to hardware tamper resistant levels the the applications desired policy enforcement while providing a workably small and pracitcally auditable associated trusted agent module. So there are practical limits stemming from realities to do with code complexity being inversely proportional to auditability and security, but the extra ring -1, remote attestation, sealing and integrity metrics really do offer some security advantages over the current situation. Adam On Mon, Aug 12, 2002 at 03:28:15PM -0400, Tim Dierks wrote: > At 07:30 PM 8/12/2002 +0100, Adam Back wrote: > >(Tim Dierks: read the earlier posts about ring -1 to find the answer > >to your question about feasibility in the case of Palladium; in the > >case of TCPA your conclusions are right I think). > > The addition of an additional security ring with a secured, protected > memory space does not, in my opinion, change the fact that such a ring > cannot accurately determine that a particular request is consistant with > any definable security policy. I do not think it is technologically > feasible for ring -1 to determine, upon receiving a request, that the > request was generated by trusted software operating in accordance with the > intent of whomever signed it. > > Specifically, let's presume that a Palladium-enabled application is being > used for DRM; a secure & trusted application is asking its secure key > manager to decrypt a content encryption key so it can access properly > licensed code. The OS is valid & signed and the application is valid & > signed. How can ring -1 distinguish a valid request from one which has been > forged by rogue code which used a bug in the OS or any other trusted entity > (the application, drivers, etc.)? > > I think it's reasonable to presume that desktop operating systems which are > under the control of end-users cannot be protected against privilege > escalation attacks. All it takes is one sound card with a bug in a > particular version of the driver to allow any attacker to go out and buy > that card & install that driver and use the combination to execute code or > access data beyond his privileges. > > In the presence of successful privilege escalation attacks, an attacker can > get access to any information which can be exposed to any privilige level > he can escalate to. The attacker may not be able to access raw keys & other > information directly managed by the TOR or the key manager, but those keys > aren't really interesting anyway: all the interesting content & > transactions will live in regular applications at lower security levels. > > The only way I can see to prevent this is for the OS to never transfer > control to any software which isn't signed, trusted and intact. The problem > with this is that it's economically infeasible: it implies the death of > small developers and open source, and that's a higher price than the market > is willing to bear. > > - Tim --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From adam at cypherspace.org Mon Aug 12 14:13:58 2002 From: adam at cypherspace.org (Adam Back) Date: Mon, 12 Aug 2002 22:13:58 +0100 Subject: trade-offs of secure programming with Palladium (Re: Palladium: technical limits and implications) In-Reply-To: <5.1.0.14.2.20020812161317.03e05818@dierks.org>; from tim@dierks.org on Mon, Aug 12, 2002 at 04:32:05PM -0400 References: <5.1.0.14.2.20020812150745.03d70748@dierks.org> <699bcf9a15f57cec8e85fb08c0c02652@aarg.net> <699bcf9a15f57cec8e85fb08c0c02652@aarg.net> <20020812193000.A844266@exeter.ac.uk> <5.1.0.14.2.20020812150745.03d70748@dierks.org> <20020812210759.A846822@exeter.ac.uk> <5.1.0.14.2.20020812161317.03e05818@dierks.org> Message-ID: <20020812221358.A832443@exeter.ac.uk> At this point we largely agree, security is improved, but the limit remains assuring security of over-complex software. To sum up: The limit of what is securely buildable now becomes what is securely auditable. Before, without the Palladium the limit was the security of the OS, so this makes a big difference. Yes some people may design over complex trusted agents, with sloppy APIs and so forth, but the nice thing about trusted agents are they are compartmentalized: If the MPAA and Microsoft shoot themselves in the foot with a badly designed over complex DRM trusted agent component for MS Media Player, it has no bearing on my ability to implement a secure file-sharing or secure e-cash system in a compartment with rigorously analysed APIs, and well audited code. The leaky compromised DRM app can't compromise the security policies of my app. Also it's unclear from the limited information available but it may be that trusted agents, like other ring-0 code (eg like the OS itself) can delegate tasks to user mode code running in trusted agent space, which can't examine other user level space, nor the space of the trusted agent which stated them, and also can't be examined by the OS. In this way for example remote exploits could be better contained in the sub-division of trusted agent code. eg. The crypto could be done by the trusted-agent proper, the mpeg decoding by a user-mode component; compromise the mpeg-decoder, and you just get plaintext not keys. Various divisions could be envisaged. Given that most current applications don't even get the simplest of applications of encryption right (store key and password in the encrypted file, check if the password is right by string comparison is suprisingly common), the prospects are not good for general applications. However it becomes more feasible to build secure applications in the environment where it matters, or the consumer cares sufficiently to pay for the difference in development cost. Of course all this assumes microsoft manages to securely implement a TOR and SCP interface. And whether they manage to succesfully use trusted IO paths to prevent the OS and applications from tricking the user into bypassing intended trusted agent functionality (another interesting sub-problem). CC EAL3 on the SCP is a good start, but they have pressures to make the TOR and Trusted Agent APIs flexible, so we'll see how that works out. Adam -- http://www.cypherspace.org/adam/ On Mon, Aug 12, 2002 at 04:32:05PM -0400, Tim Dierks wrote: > At 09:07 PM 8/12/2002 +0100, Adam Back wrote: > >At some level there has to be a trade-off between what you put in > >trusted agent space and what becomes application code. If you put the > >whole application in trusted agent space, while then all it's > >application logic is fully protected, the danger will be that you have > >added too much code to reasonably audit, so people will be able to > >gain access to that trusted agent via buffer overflow. > > I agree; I think the system as you describe it could work and would be > secure, if correctly executed. However, I think it is infeasible to > generally implement commercially viable software, especially in the > consumer market, that will be secure under this model. Either the > functionality will be too restricted to be accepted by the market, or there > will be a set of software flaws that allow the system to be penetrated. > > The challenge is to put all of the functionality which has access to > content inside of a secure perimeter, while keeping the perimeter secure > from any data leakage or privilege escalation. [...] --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From remailer at aarg.net Mon Aug 12 23:55:14 2002 From: remailer at aarg.net (AARG! Anonymous) Date: Mon, 12 Aug 2002 23:55:14 -0700 Subject: Another application for trusted computing Message-ID: <4ef29e56fbb8a06e34fb5369fecbf741@aarg.net> I thought of another interesting application for trusted computing systems: mobile agents. These are pieces of software which get transferred from computer to computer, running on each system, communicating with the local system and other visiting agents, before migrating elsewhere. This was a hot technology from a couple of years ago, but it never really went anywhere (so to speak). Part of the reason was that there wasn't that much functionality for agents which couldn't be done better in other ways. But a big part of it was problems with security. One issue was protecting the host from malicious agents, and much work was done in that direction. This was one of the early selling points of Java, and other sandbox systems were developed as well. Likewise the E language is designed to solve this problem. But the much harder problem was protecting the agent from malicious hosts. Once an agent transferred into a host machine, it was essentially at the mercy of that system. The host could lie to the agent, and even manipulate its memory and program, to make it do anything it desired. Without the ability to maintain its own integrity, the agent was relatively useless in many ecommerce applications. Various techniques were suggested to partially address this, such as splitting the agent functional