October 2003 - cypherpunks-legacy

Re: Software protection scheme may boost new game sales (fwd)
by Sunder 11 Oct '03

11 Oct '03

Yawn... This is no different than any of the copy protection schemes employed in the 1980's on then popular home computers such as the commodore 64. Hindsight is 20/20 and recalls, all of these were broken within weeks if not months. "Nibbler" copiers and other programs were quickly built that allowed the breaking of all of these systems. All sorts of "error" sectors, duplicate tracks, half tracks, extra tracks, extra sectors, non-standard sized sectors, tracks written at different speeds, erroneous checksums, hidden data, and other sorts of weird bits were employed. All were broken. None survived the ages. In the end, the companies that employed copy protection only managed to piss off customers who lost their only copy of the software, and created a market for the copiers and crackers. The crackers won, the software companies lost. Few of the companies of that era are still in business today. CEO's, Vulture Capitalists, and others who have an interest in such schemes would do well to invest some time in learning about that time, and the results, for their investments, and dollars will go the same way... the way of the brontosaurus, the trilobite, and the dodo. Let them try, if they wish to burn their money. As far as I'm concerned, I'll vote with my wallet as usual and only run open source, free software. If the moronic kids at whom these titles are aimed have the $50-$70 per title to waste on self destructing, flavor of the month games, they are certainly free to spend that money to their heart's desire. Not a dime from my wallet will wind up in their pockets - except perhaps indirectly: the next time I buy my next burger, "no, I don't want fries with that, no, I don't want to supersize it," my $5 eventually makes a small contribution to the salary of the burger flipper, which in turn is applied to the purchase of said game. :) I've not read the said article just yet, but from that direct quote "as the copy degrades..." I can already see the trouble with this scheme: their copy protection already fails them. They allow copies to be made and rely on the fact that the CDR or whatever media, will eventually degrade, because their "code looks like scratches..." Riiiiggghtt..... If you can make one copy, you can make many, and you can certainly store the ISO in compressed form on a normal CD to make more copies later. CDR's are what? $0.20@ these days? Hell, you can even get one of those virtual CDROM programs to mount the CD's as if they were CD's, and store the ISO on a hard drive, or DVD-R instead. Hard drives are already in the 250-500GB range these days. So their scheme is already flawed and doomed from the start. It seems to me that people that engage in treating their customers like theives to begin with lack a vital ingredient for making money: common sense. ----------------------Kaos-Keraunos-Kybernetos--------------------------- + ^ + :25Kliters anthrax, 38K liters botulinum toxin, 500 tons of /|\ \|/ :sarin, mustard and VX gas, mobile bio-weapons labs, nukular /\|/\ <--*-->:weapons.. Reasons for war on Iraq - GWB 2003-01-28 speech. \/|\/ /|\ :Found to date: 0. Cost of war: $800,000,000,000 USD. \|/ + v + : The look on Sadam's face - priceless! --------_sunder_(a)_sunder_._net_------- http://www.sunder.net ------------ On Sat, 11 Oct 2003, Steve Schear wrote: > Companies are using a new software protection system, called Fade, to > protect their intellectual property from software thieves. Fade is being > introduced by Macrovision, which specializes in digital rights management, > and the British games developer Codemasters. What the program does is make > unauthorized copies of games slowly degrade, by exploiting the systems for > error correction that computers use to cope with CD-ROMs or DVDs that have > become scratched. Software protected by Fade contains fragments of > "subversive" code designed to seem like scratches, which are then arranged > on the disc in a pattern that will be used to prevent copying. Bruce > Everiss of Codemasters says, "The beauty of this is that the degrading copy > becomes a sales promotion tool. People go out and buy an original version." > (New Scientist 10 Oct 2003) > > <http://www.newscientist.com/news/news.jsp?id=ns99994248>

1 0

Nuking USG: not just for cypherpunks anymore
by Major Variola (ret.) 11 Oct '03

11 Oct '03

'If I could just get a nuclear device inside Foggy Bottom, I think that's the answer'," he said. --Pat Robertson, republican presidential candidate http://news.yahoo.com/news?tmpl=story2&cid=1521&u=/afp/20031009/pl_afp/us_d…

