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]
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]
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]
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]
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 public had an accurate 20-page
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: 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: 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: 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: 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
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
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: 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 the release or use of that data only in the presence of a particular
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: 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: 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: 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]
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]
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: 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]
