- cypherpunks-legacy - lists.cpunks.org

RE: Challenge to David Wagner on TCPA
by Wall, Kevin 02 Aug '02

02 Aug '02

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

1 0

RE: Challenge to David Wagner on TCPA
by AARG! Anonymous 02 Aug '02

02 Aug '02

Sampo Syreeni writes: > On 2002-08-01, AARG!Anonymous uttered to ptrei(a)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.

1 0

Freedom of association denied in Ventura Cty
by Major Variola (ret) 02 Aug '02

02 Aug '02

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

3 2

RE: Challenge to David Wagner on TCPA
by AARG! Anonymous 01 Aug '02

01 Aug '02

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?

4 3

document popularity estimation / amortizable hashcash (Re: Hollywood Hackers)
by Adam Back 01 Aug '02

01 Aug '02

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

1 1

Re: Challenge to David Wagner on TCPA
by AARG!Anonymous 01 Aug '02

01 Aug '02

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

3 2

thoughtcrime, art, mandatory youth education camps, AP, kirkland
by Major Variola (ret) 01 Aug '02

01 Aug '02

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

1 0

15 ways to start your first email
by Matchnews＠match.com 01 Aug '02

01 Aug '02

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&Banner… SRW27 http://www.match.com/spotlight/showprofile.asp?UserID=42454B44464C494D&Bann… 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.

1 0

Re: Mandatory hardware
by Michael Motyka 01 Aug '02

01 Aug '02

"Major Variola $ret$" <mv(a)cdc.gov> 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. > <snip> > 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.

1 0

Mandatory hardware
by Major Variola (ret) 01 Aug '02

01 Aug '02

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. <snip> http://news.yahoo.com/news?tmpl=story2&cid=711&ncid=738&e=8&u=/usatoday/200… 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?

2 1