3 2

base conversion
by Sarad AV 11 Oct '03

11 Oct '03

hi, If we are to convert a k-bit integer n to a base b number,it takes us O(log n) if the base b is a power of 2. eg. converting (11111)base to base 16 0001 1111 ^ ^ 1 F in hex. using a look up table. Is there an algorithm with time complexity O(log n) which allows such conversion to base b ,when b is not a power of 2? Thanks. Regards Sarath. __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com

3 4

Idea: Small-volume concealed data storage
by Thomas Shaddack 11 Oct '03

11 Oct '03

I mentioned here the AT24RF08 chip here for couple times already. I got an idea about another application for this nice toy. For an encrypted data storage, the storage of the key is crucial. If the key is recovered, everything is lost. Remembering 256 (or even 128) bits is a hassle, a storage medium is subject to potential seizure. The key has to be protected by a passphrase, which is subject to bruteforcing. The key has to be destroyed in the event of a dangerous situation detected by the environmental sensors, or if the passphrase is tried one time too much (which opens the possibility of a DoS attack, rendering the data protection scheme unusable by regular intentional destruction of the key). However, the higher security we want, the lower alarm thresholds we have to set and the higher is the probability of misfire. For convenience reasons, for most common scenarios where absolute security is not necessary and some risk is affordable, we need a backup key storage. The mentioned chip can operate passively, powered from the coil used for data transfer, principially the same as an RFID tag. The independence on any kind of power supply makes it suitable for being built into some object, including the building itself; the chip and coil may be located inside a wall, serving as a potential storage for up to 8 kilobits of data as necessary. It may be put in place at the moment when the building is built, or during some construction work. Routine kinds of police raids are quite unlikely to discover this kind of data storage (though the eventual discovery of a reader device may be a giveaway). XORing the key with a MD5 hash of a memorized keyphrase can further increase security. This method may be also used for covert exchange of short messages. The device may be hidden under the carpet or inside poured concrete floor, and reader/writed in the shoes of the conspirators. The simplicity and robustness of the storage part of the technology could permit long-time installations "just for case". Or maybe I am too tired to think in coherent way. Maybe it's a good idea. Maybe not (if, then why?). May be handy at least for a spy novel writer.

2 1

What You Can Do -Right Now- To Stop CAPPS II
by Bill Scannell 10 Oct '03

10 Oct '03

Dear Patriot, For the past seven months, I have been fighting for the right of all Americans to travel freely in our own country. CAPPS II, the Soviet-style internal border control system being pushed by the Department of Homeland Security, will strip us of that right, and make air travel a 'privilege' granted by government. A lot has been accomplished: * Delta was shamed out of testing CAPPS II * Homeland Security was forced to appoint a Chief Privacy Officer * JetBlue was exposed violating the privacy of millions of passengers * JetBlue was shamed out of CAPPS II testing * A pro-CAPPS II 'consumer advocate' was unmasked as a Cendant shill * Galileo/Cendant has backpedaled on CAPPS II I need your help taking this fight forward. Running the anti-CAPPS II campaign costs a lot of time and money. The Boycott Delta and Don't Spy On US websites require a team of graphic artists and web designers. As you can imagine, the bandwidth usage is enormous. The over 40 million dollars in publicity generated for the ongoing anti-CAPPS II awareness campaign came at a cost of hundreds of media interviews, astronomical telephone bills, and all of my time and energy. Up to now, I have funded this project out of my own personal savings. America has been good to me and spending money to keep our country free seemed only fair. Unfortunately, I can't do this alone anymore, which is why I am turning to you for help. To keep up the fight, I need you to contribute to the cause. Whether you can afford $20.00 or $100.00; $50.00 or $1,000.00 , every cent you give makes it possible to keep up the pressure on those who would make our great nation less free. There are two ways you can help fund the fight: 1. Use your credit card and contribute using PayPal: http://dontspyon.us/paypal.html 2. Send a check or money order payable to 'Bill Scannell' in care of my attorneys: The Electronic Frontier Foundation 454 Shotwell Street San Francisco, CA 94110 Together, we can stop CAPPS II. With deepest gratitude, Bill Scannell Founder www.boycottdelta.org www.DontSpyOn.US "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." Benjamin Franklin [demime 0.97c removed an attachment of type image/jpeg which had a name of image.jpg]

