August 2002 - cypherpunks-legacy

Discreet Extramarital Dating ............................................................................ rptm
by hil__Kelly 07 Aug '02

07 Aug '02

1 0

Hetts memory hole
by Matthew X 07 Aug '02

07 Aug '02

>>> By PAUL KRUGMAN ...a well-known crypto-anarchist and anarchocapitalist. ;-) Cheers, RAH << R. A. Hettinga Well known false prophet and crashing bore. 'Trifecta' gets a mention at http://www.mediawhoresonline.com/ Scroll down.I cant keep feeding you like babies. "We have always been at war with Oceania bin laden."

1 0

Re: dangers of TCPA/palladium
by Adam Back 07 Aug '02

07 Aug '02

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

1 0

RE: dangers of TCPA/palladium
by Eugen Leitl 07 Aug '02

07 Aug '02

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.

1 0

CodeCon 2003 Call for Papers
by Len Sassaman 07 Aug '02

07 Aug '02

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(a)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(a)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(a)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(a)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.

1 0

NYTimes.com Article: The Memory Hole
by mean-green＠hushmail.com 06 Aug '02

06 Aug '02

This article from NYTimes.com has been sent to you by mean-green(a)hushmail.com. Increasing comparisons in NYT to Bush admin and 1984 tactics. mean-green(a)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… 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(a)nytimes.com or visit our online media kit at http://www.nytimes.com/adinfo For general information about NYTimes.com, write to help(a)nytimes.com. Copyright 2002 The New York Times Company

2 1

RE: dangers of TCPA/palladium
by Sunder 06 Aug '02

06 Aug '02

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_(a)_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?

1 0

Re: dangers of TCPA/palladium
by Greg Newby 06 Aug '02

06 Aug '02

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?

1 0

RE: dangers of TCPA/palladium
by R. A. Hettinga 06 Aug '02

06 Aug '02

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 <mailto: rah(a)ibuc.com> The Internet Bearer Underwriting Corporation <http://www.ibuc.com/> 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'

1 0

Re: dangers of TCPA/palladium
by AARG!Anonymous 06 Aug '02

06 Aug '02

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(a)wasabisystems.com

1 0