Re: Challenge to TCPA/Palladium detractors
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 | - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Seth on TCPA at Defcon/Usenix
- Original Message - From: "AARG! Anonymous" <[EMAIL PROTECTED]> [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 [EMAIL PROTECTED]
Re: Thanks, Lucky, for helping to kill gnutella
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 [EMAIL PROTECTED]
Seth on TCPA at Defcon/Usenix
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 [EMAIL PROTECTED]
FAQ: How will Microsoft respond to Lucky's patent application?
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 ant
Re: Thanks, Lucky, for helping to kill gnutella
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 [EMAIL PROTECTED]
Re: responding to claims about TCPA
AARG!Anonymous <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] www.ihtfp.com - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: adding noise blob to data before signing
Nomen Nescio <[EMAIL PROTECTED]> writes: > Derek Atkins replied: > > It depends on the signature algorithm. With RSA you can sign any > > message "directly" if said message is smaller than the public key size > > (N). DSA, however, requires the use of a hash. > > Actually, depending on the data being signed, it can be important to > hash for RSA. After all, RSA is existentially forgeable: anyone can > forge a signature on a *random* value (if C=M^e mod n, then M is a > signature on C). They might be able to try some large number of sigs > until they got a random value which looked enough like legitimate data > to be accepted - especially possible if the 1kbit value being signed > holds dense, random-ish binary data. Let me be clear: I implied (but clearly I should have been explicit) that PKCS#1 padding should be used, not "raw" RSA. The problem with raw RSA is that you can combine multiple encryptions into new encryptions. Using PKCS padding inside the RSA signature foils the multiplication attack. So, sure, your message is can only be N-(sizeof(pkcs#1)) bits, not N bits. However you still do not need a hash. -derek -- Derek Atkins Computer and Internet Security Consultant [EMAIL PROTECTED] www.ihtfp.com - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
RE: Challenge to David Wagner on TCPA
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 [EMAIL PROTECTED]
Re: responding to claims about TCPA
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 t
Re: adding noise blob to data before signing
Eugen Leitl asked: > 1) What's the name of the technique of salting/padding an small integer >I'm signing with random data? You shouldn't need to salt/pad with random data, fixed data should be OK. > 2) If I'm signing above short (~1 kBit) sequences, can I sign them >directly, or am I supposed to hash them first? (i.e. does a presence >of an essentially fixed field weaken the signature) Derek Atkins replied: > It depends on the signature algorithm. With RSA you can sign any > message "directly" if said message is smaller than the public key size > (N). DSA, however, requires the use of a hash. Actually, depending on the data being signed, it can be important to hash for RSA. After all, RSA is existentially forgeable: anyone can forge a signature on a *random* value (if C=M^e mod n, then M is a signature on C). They might be able to try some large number of sigs until they got a random value which looked enough like legitimate data to be accepted - especially possible if the 1kbit value being signed holds dense, random-ish binary data. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Thanks, Lucky, for helping to kill gnutella
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 - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: adding noise blob to data before signing
Derek Atkins <[EMAIL PROTECTED]> writes: > Eugen Leitl <[EMAIL PROTECTED]> writes: > > > 2) If I'm signing above short (~1 kBit) sequences, can I sign them > >directly, or am I supposed to hash them first? (i.e. does a presence > >of an essentially fixed field weaken the signature) > > It depends on the signature algorithm. With RSA you can sign any > message "directly" if said message is smaller than the public key size > (N). DSA, however, requires the use of a hash. > > Note that, in the grand scheme of things, performing the public key > operation is significantly slower than performing the hash, so it > really doesn't hurt you computationally to perform the hash. OTOH, > your signature strength still depends on the strength of your hash. It's generally a bad idea to sign RSA data directly. The RSA primitive is actually quite fragile. At the very least you should PKCS-1 pad the data. -Ekr -- [Eric Rescorla [EMAIL PROTECTED]] http://www.rtfm.com/ - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: adding noise blob to data before signing
Eugen Leitl <[EMAIL PROTECTED]> writes: > 1) What's the name of the technique of salting/padding an small integer >I'm signing with random data? Blinding? Padding? It depends on what you are trying to accomplish. > 2) If I'm signing above short (~1 kBit) sequences, can I sign them >directly, or am I supposed to hash them first? (i.e. does a presence >of an essentially fixed field weaken the signature) It depends on the signature algorithm. With RSA you can sign any message "directly" if said message is smaller than the public key size (N). DSA, however, requires the use of a hash. Note that, in the grand scheme of things, performing the public key operation is significantly slower than performing the hash, so it really doesn't hurt you computationally to perform the hash. OTOH, your signature strength still depends on the strength of your hash. -derek -- Derek Atkins Computer and Internet Security Consultant [EMAIL PROTECTED] www.ihtfp.com - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Thanks, Lucky, for helping to kill gnutella
Wow, this conversation has been fun. Thanks, Anonymous Aarg, for taking up the unpopular side of the debate. I'll spare any question about motives. I think most of us would agree that having a trusted computing environment makes some interesting things possible. Smartcards, afterall, are more or less the same idea as Palladium, just on a smaller scale. You're right to point out they could make things like a trusted Gnutella client possible, or do SETI@Home style distributed computing in a secure manner, or... But the context of Palladium is larger than what a few smart P2P folks could do. Palladium is a technology proposed by a convicted predatory monopolist. It is a technology that gives that monopolist even more control over the uses of its technology. And it just so happens to be exactly in line with the needs of the entertainment industry which has spent the past few years doing their best to squelch creative uses of the Internet so they can jealously protect their copyright hegemony. We'd be crazy not to be a little concerned. Let's turn the debate to a slightly more interesting place. Is there a way to create a trusted computing environment such as Palladium that does not also enable the restrictionof liberties? The "optional" aspect of Palladium isn't enough - the folks who own the media will ensure that it can only be played if your computer is in trusted mode. [EMAIL PROTECTED] . . . .. . . . http://www.media.mit.edu/~nelson/ - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Challenge to David Wagner on TCPA
Lucky Green wrote: > Ray wrote: > >>>From: "James A. Donald" <[EMAIL PROTECTED]> >>>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 [EMAIL PROTECTED]
Re: Challenge to TCPA/Palladium detractors
> Date: Fri, 9 Aug 2002 19:30:09 -0700 > From: AARG!Anonymous <[EMAIL PROTECTED]> > 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 [EMAIL PROTECTED]
Re: Thanks, Lucky, for helping to kill gnutella
> Date: Fri, 9 Aug 2002 20:25:40 -0700 > From: AARG!Anonymous <[EMAIL PROTECTED]> > 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 [EMAIL PROTECTED]
Re: Utilizing Palladium against software piracy
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 [EMAIL PROTECTED]
Re: responding to claims about TCPA
> 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 publ
adding noise blob to data before signing
1) What's the name of the technique of salting/padding an small integer I'm signing with random data? 2) If I'm signing above short (~1 kBit) sequences, can I sign them directly, or am I supposed to hash them first? (i.e. does a presence of an essentially fixed field weaken the signature) - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
It won't happen here (was Re: TCPA/Palladium -- likely future implications)
From: "AARG! Anonymous" <[EMAIL PROTECTED]> > 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 - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Thanks, Lucky, for helping to kill gnutella
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. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
p2p DoS resistance and network stability (Re: Thanks, Lucky, for helping to kill gnutella)
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 [EMAIL PROTECTED]