1 0

wifi remailer entry points
by Anonymous 10 Oct '03

10 Oct '03

The idea of using wifi access points as entry points to the remailer network has been raised before. It seems like a useful service that anyone with an internet connection and a wireless card could offer. It provides cover for the operator's own remailer use, with much lower entry requirements than running a remailer node. What's the best way to set this up? Some possibilities: 1: Run Mixmaster on the wifi interface. This seems unnecessarily complicated, since users would have to fetch the node keys, and would have to specify the correct remailer as the first hop in the chain. 2: Run a SMTP server on the wifi interface, configured to relay messages to known remailer nodes and refuse all other destinations. Users would have to configure their remailer client to use the server as a SMTP relay. 3: Run a NAT firewall on the wifi interface, configured to allow TCP port 25 connections to known remailers, and block everything else. Users would have to run their own mail transfer agent. Option 3 seems to provide the simplest interface for clients running on Unix, since they will probably already have a functioning SMTP agent. But what about Windows clients? Do Windows remailer users typically run their own SMTP servers, or do they send via relays?

1 0

Chminey growth, omni luvin, tunnels across the net(tm) and forging the local rings of power (fwd from tomwhore@slack.net)
by Eugen Leitl 09 Oct '03

09 Oct '03

----- Forwarded message from Tom <tomwhore(a)slack.net> -----

1 0

IPsec in 2.6
by Eugen Leitl 09 Oct '03

09 Oct '03

