Re: 128 bit number T-shirt?
I'd like one with Wearing an integer is not circumvention. on the back or some such. :) Large Integers are Not A Crime :-) On the other hand, isn't the key really an MD5 hash of some haiku about OK, so we know that DVD-CSS was Just Not Good Enough ? - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Such a touching song
http://www.youtube.com/watch?v=L9HaNbsIfp0 James S. Tyre [EMAIL PROTECTED] Law Offices of James S. Tyre 310-839-4114/310-839-4602(fax) 10736 Jefferson Blvd., #512 Culver City, CA 90230-4969 Co-founder, The Censorware Project http://censorware.net Policy Fellow, Electronic Frontier Foundation http://www.eff.org - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Public key encrypt-then-sign or sign-then-encrypt?
* Travis H.: Also there's a semantic issue; am I attesting to the plaintext, or the ciphertext? It's possible the difference could be important. With sign, then encrypt, it's also possible that the receiver decrypts the message, and then leaks it, potentially giving the impression that the signer authorized the disclosure. There has been a fair bit of buzz about this confusion. But the lesson from that seems to be that signature semantics are very hard to agree upon, and most marginally successful standards sidestep the issue anyway, acting as a mere transport protocol. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: 128 bit number T-shirt?
At 20:59 -0400 1/5/07, Perry E. Metzger wrote: http://www.cafepress.com/09f9 There is also http://www.cafepress.com/09f911029d74e35 Which has a wider range of extra artwork. f - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: phone encryption technology becoming popular in Italy
A notable mention is http://www.cryptophone.com/ . They are the only secure phone provider that allows for independent review of the source code. On 4/30/07, Steven M. Bellovin [EMAIL PROTECTED] wrote: According to an NY Times article (http://news.com.com/Phone+taps+in+Italy+spur+rush+toward+encryption/2100-1029_3-6180118.html?tag=nefd.top), phone encryption technology is becoming popular in Italy because of many recent incidents of conversations being published. Sometimes, a wiretap is being leaked; other times, it seems to be private behavior: What has spurred encryption sales is not so much the legal wiretapping authorized by Italian magistrates--though information about those calls is also frequently leaked to the press--but the widespread availability of wiretapping technology over the Internet, which has created a growing pool of amateur eavesdroppers. Those snoops have a ready market in the Italian media for filched celebrity conversations. --Steve Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] -- Saqib Ali, CISSP, ISSAP http://www.full-disk-encryption.net - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
2nd Benelux Workshop on Information and System Security (WISSEC)
Dear cryptographers, Prof. Sjouke Mauw and myself would like to invite you and your students to submit research papers to the 2nd Benelux Workshop on Information and System Security (WISSEC) which will take place *September 20-21, 2007 in Luxembourg. * The purpose of the workshop is to share ideas, experiences and information on the following, or related, topics: - Design and analysis of cryptographic algorithms - Cryptographic and security protocols, formal verification - Network security, Internet security, Wireless security - Security for embedded systems, smart cards and RFID - Security of software and hardware systems - Privacy enhancing technologies - E-voting, e-banking, e-government - Financial cryptography and security - Content protection, DRM, watermarking - Biometrics - Standards for information security - Legal and social aspect of information security - Ethical hacking, protection against malware, spam * *Please visit the web-site to see the call for papers:* *http://wissec2007.uni.lu/ The submission server of WISSec 2007 is now open at: https://wissec2007.uni.lu/iChair/ Please encourage your colleagues and students to submit papers for the evaluation and feel free to advertise WISSec 2007! Thank you for your help, The WISSec 2007 program co-chairs Alex Biryukov and Sjouke Mauw. P.S: sorry if you get this mail twice.
Re: Public key encrypt-then-sign or sign-then-encrypt?
Florian Weimer wrote: With sign, then encrypt, it's also possible that the receiver decrypts the message, and then leaks it, potentially giving the impression that the signer authorized the disclosure. There has been a fair bit of buzz about this confusion. But the lesson from that seems to be that signature semantics are very hard to agree upon, and most marginally successful standards sidestep the issue anyway, acting as a mere transport protocol. re: http://www.garlic.com/~lynn/aadsm26.htm#62 Public key encrypt-then-sign or sign-then-encrypt? http://www.garlic.com/~lynn/aadsm26.htm#63 Public key encrypt-then-sign or sign-then-encrypt? there is the issue for some kinds of operations of having integral authentication and integrity or integral authentication and privacy ... or integral privacy and integrity. so there is the whole issue of semantic confusion with the term digital signature because it contains the word signature ... leading to confusion that it might somehow be related to human signature ... aka things like intent and a human having read, understood, approves, agrees, and/or authorizes. on the other hand ... digital signatures can get into various kinds of dual-use attacks ... when the same private key is being used in a purely authentication protocol (server sends random data to be digitally signed ... as countermeasure to replay attack) ... and also in a authentication+integrity protocol ... where the contents being digitally signed is presumed to carry some sort of meaning (and that a digital just happens to be performed ... carries some additional implication other than authentication+integrity). there is this slightly x-over thread from sci.crypt http://www.garlic.com/~lynn/2007i.html#63 public key password authentication http://www.garlic.com/~lynn/2007i.html#73 public key password authentication http://www.garlic.com/~lynn/2007i.html#74 public key password authentication where there is possibly the suggestion that if the only thing being performed is authentication (and doesn't require either integrity and/or privacy) ... then possibly a totally different protocol by utilized (rather than digital signature) ... to help minimize the apparent extensive (human) confusion where the same technology might be used for both authentication only operations as well as authentication plus integrity operations (and where having the word signature in the term also appears to contribute significant additional confusion). however, in the x-over thread from sci.crypt ... i mention that if both authentication and integrity are both required ... that potentially if they are done as separate operation ... that there can be (security) openings provided to attackers for things like man-in-the-middle attacks. in the naked transaction metaphor mentioned in these postings http://www.garlic.com/~lynn/subintegrity.html#payments it is possible that if authentication is performed separately from any integrity provisions applied to the actual transactions ... that it may be an opening for a man-in-the-middle attack (or other kinds of attacks) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: can a random number be subject to a takedown?
On 01 May 2007 22:33, Jon Callas wrote:
On May 1, 2007, at 12:53 PM, Perry E. Metzger wrote:
unsigned char* guess_key(void)
{
unsigned
char key[] = {0x0a, 0xFa, 0x12, 0x03,
0xD9, 0x42, 0x57, 0xC6,
0x9E, 0x75, 0xE4, 0x5C,
0x64, 0x57, 0x89, 0xC1};
return key;
}
(Or it would if I'd put the actual AACS key in there.)
Heh, that's a bit like the old issue of whether you can publish an OTP that
has certain interesting properties when used to en/decrypt some other public
domain information.
See also http://preview.tinyurl.com/3dcse6
http://preview.tinyurl.com/2d3hm3
http://preview.tinyurl.com/2ey2mj
for more variations on this theme. Wonder if you can issue a take-down notice
for a 301 redirect?
cheers,
DaveK
--
Can't think of a witty .sigline today
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
The best riddle you wil hear today...
http://farm1.static.flickr.com/191/480556169_6d731d2416_o.jpg - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
The HD-DVD key fiasco
Currently, http://www.google.com/search?hl=enq=%2209+f9+11+02+9d%22btnG=Search reveals order of 50,000 hits. Doubtless soon it will be many times that number. When you treat the whole world, and especially your own customers, as the enemy, eventually everyone will come to reciprocate. Perhaps, in the words of one jurist, the constitution is not a suicide pact. However, it has become increasingly clear that a takedown notice can be a suicide note. I'm not that interested in our discussing the politics of this much further, as I think almost everyone here is in violent agreement. I'll take interesting new postings on the topic, but the threshold for interesting is pretty high. I would be interested in further legal discussion of the DMCA's ability to control the publication of mere cryptographic keys, and in further technical discussion of AACS and similar DRM technologies. Perry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
AACS and Processing Key
Since this is the cryptography mailing list, there might be interest in the cryptography behind this infamous key. This is from http://www.aacsla.com/specifications/ , particularly the first spec, Common Cryptographic Elements. The basic cryptography is from Naor, Naor and Lotspiech, http://www.wisdom.weizmann.ac.il/~naor/PAPERS/2nl.html . The AACS system implements broadcast encryption. This is a scheme which has also been used for satellite TV. The idea is that you want to encrypt data such that any of a large number of devices can decrypt it, with also the possibility of efficiently revoking the keys in a relatively small subset of devices. The revocation is in case attackers manage to extract keys from devices and use them to decrypt data without authorization. Broadcast encryption schemes such as that used by AACS equip each device with a set of keys, and encrypt a content key to various subsets of these keys such that each authorized device can decrypt the content key but the revoked devices cannot. Various methods have been proposed for achieving this, with tradeoffs between the number of keys held by each device and the amount of data which must be broadcast to hold all of the necessary encryptions. AACS uses a binary tree based method, where each device corresponds to the leaf node of a tree. It uses a tree with depth of 31, so there are 2^31 leaf nodes and 2^32 - 1 nodes in all. At this point it is believed that software players of a particular type are all considered a single device, while hardware players are each a unique device. This will allow individual hardware players to be revoked, while requiring all software players of a given brand or type to be revoked at once. This tradeoff is assumed to be acceptable because it is easy to get a new version of a software player. The method of assigning and handling the keys is called subset-difference. It allows a single encryption to be decrypted by any of the devices in a given subtree of the main tree, minus any sub-subtree of that subtree. In this way, any set of revoked nodes can be handled by the union of an appropriate chosen set of subset-difference encryptions. For example, suppose two nodes A and B are to be revoked. Let A be to the left of B, and call their lowest common ancestor node C. Encrypt to the whole tree minus the subtree rooted at C; also to C's left child's subtree minus A; also to C's right child's subtree minus B. This will cover all nodes except A and B. To implement subset-difference, the root node of each subtree is assigned a unique key called a device key. Then going down the subtree from that node, each node gets its own device key as a distinct one-way hash of its parent's device key. The result is that if you know a node's device key, you can deduce the device keys of all descendants of that node. This assignment of keys is carried out independently for each subtree, so a node at level n has n+1 device keys associated with it, one for each of the n+1 subtrees that it is a part of. Leaf nodes correspond to devices, but devices do not get the device keys for their leaf node. Instead, they are given the device keys of the sibling node of their leaf, as well as the device keys of all of the siblings of their ancestor nodes. Because knowing a device key allows deducing the device keys of all its descendents, this assignment allows each physical device to deduce all device keys in the tree except for their ancestor nodes: those on the one branch of the tree leading to the leaf node. To implement subset-difference encryption, suppose we want to encrypt to all nodes in the subtree rooted at node A except those nodes in the sub-subtree rooted at node B. Then we encrypt to the device key of node B that was assigned as part of the device key system rooted at node A. All nodes in the node-A subtree except those below node B can deduce this device key, because B is not one of their ancestors. Nodes below B cannot deduce the device key because B is an ancestor, and nodes not below A cannot deduce it because this set of device keys was unique to the node-A subtree. In order to get the system started, one node is considered pre-revoked and not assigned to any physical device. Initially, the data is encrypted to the device key assigned to that node as part of the system for the whole tree. Every device will be able to deduce that device key and decrypt the data. That one key is the processing key about which so much fuss is being made. All HD-DVD disks that were initially produced have their content keys encrypted to that single key. Knowing this processing key, along with other information available from the disk, allows determining all necessary decryption keys and provides access to the plaintext of the content. With this value having been published, all of the first generation of HD-DVD disks can be played. The interesting thing is that publishing a processing key like this does not provide
Re: 128 bit number T-shirt?
Ivan Krstić wrote, On 3/5/07 4:50 AM: But all the artwork is just ugly numbers in a monospace font My thoughts too. This one looks much better, but I don't see a link anywhere to get it. Perhaps the author just photoshopped the picture as a proof of concept to go with his blog comment? http://www.ghacks.net/2007/04/30/09-f9-11-02-t-shirt -- sidney - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: The best riddle you wil hear today...
At 10:27 AM 5/2/2007, Aram Perez wrote: http://farm1.static.flickr.com/191/480556169_6d731d2416_o.jpg From another list: This was one of my faves bits of html from last night tr td bgcolor=#09f911/td td bgcolor=#029d74/td /tr tr td bgcolor=#e35bd8/td td bgcolor=#4156c5/td /tr tr td bgcolor=#635688/td td bgcolor=#c0/td /tr /table Makes a nice flag..fly it -- ((Udhay Shankar N)) ((udhay @ pobox.com)) ((www.digeratus.com)) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: AACS and Processing Key
[EMAIL PROTECTED] (Hal Finney) writes: The interesting thing is that publishing a processing key like this does not provide much information about which device was cracked in order to extract the key. This might leave AACSLA in a quandary about what to revoke in order to fix the problem. However in this particular case the attackers made little attempt to conceal their efforts and it was clear which software player(s) were being used. This may not be the case in the future. AACSLA has announced that they will be changing the processing keys used in disks which will begin to be released shortly. Software players have been updated with new device keys, indicating that the old ones will be revoked. In the context of the subset-difference algorithm, there will now probably be a few encryptions necessary to cover the whole tree while revoking the old software player nodes as well as the pre-revoked node. This will make the processing key which has been published useless for decrypting new disks. However, it is still fine for decrypting old disks, and thus revelation of this sort of information ruins inventory, which is very expensive. All cryptography is about economics. In crypto, we usually consider what the best strategy for an attacker is in terms of breaking a cryptosystem, but here I think the right question is what the optimal strategy is for the attacker in terms of maximizing economic pain for the defender. I'd be very interested in what the optimal strategy is for the attacker in a system like this, and what possible changes could be made to such a system to defeat such strategies. At first glance, it would seem that, for the attackers, the right strategy is not to flood the world with newly cracked keys but to release them quite slowly. Lets say that the lifetime of the technology in question is somewhere around ten years. Releasing one key on the order of every two months or so -- only sixty keys in all over the life of the technology -- would be crippling. It would render all inventory in warehouses and the production pipeline useless, at quite minimal cost to the attackers. The defenders then have a choice -- destroy all your inventory, or give up. (Or, do they have alternate strategies here?) Anyone very familiar with AACS have ideas on what optimal attack and defense strategies are? This seems like a fertile new ground for technical discussion. Perry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Was a mistake made in the design of AACS?
Expanding my last message to make it clearer: Schemes like the AACS one work quite well for satellite TV broadcast protection. In such systems, one's goal is to disable the units owned by rogue subscribers, but the only inventory that one might ruin by a key invalidation is a bit of electromagnetic radiation in transit from the broadcast site to the subscribers. Little is lost by performing a revocation. An ongoing business relationship exists with the legitimate subscribers as well, so they can receive updates in the form of hardware tokens that are difficult to reverse engineer quickly enough. Further, the users of unauthorized decoders are in a bit of a bind -- they cannot retrieve last months' broadcasts while waiting for new keys, so if they want entertainment now they need to have a continuous supply of keys fed in real time. In the HD-DVD/Blu Ray case, the model is very different. End users of hardware players have no ongoing relationship with the provider, so one cannot be guaranteed the ability to update. All old disks sold can be compromised, and they constitute a substantial risk, as does the actual inventory of disks waiting to be sold. Additional economic hardship comes from the fact that there is non-zero effort involved in sending new masters to production houses and in tracking dead inventory. As I noted, in the direct broadcast satellite case slow leaks of keys over extended periods of time are not of much use to the end users and are not of much damage to the system owners, but in the AACS case slow leaks are actually exceptionally damaging. Were the bad guys to release just one key every couple of months it would effectively destroy the system. There is also the issue of differing threat models. In a broadcast system, you are attempting to assure that people watching the real time broadcast are paying you money. In the high def video disk case, you have several quite different goals from the broadcast case. One is to enforce region encoding so that you can charge U.S. customers a large multiple of what you charge, say, a Chinese customer for exactly the same material. The second is to prevent people from retrieving the content in a form they can send to their friends over the internet. A third goal is to keep customers from being able to use content in unplanned ways so you can up-sell them to a newer format later on. (Note that the DRM scheme does *not* prevent actual commercial piracy of disks, since pirates can simply press bit for bit identical disks.) Goals one through three are all failures even if key data leaks only quite slowly to the public. You will be just as interested in preventing people from watching different region HD-DVDs that are three months old as you will in preventing them from watching ones that are only days old. You will be just as interested in preventing people from uploading the contents of Blu Ray disks that are a few months old as you will in preventing uploads that are from brand new releases. On part three, the failure would be quite complete -- collectors of HD discs will be able to transfer their old discs to their new UltraVideoPseudoPods in ten years, thus eliminating the lucrative business of selling them content they have previously bought in a new format. My feeling, then, is that the entire HD protection scheme was a miscalculation. Methods like this worked just fine for satellite TV, and they were then applied without sufficient thinking about threat models to a new domain where things are quite different. This seems to me to be, yet again, an instance where failure to consider threat models is a major cause of security failure. It is not enough to throw clever algorithms at things -- you have to consider what it is that you are trying to defend against specifically, and how those algorithms will lead to the specific security goals. I will again solicit suggestions about optimal strategies both for the attacker and defender for the AACS system -- I think we can learn a lot by thinking about it. It would be especially interesting if there were modifications of the AACS system that would be more hardy against economic attacks -- can you design the system so that slow key revelation is not an economic disaster while still maintaining an offline delivery model with offline players entirely in the enemy's control? I don't think you can, but it would be very interesting to consider the problem in detail. -- Perry E. Metzger[EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: The HD-DVD key fiasco
At 02:15 PM 5/2/2007 -0400, Perry E. Metzger wrote: I would be interested in further legal discussion of the DMCA's ability to control the publication of mere cryptographic keys, and in further technical discussion of AACS and similar DRM technologies. (Links at the site, posted by EFF Senior IP Attorney Fred von Lohmann) http://www.eff.org/deeplinks/archives/005229.php 09 f9: A Legal Primer May 02, 2007 As was reported back in February, an enterprising hacker unearthed and posted one of the decryption keys used by AACS to decode HD-DVD movies (other keys and exploits have been made available in the weeks since). Now the AACS-LA (the entity that licenses AACS to makers of HD-DVD players) has set its lawyers on the futile mission of trying to get every instance of at least one key (hint: it begins with 09 f9) removed from the Internet. Predictably, this legal effort has backfired, resulting in eternal Internet fame for the key in question. In addition to having been posted on hundreds of thousands of web sites (and resulting in the temporary shutdown of Digg.com), the key has already spawned a song, a quiz, a domain name, and numerous T-shirts. So now might be a good time to review a few of the basic legal issues raised by the posting of the keys. (This is an overview of the legal landscape, not legal advice, and I am not expressing any view about how a case might come out if AACS-LA sued anyone.) What is the AACS-LA's argument? In its takedown letters, the AACS-LA claims that hosting the key violates the DMCA's ban on trafficking in circumvention devices. The DMCA provides that: No person shall ... offer to the public, provide, or otherwise traffic in any technology, product, service, device, component, or part thereof that that - (A) is primarily designed or produced for the purpose of circumventing a technological measure that effectively controls access to a work protected under this title; (B) has only limited commercially significant purpose or use other than to circumvent a technological measure that effectively controls access to a work protected under this title; or (C) is marketed by that person or another acting in concert with that person with that person's knowledge for use in circumventing a technological measure that effectively controls access to a work protected under this title. The AACS-LA presumably would argue that the key is a component or part of a technology that circumvents AACS. Moreover, AACS-LA would likely argue that the key was primarily ... produced to circumvent AACS, that is has no other commercially significant purpose, and that it is being marketed for use in a circumvention technology. The takedown letters seem to take the position that both the poster and the hosting provider are engaged in trafficking. The AACS-LA will also doubtless point to the DMCA cases brought against 2600 magazine for posting the DeCSS code back in 2000 (EFF was counsel to the defendant). In that case, both the district court and court of appeals concluded that posting DeCSS to a website violated the DMCA. Who can sue over the posting of the key? The DMCA entitles anyone injured by a violation to bring a civil lawsuit seeking damages (including statutory damages ranging between $200 and $2500 for each offer). In addition, if a person violates the DMCA willfully and for purposes of commercial gain, a federal prosecutor could bring criminal charges (with the famous exception of the Sklyarov case, however, criminal prosecutions have generally been limited to situations where the DMCA violation was also accompanied by evidence of commercial piracy). What about just linking to a place where the key is posted? The courts in the DeCSS case wrestled with the proper test to apply when someone links to a location where a circumvention tool can be found. Ultimately, the district court held that an injunction against linking could be issued after a final judgment if a the plaintiff could show, by clear and convincing evidence, that those responsible for the link (a) know at the relevant time that the offending material is on the linked-to site, (b) know that it is circumvention technology that may not lawfully be offered, and (c) create or maintain the link for the purpose of disseminating that technology. The court of appeals upheld that ruling, while admitting that the issue presented a difficult First Amendment question. What about the DMCA safe harbors? While no court has ruled on the issue, AACS-LA will almost certainly argue that the DMCA safe harbors do not protect online service providers who host or link to the key (the AACS-LA takedown letters do not invoke the DMCA notice-and-takedown provisions, nor do they include the required elements for such a takedown, thereby signaling the AACS-LA position on this). The DMCA safe harbors apply to liabilities arising from infringement of
Re: Was a mistake made in the design of AACS?
* Perry E. Metzger: This seems to me to be, yet again, an instance where failure to consider threat models is a major cause of security failure. Sorry, but where's the security failure? Where can you buy hardware devices that can copy HD disks? Or download software that does, with a readily usable interface? In that sense, even CSS hasn't really been broken. Even the flurry of DMCA takedown notices isn't necessarily a bad move. It might help to shape the future of how access to content is regulated in some very particular way. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Was a mistake made in the design of AACS?
Florian Weimer [EMAIL PROTECTED] writes: * Perry E. Metzger: This seems to me to be, yet again, an instance where failure to consider threat models is a major cause of security failure. Sorry, but where's the security failure? Where can you buy hardware devices that can copy HD disks? Or download software that does, with a readily usable interface? You can't, but I think that is more a question of the market size. Right now there are very few HD-DVDs and Blu Ray discs on the market, and most people have DVD drives but not HD-DVD or Blu Ray drives. (I don't know that I've ever even seen such a drive to date, but that will surely change in a year.) Until there is a significant percentage of the user community with an itch to scratch the software will not appear. However, it is now very clear that the software is quite doable once people want it. In that sense, even CSS hasn't really been broken. I watch DVDs all the time on my open source OS laptop using software that depends on DeCSS. It is quite nice software -- the UI is more or less as good as any of the Windows DVD players. (If the MPAA or DVD copy control folk want to try prosecuting me for watching DVDs I've bought legitimately using software they don't approve of, they are welcome to try -- I suspect that they don't have much of chance of winning.) I haven't used extraction software myself for real (I have no need for it at the moment -- I don't need my DVD library online) but there are a number of programs out there that allow you to extract the content from DVDs to your hard drive as easily as you can do it for a CD. They're pretty easy to find, even for Windows and OS X, and in my tests the UIs appeared to be pretty much easy enough for an ordinary person to use. These programs also depend on DeCSS, of course. Even the flurry of DMCA takedown notices isn't necessarily a bad move. It might help to shape the future of how access to content is regulated in some very particular way. I doubt they'll get very far. Their best bet for suppression is to sue a selected subset of people for publishing the process key, but beyond bad publicity I don't see what practical benefit they might get. Especially in the US, they may also eventually run up against the first amendment. I know that one judge in the 2600 case believed that the constitution is not a suicide pact, but those were different days. That case happened when the community was far less prepared, was not shepherded by ideal people, and did not set a real precedent. I think it might be harder to ramrod a similar case through the courts now, especially given that the Supreme Court has never ruled on this, and especially since programs like the ones I use to watch DVDs are clear and obvious legitimate uses and can be demonstrated to and understood even by members of the judiciary. -- Perry E. Metzger[EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Was a mistake made in the design of AACS?
Perry Metzger writes: I will again solicit suggestions about optimal strategies both for the attacker and defender for the AACS system -- I think we can learn a lot by thinking about it. It would be especially interesting if there were modifications of the AACS system that would be more hardy against economic attacks -- can you design the system so that slow key revelation is not an economic disaster while still maintaining an offline delivery model with offline players entirely in the enemy's control? I don't think you can, but it would be very interesting to consider the problem in detail. Ed Felten has blogged a number of ideas along these lines: http://www.freedom-to-tinker.com/?p= By this point in our series on AACS (the encryption scheme used in HD-DVD and Blu-ray) it should be clear that AACS creates a nontrivial strategic game between the AACS central authority (representing the movie studios) and the attackers who want to defeat AACS. Today I want to sketch a model of this game and talk about who is likely to win... Felten focuses on the loss of revenue due to extraction of device keys and subsequent file sharing of decrypted content. AACS has a mechanism called sequence keys to watermark content and allow it to be traced back to the player that created it. Felten assumes that attackers would publish decrypted movies, AACSLA would then trace them back to the broken device, and revoke that device in future releases. The optimal strategy depends on his parameters C, the cost in time it takes for attackers to break into new devices and extract keys; and L, the commercial lifetime of a new disk. Felten writes: It turns out that the attacker's best strategy is to withhold any newly discovered compromise until a 'release window' of size R has passed since the last time the authority blacklisted a player. (R depends in a complicated way on L and C.) Once the release window has passed, the attacker will use the compromise aggressively and the authority will then blacklist the compromised player, which essentially starts the game over. The studio collects revenue during the release window, and sometimes beyond the release window when the attacker gets unlucky and takes a long time to find another compromise. He estimates that C is measured in weeks and L in months, which bodes ill for the studios, as his model predicts that studios will receive the fraction C/(C+L) of their potential revenues if no piracy occured, and CL makes this fraction small. I see a couple of problems with his model. First, it may be that by publishing processing keys instead of device keys or movie content, it will be harder to make the traitor tracing algorithm work and AACSLA may be thwarted in their attempt to revoke the broken device. I'm not sure I understand the system well enough to know whether there are effective countermeasures for AACSLA against this attacker strategy. Threats of legal action do not appear to be achieving much success. Second, there is a long lead time between when AACSLA determines to update the processing keys and other components of the subset difference scheme, and when the disks actually reach the public. This is bad for the studios and probably effectively increases L. On the other hand I suspect his L estimate of months is excessive; 8 of the Amazon's 10 top selling DVDs were released since April 24. As with other media like CDs, it is likely that the bulk of revenues arrive during the first few weeks of release. If they can protect that window then they might view the system as achieving at least some of its goals. But these other considerations will work against them. Hal Finney - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Was a mistake made in the design of AACS?
Hal Finney wrote: Perry Metzger writes: Once the release window has passed, the attacker will use the compromise aggressively and the authority will then blacklist the compromised player, which essentially starts the game over. The studio collects revenue during the release window, and sometimes beyond the release window when the attacker gets unlucky and takes a long time to find another compromise. This seems to assume that when a crack is announced, all revenue stops. This would appear to be false. When cracks are announced in such systems, normally revenues aren't strongly effected. C.f. DVDs. iang - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