I've always had trouble with FreeS/WAN breaking at kernel upgrades, but now that 2.6 is coming we're getting native IPsec support (albeit FreeS/WAN seems to claim Opportunistic Encryption won't be supported?). We seem to have a curious situation here. The majority of systems out there now support IPsec (NT/Win2K/XP; OS X), but there's very little interoperability. Particularly, there is no support for ad hoc encryption as default, without going through a lot of jumping through hoops (why should I be required to be able to publish DNS records just to have an encryption link?). Are there technical reasons for this situation? If yes, what is required to enable IPsec default interoperability at least with open source OSses? -- Eugen* Leitl <a href="http://leitl.org">leitl</a> ______________________________________________________________ ICBM: 48.07078, 11.61144 http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

3 4

EFF Report on Trusted Computing
by Anonymous 09 Oct '03

09 Oct '03

[Permission is granted to repost this document in its entirety, without other limitation. See http://invisiblog.com/1c801df4aee49232/ for an online copy.] The EFF has published a report on the "Promise and Risk" of Trusted Computing at http://www.eff.org/Infra/trusted_computing/20031001_tc.php. See also http://www.eff.org/Infra/trusted_computing/ for ongoing coverage of TC issues. The EFF is to be congratulated for taking its time to study the many issues revolving around TC and come to a relatively balanced and nuanced position. Staff Technologist Seth Schoen, said to be the principle author of the new report, provided some of the best early information about Palladium on his blog at http://vitanuova.loyalty.org/2002-07-05.html and similar postings, which were refreshingly objective and free of the almost obligatory anti-Microsoft bias of other analyses from so-called online rights activists. Nevertheless, the EFF report has a number of shortcomings which deserve discussion. The EFF tries to distinguish between "good" and "bad" aspects of TC, but it does not draw the line in quite the right place, even given its somewhat questionable assumptions. It fails to sufficiently emphasize the many positive uses of the full version of TC (and hence the costs of blocking its implementation), and also misses some important negatives as well. And the recommended fix to TC is not clearly described and as written appears to be somewhat contradictory. But let us begin with some positive elements of the EFF report. This is perhaps the first public, critical analysis of TC which fails to include two of the worst lies about the technology, lies promulgated primarily by Ross Anderson and Lucky Green: that only authorized programs can run "trusted", and that unauthorized or illegal programs and data will be deleted from computers or prevented from running. The EFF appears to recognize the key feature of TC, which gives it its name: that trust is in the eye of the truster. Anyone can create code which benefits from TC features, and it is up to the user of a computer to decide which local and remote software he will trust. The report also forthrightly rejects the claim that TC technology is some kind of trick to defeat Linux or lock-in computers to Microsoft operating systems, and debunks the lie put forth by Lucky Green that TC will insert spyware into your computer. By choosing to emphasize the truth rather than lies on these important points, the EFF gains credibility at the expense of opening itself to charges by extremists that it is in bed with Microsoft or is promoting "evil" technology. Those of us who have argued in the past for balanced analyses of TC are well aware of the speed with which opponents resort to name-calling and personal attacks, and it is a credit to the EFF that they have taken a courageous position which departs from the conventional wisdom in the online rights community. Despite these positives, as noted above the report has some weaknesses which need to be addressed. The EFF attempts to distinguish one feature of TC, remote attestation, as a source of problems. This is the ability of a computer user to convince other systems about what software he is running. The EFF is convinced that this feature will cause users to be compelled to use software not of their choice; harm interoperability and encourage lock-in; and support DRM and various restrictive kinds of licensing. But when we break these down in detail, many of the problems either go away or are not due to attestation. Software choice limitation may occur if a remote system provides some service conditional on the software being used to access it. But that's not really a limitation of choice, because the user could always elect not to receive the offered service. The implicit assumption here seems to be that if TC did not exist, the service would be offered without any limitations. Then it makes it appear that TC adds limitations which are not currently present. But what this analysis overlooks is that TC will allow the creation of new services which are not economically possible today. By allowing for more protection of data, a whole host of new applications may become possible. So the proper comparison is not with a hypothetical state where you'd have all the same services without TC as with; but rather, comparing a TC world that is relatively rich in services with a service-poor non-TC world. Turning to the issues of lock-in and interoperability, it is true that TC may allow software creators to lock their data to the applications and make it more difficult to create interoperable alternatives, thus promoting lock-in. The problem here with the EFF analysis is that it is not the remote attestation feature of TC which is the primary cause of this effect, but rather it is the sealed storage feature. It is sealed storage that allows data to be encrypted such that only one particular application can decrypt it, and potentially makes it impossible to switch to a different software package, or access the data in an interoperable way. The EFF attempts to say that sealed storage and other features of TC are good, because they clearly can increase the security features of your computer. Then they draw a line at remote attestation. But if it is lock-in and interoperability that worries them, sealed storage has to go as well. This inconsistency in the report undercuts its main conclusion. And parenthetically, lock-in is not necessarily a bad thing, as long as people know about it in advance. When you go on vacation you know that you will only be able to eat at restaurants in the local area. You are locked-in to local eateries. Everyone accepts this as part of the cost of the vacation. People can factor these kinds of lock-in costs into the overall package when they make decision about what to buy, whether travel or software. In this sense, it's good for activists like the EFF to make people aware that TC may increase lock-in, but they should put the issue into perspective and not present it as a reason to abandon the technology. It's just a consideration to be aware of when buying any software that is TC-enabled. Lastly, the EFF is worried that remote attestation enables DRM and other restrictive licensing practices. This is clearly true, although things are not quite as simple as they seem. Before wide-scale use of TC for DRM, it will be necessary for the manufacturers, software vendors and content providers to get past a few tiny details, like setting up a global, universal, widely trusted and secure PKI. Hopefully readers in these forums will understand that this is not exactly a trivial problem. Going from the basic technological definitions of TC to the massive infrastructure of keys and revocations needed for a secure, commercial DRM system and other licensing schemes is going to take quite a while. But in any case, once it happens, again the report fails to paint a balanced picture, by emphasizing the negative aspects of the new kinds of licensing that TC will enable. It should be clear that a technology that allows new kinds of voluntary arrangements, without eliminating any old ones, cannot be entirely evil. TC only expands the space of possibilities, it does not stop anyone from doing things the old way. If the new possibilities enabled by TC are truly so horrible for consumers, and if it is possible (as TC opponents implicitly assume) to provide these functionalities without the nightmarish limitations that the report is so afraid of, then some companies can still offer their goods under those more-favorable terms, and reap massive rewards as consumers triumphantly reject the horrific license terms of the TC-based software. This report, like so many others, ignores the role of consumers in making decisions about what technologies to use. This is one area in which the EFF was unable to rise above the myopia shared by so many other analyses. Ironically, given these oversights, the report also manages to miss some bad features of TC, features which have been discussed at some length on the cypherpunks and cryptography mailing lists. One of the biggest is the area of upgrades and system replacement. The TCPA (now TCG) proposal for handling upgrades is clearly unworkable, and Microsoft has said nothing about how they will do it. Any data which is locked to your computer is clearly at greater risk of being unrecoverable if your computer breaks. Until a bulletproof upgrade path exists, end users are going to be reluctant to embrace the promise of TC technology. Another area not discussed is the risk to privacy implicit in using this technology on a global network. TCPA's solution, "privacy CAs", is another part of the spec that is obviously never going to work. Microsoft had made some noise about copying this at one point, and is now decidedly mute on the issue. It is an almost impossible problem to solve, and chances are that the companies will simply give up and let the system compromise user privacy. As a privacy-oriented watchdog group, the EFF has dropped the ball in failing to emphasize this point. The final complaint about the report is that their solution doesn't seem to make sense. The basic idea is to allow the user to override the remote attestation feature so his system can lie about his software configuration. The apparent problem with this, as a number of commentators have pointed out, is that it undercuts the remote attestation feature and makes it useless. It is like "fixing" the limitations of cryptographic certificates by allowing anyone to forge them. Doing this defeats the purpose of the feature so completely that you might as well not have it. It would seem to make more sense for the EFF to simply call for remote attestation to be removed from the TC concept than to try to come up with a complicated "owner override". And in fact it seems likely that remote attestation will be one of the last parts of the TC spec to be implemented due to the PKI problem noted above, so we will probably see TC installations initially without attestation support. It may be that remote attestation never becomes as popular as TC proponents hope and critics fear. Now, perhaps there are some subtle aspects to the EFF proposal which would make attestation with owner overrides more useful than a version of TC without attestation at all. But to analyze that we'd need more detail about how exactly this owner override is supposed to work, and what attestation would still be used for in such a system. As it is, the proposal is frustratingly vague on these details. Summing up, the EFF report manages avoid the worst excesses of anti-TC rhetoric so common in the online rights community. By attempting to take a moderate course and identifying both promise and risk with TC technology, it does a service in setting a new standard of accuracy and civility in analyzing this important topic. However the report does have weaknesses, and its attempt to focus on problems with remote attestation misunderstands both economic realities and the technical details of which aspects of TC cause problems. By concentrating so narrowly on attestation, the EFF overlooks both important risks and promises of this new technology. And its proposed solution appears illogical on its face, requiring much more explanation and discussion for a fair evaluation. Make no mistake about it: TC is coming. All the rhetoric, all the protests and objections, are doing nothing to alter the apparently unstoppable momentum of this new technology. Microsoft is committed to NGSCB (Palladium), and the TCG (TCPA) is working actively on specs for cell phones and other devices. There is even considerable work to bring TC into Linux. What we need now is better understanding of both the risks and rewards of this technology, which will be here perhaps sooner than many of us expect. The EFF report is a good first step in this direction, but the problems need to be corrected. And rather than a futile and quixotic attempt to change the nature of TC, the EFF should focus on informing consumers about the pros and cons of the system, how it will affect their use of technology in years to come, questions to ask of vendors, and ways to protect their privacy and security. That is a hard enough task, and one truly in keeping with the EFF's goals and mission.

2 1

EU directive could spark patent war
by Steve Schear 08 Oct '03

08 Oct '03

[I wonder what if any effect this might have on crypto patents, e.g., Chaumian blinding?] "The European Parliament's decision to limit patents... risks creating a "patent war" with a fallout that could make it illegal to access some European e-commerce sites from the United States..." "Pure software should not be patentable, the parliament argued, and software makers should not be required to license patented technology for the purposes of interoperability--for example, creating a device that can play a patented media format, or allowing a computer program to read and write a competitor's patented file formats. " "The amendments also sought to ban the patenting of business methods such as Amazon.com's patent on one-click purchasing. " Full story at http://news.com.com/2100-1014_3-5086062.html?tag=nefd_top steve

2 1