Blind Signature Patent Expiration Party this Saturday
Friends, colleagues, and co-conspirators, It has been 17 long years and now the time is finally here to celebrate at the: BLIND SIGNATURE PATENT EXPIRATION PARTY === WHAT: A party to celebrate the expiration of the Blind Signature patent. WHY: U.S. Patent 4,759,063 (Blind Signature Systems) to David Chaum is the core invention enabling privacy-protecting electronic payment systems and credentials. It was a truly ingenious, ground-breaking contribution. Unfortunately the existence of the corresponding patent, which was notoriously difficult to license, prevented this great invention from receiving the wide use that it so very much deserved. For a copy of the patent, see http://www.pat2pdf.org/pat2pdf/foo.pl?number=4759063 Unlike copyrights these days, patents do expire. The blind signature patent will expire on July 19, 2005, next Tuesday. Since weekends tend to fit better with the schedules of potential party goers than weekdays, we are holding the party this Saturday instead. The 17 years that this patent has been in effect has been an awfully long time for the many of us that hoped to make use of this technology to help citizens to maintain privacy in the age of the Internet and the patent's expiration is a much overdue reason for celebration. WHO: If you know what blind signatures are you are invited. WHEN: This Saturday, July 16, starting at 1:00 PM PDT WHERE: Since the number of inquiries I received in response to the party pre-announcement exceed the maximum occupancy limit of my home and since the weather promises to be excellent, we will hold the party in a beer garden instead. Drinks are on me! We will meet at the Alpine Inn (aka Alpine Beer Garden) 3915 Alpine Road, Portola Valley, CA 94028 USA AWARDS: Those that can demonstrate that they have created a full system that makes significant use of the blind signature patent by 4 PM on Saturday will be invited to and receive a free dinner at the afterparty. So get coding! (Pr0duct Cypher, where are you)? A team of judges will determine if a particular system qualifies for the award. AFTERPARTY: A handful of us plan to have dinner at a swanky restaurant on patent-free Tuesday. Email me or talk with me at the party if you are interested in joining. Space is limited. You will have to pay for your own food at the Tuesday dinner unless you qualify for the award above or your name is on the blind signature patent. Looking forward to see you all this Saturday, --Lucky This email could have been PGP encrypted. If you already have a PGP key, please upload it to https://keyserver.pgp.com to enable all users of PGP Universal and PGP Desktop 9 to use your key. If you would like your key to be used only with the cypherpunks.to domain, please upload your key to this PGP Universal server by visiting the URL below. https://keys.cypherpunks.to/b/b.e?r=cypherpunks%40minder.netn=lzqcyQA4Pb3bG%2FFx180YsQ%3D%3D
Blind Signature Patent Expiration Party this Saturday
Friends, colleagues, and co-conspirators, It has been 17 long years and now the time is finally here to celebrate at the: BLIND SIGNATURE PATENT EXPIRATION PARTY === WHAT: A party to celebrate the expiration of the Blind Signature patent. WHY: U.S. Patent 4,759,063 (Blind Signature Systems) to David Chaum is the core invention enabling privacy-protecting electronic payment systems and credentials. It was a truly ingenious, ground-breaking contribution. Unfortunately the existence of the corresponding patent, which was notoriously difficult to license, prevented this great invention from receiving the wide use that it so very much deserved. For a copy of the patent, see http://www.pat2pdf.org/pat2pdf/foo.pl?number=4759063 Unlike copyrights these days, patents do expire. The blind signature patent will expire on July 19, 2005, next Tuesday. Since weekends tend to fit better with the schedules of potential party goers than weekdays, we are holding the party this Saturday instead. The 17 years that this patent has been in effect has been an awfully long time for the many of us that hoped to make use of this technology to help citizens to maintain privacy in the age of the Internet and the patent's expiration is a much overdue reason for celebration. WHO: If you know what blind signatures are you are invited. WHEN: This Saturday, July 16, starting at 1:00 PM PDT WHERE: Since the number of inquiries I received in response to the party pre-announcement exceed the maximum occupancy limit of my home and since the weather promises to be excellent, we will hold the party in a beer garden instead. Drinks are on me! We will meet at the Alpine Inn (aka Alpine Beer Garden) 3915 Alpine Road, Portola Valley, CA 94028 USA AWARDS: Those that can demonstrate that they have created a full system that makes significant use of the blind signature patent by 4 PM on Saturday will be invited to and receive a free dinner at the afterparty. So get coding! (Pr0duct Cypher, where are you)? A team of judges will determine if a particular system qualifies for the award. AFTERPARTY: A handful of us plan to have dinner at a swanky restaurant on patent-free Tuesday. Email me or talk with me at the party if you are interested in joining. Space is limited. You will have to pay for your own food at the Tuesday dinner unless you qualify for the award above or your name is on the blind signature patent. Looking forward to see you all this Saturday, --Lucky This email could have been PGP encrypted. If you already have a PGP key, please upload it to https://keyserver.pgp.com to enable all users of PGP Universal and PGP Desktop 9 to use your key. If you would like your key to be used only with the cypherpunks.to domain, please upload your key to this PGP Universal server by visiting the URL below. https://keys.cypherpunks.to/b/b.e?r=cypherpunks%40jfet.orgn=pk3p2YzQ7qdYMEhuETiSPg%3D%3D
CFP: What the Hack '05 and Blind Signature Expiration Party
hand-carried to HIP in my luggage. The source compiled without errors. I was sound asleep at the time. By the time I woke up, cryptography had entered a new era: the U.S. Government, and in fact the entire world, woke up to a day from which on the only path remaing to stem the flow of strong crypto out of the U.S. was to ban books. And even the staunchest advocates of cryptographic export regulations knew that albeit the U.S. Supreme Court Justices may perhaps be bamboozled by declarations of the dangers of this new Internet thing, banning books was a proposal not in the least novel to the Court, standing no chance of meeting with the Justices approval. Cornered into an untenable position and with no help from the courts in sight, the U.S. Government eventually acknowledged the inevitable and relaxed the exports laws for strong cryptography to the point of insignificance in January of 2000. Eight years have passed since HIP '97, to be succeed by WTH '05 this year. While I don't really need the distraction, I could be convinced to organize another Cypherpunks, crypto, and security tent. Perhaps the most valuable lesson I learned at HIP '97 was the value of education. I received unexpected and invaluable education from two teenagers. I, and the many of us that made up the Cypherpunks contingent, provided much valuable educations to others. There exists an entire new generation that wasn't around in 1997, hungering for education, that could benefit from our knowledge. If we don't teach them, who will? If you are interested in joining the Cypherpunks tent at WTH during July 28-31 2005, please email me. If there is enough interest, I will organize another presence. http://www.whatthehack.org/ Sidebar: Free at last. Oh Lord. We are fee at last (Also known as the Blind Signature Patent Expiration Party) Some of you may rememember the RSA patent. Yes, there was a time when you couldn't use RSA inside the U.S. without paying licensing fees to RSA DSI. Many that were around at that time were not too happy about this fact. But at least you could pay somebody money to use RSA. If you had a valid business model, paying licensing fees may have be unpleasant, but using RSA was not insurmountable. There is another patent that is every bit as significant as the RSA patent. More so, perhaps. Unlike the RSA patent, this patent has not been available for licensing at any price, stymieing an entire field of research and wide swaths of commerce. This patent is U.S. Patent 4,759,063 Blind Signature Systems. http://www.pat2pdf.org The Blind Signature patent is not just any patent. This is *the* patent. Without the invention covered by this patent, there is no hope for online privacy. With this technology, the opportunities not just for privacy, but also for commerce, are endless. Countless visionaries have spent years of their lives, in some cases decades, trying to make those opportunities a reality only to run up against the fact that for reasons that would be worthy of a book, the patent could not be licensed. U.S. Patent 4,759,063 Blind Signature Systems will expire on July 19, 2005. A Tuesday. Since no patent litigator will consider litigating on a Monday morning over patent infringement for a patent that expires the next day, it appears safe to say that come the preceding Saturday, technologies that make use of this patent can be displayed to the public. That Saturday is July 16, 2005. It took us 20 long years to get to this date. For those of us that tried to use this technology, it was 20 very, very long years. Fortunately, the 20 years are over. Which is as much reason for celebration as I can imagine. The expiration of the Blind Signature patent surely calls for a party. And as I promised so many years go, I will take it upon myself to throw that party. Anybody that knows what blind signatures are is welcome, no, make that implored, to come to the expiration party at my house (or other venue if there are too many people for my place) to celebrate the expiration of the patent on Saturday, July 16. As for me, I am counting the days. Ping me for details. - --Lucky Green [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: PGP Desktop 9.0.0 (Build 1799) iQIVAwUBQlZnKwRVjUj9NCi0AQLRaA/8D9m/ThykSpmWd5aKzqxZEr1HNNhAUEl8 WktmQOUd0Ux0VUhhl/SyLPAaNMf7o1Fs+XpFc7hRP/cBtaeVOB8c87XkTQDIxGB/ +LL55toIQzAcT/alPGLqJEfN/sqNgeEZH6SU3PpgQmkXiBt2EjWAnmHZfX5YnEa3 Szd7HTRF0Rgy9othhmMlFvwHrW5SRv9c170iPuGNe4qFTqc+gNu0jznM/gW1V6Xk k1eZAbJ/X9OfWSsnKY8A42qt2XGhoAyJhnehTIqTUbnGjltaPiBz+S0zvBMIb+s9 C6zt2ynCutWdX4reiamLvpHGNT1bY3HukC/TrS+06BUJyMqJQZlOK8VkVqyWroV0 ege1eS8bJmjd3VpLaFZTFFGmGC/ZNtKIp2wCzn2KzAmoHyGmi+NNR2eVq04+XEG2 8+y0Lx54F+gCoUvMJg6+lcPd0R5iGT8iqmhLoLzUM6OUkKDPNUpSiyazzUnDxF15 YYi3nn/bTMZzouEgkVD8KxPU/D8f5rksZ/UE0SG5Q9h+8n8woN/6PR3JNYIa2onT m7QFhbs5ISTdcrCbzwmnd9h4GmXM161kLXQT8KFIDrpiawhpy9FRj89TlcHnNdMJ 8vdBonbyQ18WMdLYcxolPmUYYFIBhLxMoBb9GeXs0TGDBFQVbkM/x30tgOpECwyp wceTbcRpKy0= =09b/ -END PGP SIGNATURE-
RE: FIPS chassis/linux security engineer?
Hmm. Looking at the amazing number of unread messages in this folder, the list sure has picked up again. Eric wrote: Does anyone know of a manufacturer of FIPS 140 certified or certifiable 1u/2u rack mount chassis? Eric, There is a lot more to FIPS 140-2 than the case. It's what's inside the aluminum case that matters. In principle, any solid case with 6 sides could be the basis for a FIPS certified device. --Lucky Green This message could have been secured by PGP Universal. To secure future messages from this sender, please click this link: https://keys.cypherpunks.to/b/[EMAIL PROTECTED]
RE: FIPS chassis/linux security engineer?
Hmm. Looking at the amazing number of unread messages in this folder, the list sure has picked up again. Eric wrote: Does anyone know of a manufacturer of FIPS 140 certified or certifiable 1u/2u rack mount chassis? Eric, There is a lot more to FIPS 140-2 than the case. It's what's inside the aluminum case that matters. In principle, any solid case with 6 sides could be the basis for a FIPS certified device. --Lucky Green This message could have been secured by PGP Universal. To secure future messages from this sender, please click this link: https://keys.cypherpunks.to/b/[EMAIL PROTECTED]
New PGP Universal beta: PGP and S/MIME
Cpunks, I spent the last few months working at PGP on a nifty new solution to an old problem: how to get email encryption deployed more widely without requiring user education. Since ideas for solving this problem have been discussed on this mailing list for over 10 years now, some of you might wish to take a peek at the solution that we came up with. The public beta of PGP Universal 1.1 is now yours to download for free from http://www.pgp.com/products/beta1.1.html One of the many interesting features of our approach is the ability to secure all users of a mail server, without the users needing to understand what encryption is or does, no need for MUA-specific plugins, interchangeable use of PGP keys or S/MIME, and much more. And yes, you can still keep your 4096-bit RSA key on your PC only. I am using PGP Universal myself. It is really cool. Note that the download of PGP Universal is 322MB in size and requires a dedicated x86 server to install. Have fun, --Lucky Green [EMAIL PROTECTED]
New PGP Universal beta: PGP and S/MIME
Cpunks, I spent the last few months working at PGP on a nifty new solution to an old problem: how to get email encryption deployed more widely without requiring user education. Since ideas for solving this problem have been discussed on this mailing list for over 10 years now, some of you might wish to take a peek at the solution that we came up with. The public beta of PGP Universal 1.1 is now yours to download for free from http://www.pgp.com/products/beta1.1.html One of the many interesting features of our approach is the ability to secure all users of a mail server, without the users needing to understand what encryption is or does, no need for MUA-specific plugins, interchangeable use of PGP keys or S/MIME, and much more. And yes, you can still keep your 4096-bit RSA key on your PC only. I am using PGP Universal myself. It is really cool. Note that the download of PGP Universal is 322MB in size and requires a dedicated x86 server to install. Have fun, --Lucky Green [EMAIL PROTECTED]
RE: C3 Nehemia C5P with better hardware RNG and AES support
Peter wrote: In case anyone's interested, there's a cpu die photo at http://www.sandpile.org/impl/pics/centaur/c5xl/die_013_c5p.jpg showing the amount of real estate consumed by the crypto functions (it's the bottom centre, a bit hard to read the label). I fail to understand why VIA bothered adding AES support into the CPU. When was AES last the bottleneck on a general-purpose CPU? The bottleneck tends to be modular exponentiations, yet VIA failed to include a modular exponentiation engine. Strange. --Lucky Green
RE: RSA performance on Athlon64 vs. Itanium
-Original Message- From: J.A. Terranson [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 22, 2003 18:46 To: Lucky Green Cc: [EMAIL PROTECTED] Subject: Re: RSA performance on Athlon64 vs. Itanium On Sun, 12 Oct 2003, Lucky Green wrote: I just picked up an Athlon64 3200+, which runs at a 2 GHz clock speed. Using the Red Hat for AMD64 beta and the version of OpenSSL that ships with that beta, I get 922 1024-bit RSA signs per second. This is a tad less RSA signatures per second than I have seen on an 800MHz Itanium using highly optimized assembler. That's rather poor performance on the Athlon64. Are the figures that I am seeing typical for OpenSSL on the Athlon64? Has anybody here seen different figures using optimized code? Thanks, --Lucky Green Was there ever a reply to this? If so, could someone forward it to me off-list, as I missed it :-( J.A., I since ran additional tests. All tests are for 1024-bit RSA signatures. 1) OpenSSL as shipping with the RedHat Taroon beta for Athlon 64: 921 RSA signatures/second 2) OpenSSL compiled manually: 1313 RSA signatures/second 3) Performance benchmark application made available to reviewers: Exceeding 3800 RSA signatures/second. Reading various gamer and over clocker websites, the Athlon 64 general performance is testing at about par with the Intel P4 3.2GHz, faster in some tests, slower in others. With the Athlon 64 being the slightly less expensive CPU based on the prices I have seen around here. You basically get a 64-bit CPU for the price of a 32-bit CPU. The CPU seems to be catching on amongst the early adopter crowd. A friend just bought one for 32-bit gaming and is very pleased. Motherboards for the Athlon 64 are appearing rapidly. Two weeks ago, Fry's stocked one Athlon 64 motherboard. Today, Fry's had 3 of them. Looks like AMD may have some done something right with this CPU. I am getting ready to buy a second one to upgrade my other box at home. --Lucky Green
RE: C3 Nehemia C5P with better hardware RNG and AES support
Peter wrote: In case anyone's interested, there's a cpu die photo at http://www.sandpile.org/impl/pics/centaur/c5xl/die_013_c5p.jpg showing the amount of real estate consumed by the crypto functions (it's the bottom centre, a bit hard to read the label). I fail to understand why VIA bothered adding AES support into the CPU. When was AES last the bottleneck on a general-purpose CPU? The bottleneck tends to be modular exponentiations, yet VIA failed to include a modular exponentiation engine. Strange. --Lucky Green
RE: RSA performance on Athlon64 vs. Itanium
-Original Message- From: J.A. Terranson [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 22, 2003 18:46 To: Lucky Green Cc: [EMAIL PROTECTED] Subject: Re: RSA performance on Athlon64 vs. Itanium On Sun, 12 Oct 2003, Lucky Green wrote: I just picked up an Athlon64 3200+, which runs at a 2 GHz clock speed. Using the Red Hat for AMD64 beta and the version of OpenSSL that ships with that beta, I get 922 1024-bit RSA signs per second. This is a tad less RSA signatures per second than I have seen on an 800MHz Itanium using highly optimized assembler. That's rather poor performance on the Athlon64. Are the figures that I am seeing typical for OpenSSL on the Athlon64? Has anybody here seen different figures using optimized code? Thanks, --Lucky Green Was there ever a reply to this? If so, could someone forward it to me off-list, as I missed it :-( J.A., I since ran additional tests. All tests are for 1024-bit RSA signatures. 1) OpenSSL as shipping with the RedHat Taroon beta for Athlon 64: 921 RSA signatures/second 2) OpenSSL compiled manually: 1313 RSA signatures/second 3) Performance benchmark application made available to reviewers: Exceeding 3800 RSA signatures/second. Reading various gamer and over clocker websites, the Athlon 64 general performance is testing at about par with the Intel P4 3.2GHz, faster in some tests, slower in others. With the Athlon 64 being the slightly less expensive CPU based on the prices I have seen around here. You basically get a 64-bit CPU for the price of a 32-bit CPU. The CPU seems to be catching on amongst the early adopter crowd. A friend just bought one for 32-bit gaming and is very pleased. Motherboards for the Athlon 64 are appearing rapidly. Two weeks ago, Fry's stocked one Athlon 64 motherboard. Today, Fry's had 3 of them. Looks like AMD may have some done something right with this CPU. I am getting ready to buy a second one to upgrade my other box at home. --Lucky Green
RSA performance on Athlon64 vs. Itanium
I just picked up an Athlon64 3200+, which runs at a 2 GHz clock speed. Using the Red Hat for AMD64 beta and the version of OpenSSL that ships with that beta, I get 922 1024-bit RSA signs per second. This is a tad less RSA signatures per second than I have seen on an 800MHz Itanium using highly optimized assembler. That's rather poor performance on the Athlon64. Are the figures that I am seeing typical for OpenSSL on the Athlon64? Has anybody here seen different figures using optimized code? Thanks, --Lucky Green
RSA performance on Athlon64 vs. Itanium
I just picked up an Athlon64 3200+, which runs at a 2 GHz clock speed. Using the Red Hat for AMD64 beta and the version of OpenSSL that ships with that beta, I get 922 1024-bit RSA signs per second. This is a tad less RSA signatures per second than I have seen on an 800MHz Itanium using highly optimized assembler. That's rather poor performance on the Athlon64. Are the figures that I am seeing typical for OpenSSL on the Athlon64? Has anybody here seen different figures using optimized code? Thanks, --Lucky Green
RE: Digicash Patents
Tim wrote: Some people expected a land rush when the main RSA patents expired several years ago. Parties were even thrown. The land rush never happened. Just a reminder that there will be a Blind Signature Patent Expiry party at my place the Saturday before the blind signature patent expires. (The patent expires on a Tuesday. I called dibs on that party years ago). --Lucky
RE: Things are looking better all the time
Eugen wrote: This is dire lunacy. Currently US is perceived as an agressor by the majority of the world, including the so-called ally U.K. which has lent more than just its name. You will see an unprecedented surge in terrorism in the heart of homeland soon after this campaign is over. These attacks could well be nuclear, or at the very least result in heavy casualities, far eclipsing 9/11. Resulting nuclear strike on a random city somewhere will result in a world wide nuclear arms race. Soon after we're at the threshold of WWIII, a Gdeath event. If any terrorists had nukes, why have they not used them so far? --Lucky
RE: Things are looking better all the time
Eugen wrote: This is dire lunacy. Currently US is perceived as an agressor by the majority of the world, including the so-called ally U.K. which has lent more than just its name. You will see an unprecedented surge in terrorism in the heart of homeland soon after this campaign is over. These attacks could well be nuclear, or at the very least result in heavy casualities, far eclipsing 9/11. Resulting nuclear strike on a random city somewhere will result in a world wide nuclear arms race. Soon after we're at the threshold of WWIII, a Gdeath event. If any terrorists had nukes, why have they not used them so far? --Lucky
RE: pgp in internet cafe (webpgp)
Anon wrote: Assumptions: - I have https (SSL) access to a trusted unix box - I trust SSL - I'll take a risk of unknown machine running http client being subverted I want to use PGP while checking/sending e-mail via web interface on someone else's machine (say, internet cafe). So [...] The question is - do I have to code this or has someone already done it ? http://www.lokmail.com/ --Lucky Green
RE: IDEA
Mindfuq wrote: I compiling the Mixmaster remailer, I get an error the OpenSSL was not compiled with IDEA support. However, OpenSSL was supposed to have compiled with IDEA out of the box, with only an option to disable it. What am I missing? You in all likelihood fell victim to some misguided nonsense that seems to spread through the Open Source community at present. Some distributions have disabled IDEA and other patented algorithms to cleanse the code from non-free math to maintain the patent-purity of the software. Cypherpunks of course reject such nonsense, just as they rejected RSA DSI's and David Sternlight's claims that PGP must not be used because it supposedly infringed on some patents. Do a Google search for IDEA and the name of your OS or distribution to find out how to recompile with IDEA support enabled. --Lucky
RE: IDEA
Mindfuq wrote: I compiling the Mixmaster remailer, I get an error the OpenSSL was not compiled with IDEA support. However, OpenSSL was supposed to have compiled with IDEA out of the box, with only an option to disable it. What am I missing? You in all likelihood fell victim to some misguided nonsense that seems to spread through the Open Source community at present. Some distributions have disabled IDEA and other patented algorithms to cleanse the code from non-free math to maintain the patent-purity of the software. Cypherpunks of course reject such nonsense, just as they rejected RSA DSI's and David Sternlight's claims that PGP must not be used because it supposedly infringed on some patents. Do a Google search for IDEA and the name of your OS or distribution to find out how to recompile with IDEA support enabled. --Lucky
RE: Switzerland: Another hit for phone privacy
Thomas Shaddack wrote: If anything, Twist (or how they changed the name after T-Mobile took over and screwed with things) (www.t-mobile.cz), Go (www.eurotel.cz), and Oskarta (Oscard, www.oskarmobil.cz) prepaid cards are quite common here. What Swisscom's EasyRoam pre-paid SIMs offered that no other pre-paid service that I am aware of offered, at least as of a year ago, was roaming in nearly every country that has GSM service. Most pre-paid SIMs are limited to roaming in just a few countries. In addition, EasyRoam was reasonably priced. Do the providers that you mention above offer global roaming on their pre-paids? Thanks, --Lucky
RE: Switzerland: Another hit for phone privacy
Thomas Shaddack wrote: If anything, Twist (or how they changed the name after T-Mobile took over and screwed with things) (www.t-mobile.cz), Go (www.eurotel.cz), and Oskarta (Oscard, www.oskarmobil.cz) prepaid cards are quite common here. What Swisscom's EasyRoam pre-paid SIMs offered that no other pre-paid service that I am aware of offered, at least as of a year ago, was roaming in nearly every country that has GSM service. Most pre-paid SIMs are limited to roaming in just a few countries. In addition, EasyRoam was reasonably priced. Do the providers that you mention above offer global roaming on their pre-paids? Thanks, --Lucky
CodeCon happenings [was: RE: Social democrats on our list]
Anon wrote quoting Tim: Does my right to control my own property vanish when I become a shop or restaurant? How about when I get larger? Renowned cypherpunk Dave Del Torto thinks it does. This is the argument that he was using to try to gain admittance to CodeCon this year, after being blacklisted by the producers due to disturbances at the previous year's CodeCon. Do you mean to say DDT could be wrong about his rights as a member of the public wishing to attend an event open to the public on private property? Renowned Cypherpunk? Some would consider deleterious to be a more appropriate word choice. At any rate, it is undisputed that the producers of CodeCon made it abundantly clear, in particular to DDT, that CodeCon was not open to the public, but open only to those that the producers had no reason to believe would act disruptively. CodeCon was held in a location licensed to sell alcoholic beverages and there is a reason why many bars have bouncers. I am not a lawyer, but I predict that the odds of anybody recovering damages for being 86'ed from a bar are slim indeed. Having attended CodeCon both last year and this year, I can say the following: last year, DDT repeatedly abused the QA periods of the highly-technical presentations not to ask questions about the technology, as was the purpose of the QA periods, but to deliver repeated, unwelcome, and frankly, annoying rants on the supposed merits of the Cryptorights Foundation. As was observed by others, DDT's inappropriate behavior cut into, and for some sessions absorbed virtually entirely, the time available for technical QA. I am grateful that the organizers of CodeCon had the courage to refuse admission to a potential attendee known to have been disruptive in the past. The technical QA sections of the program were all the more useful to the bona fide attendees because of it. Countless other attendees have expressed the same gratitude in private conversations. --Lucky
RE: The Wimps of War
Steve wrote quoting: PAUL KRUGMAN And though you don't hear much about it in the U.S. media, a lack of faith in Mr. Bush's staying power a fear that he will wimp out in the aftermath of war, that he won't do what is needed to rebuild Iraq is a large factor in the growing rift between Europe and the United States. And this matters how? Why would Bush, or for that matter the Europeans, care about rebuilding (what?) in Iraq? Other than the minimum investments required to prevent the population from rising up against their future leaders, why should the U.S. concern itself with making investments in Iraq not directly related to creating and maintaining oil extraction and transport facilities? --Lucky
RE: DOJ quietly drafts USA Patriot II w/crypto-in-a-crime penalty
Declan wrote: Note the draft legislation creates a new federal felony of willfully using encryption in the commission of a felony. No more than five years in prison plus a hefty fine. This seems at first glance to be remarkably similar to what was in the SAFE bill years ago. Here's a Politech message from 1998, before the politechbot.com archives: http://www.inet-one.com/cypherpunks/dir.98.05.11-98.05.17/msg0 0046.html Question: When encryption is omnipresent in everything from wireless networks to hard drives to SSH clients, might the basic effect of such a law be to boost potential maximum prison terms by five years? According to my reading of the text, the enhanced penalties only come into effect if the person happens to know that encryption is being used in the communication medium. In other words, the enhanced penalties only apply if the person is a past or present reader of the Cypherpunks or similar mailing lists. --Lucky Green
RE: DOJ quietly drafts USA Patriot II w/crypto-in-a-crime penalty
Declan wrote: Note the draft legislation creates a new federal felony of willfully using encryption in the commission of a felony. No more than five years in prison plus a hefty fine. This seems at first glance to be remarkably similar to what was in the SAFE bill years ago. Here's a Politech message from 1998, before the politechbot.com archives: http://www.inet-one.com/cypherpunks/dir.98.05.11-98.05.17/msg0 0046.html Question: When encryption is omnipresent in everything from wireless networks to hard drives to SSH clients, might the basic effect of such a law be to boost potential maximum prison terms by five years? According to my reading of the text, the enhanced penalties only come into effect if the person happens to know that encryption is being used in the communication medium. In other words, the enhanced penalties only apply if the person is a past or present reader of the Cypherpunks or similar mailing lists. --Lucky Green
RE: Encrypted hard drive enclosure for $139
Declan wrote: http://fwdepot.com/thestore/product_info.php?products_id=331 http://www.del trontech.com/Enclosure/E3S/E3S.htm Interesting, but I'm confused about the Real-time 64-bit/ 40-bit DES (Data Encryption Standard) Encryption/ Decryption with throughput of 712Mbit/ sec Does anyone know about a stronger version of a similar device? This looks very similar to the dLock device. http://www.enovatek.com.tw/realtime-hd.htm Perhaps they are using the same ASIC? If so, the product is pure crap. Based on conversations that I had with the booth staff at the last RSA conference, the dLock employs DES and 3DES in ECB mode. Meaning the ciphertext on disk can be broken with the most trivial of cryptanalysis. --Lucky
RE: Encrypted hard drive enclosure for $139
Declan wrote: http://fwdepot.com/thestore/product_info.php?products_id=331 http://www.del trontech.com/Enclosure/E3S/E3S.htm Interesting, but I'm confused about the Real-time 64-bit/ 40-bit DES (Data Encryption Standard) Encryption/ Decryption with throughput of 712Mbit/ sec Does anyone know about a stronger version of a similar device? This looks very similar to the dLock device. http://www.enovatek.com.tw/realtime-hd.htm Perhaps they are using the same ASIC? If so, the product is pure crap. Based on conversations that I had with the booth staff at the last RSA conference, the dLock employs DES and 3DES in ECB mode. Meaning the ciphertext on disk can be broken with the most trivial of cryptanalysis. --Lucky
RE: status of SMS encryption project?
Anonymous wrote: All (esp. lucky) - I was curious what the status of the SMS encryption project quoted in the below post is? [... Quoting Lucky] Anyway, the project I was thinking of related to encrypting SMS messages. I discovered that while it was possible to modify Nokia firmware to support SMS encryption, there were easier solutions by running the SMS through a PC. There are other projects underway that provide encrypted SMS messages using a Basic STAMP computer. Sorry, I am not in a position to disclose details at this time. Modified firmware: The code was never finished since easier and more maintainable solutions exist. See below. BASIC Stamp: I believe that code was completed. The SMS encryption protocol (SEMS) that grew out of that project has been published. SEMS has seen a bit of review from the community; the protocol is sufficiently simple to probably not hold any surprises. The protocol specs used to be at http://www.nah6.com/SEMS Unfortunately, this part of the NAH6 website is currently down for maintenance. I am told the site will be back up shortly. In the end, firmware low-level hacks to enable SMS encryption were obsoleted by Moore's Law. GSM smart phones/PDAs that run normal applications are easy to obtain at a reasonable price. Should you plan to write an SMS encryption application, you may wish to remain compatible with SEMS -- and be it for no other reason that SEMS has some non-zero deployed base. Hope that helps, --Lucky Green
RE: [IP] Limits Sought on Wireless Internet Access (fwd)
Industry executives say that military uses can coexist with the millions of smart wireless Internet devices that can sense the nearby use of military radar and automatically yield the right of way. These devices are in use in Europe and will soon be used in the United States. In other words, the new WaveLAN cards are shipping with a remote off-switch held by minor government officials. Let's recap the initiatives currently underway by both governments and major software vendors: Remote disabling of your OS. Remote disabling of your applications. Remote disabling of your network connectivity. Remote invalidation, if not downright alteration, of your digital documents. I wonder what they'll announce next. --Lucky Green
RE: Libel lunacy -all laws apply fnord everywhere
Steve wrote: This is totally bogus thinking. The Internet is not broadcast medium. Information from Web sites must be requested, the equivalent of ordering a book or newspaper, for delivery. Under this logic a retailer in one country, selling a controversial book to someone in another country, could involve publishers in yet a third country to litigation in the second country. Bizarre. The real question is whether any judgement is enforceable. Agreed. A few years ago, some would advocate that on the Internet, no national laws apply. This was, of course, nonsense. Instead, every single national, regional, and local law in effect today anywhere in the world applies to anything you do to the extent that said law can be enforced. --Lucky
RE: Libel lunacy -all laws apply fnord everywhere
Steve wrote: This is totally bogus thinking. The Internet is not broadcast medium. Information from Web sites must be requested, the equivalent of ordering a book or newspaper, for delivery. Under this logic a retailer in one country, selling a controversial book to someone in another country, could involve publishers in yet a third country to litigation in the second country. Bizarre. The real question is whether any judgement is enforceable. Agreed. A few years ago, some would advocate that on the Internet, no national laws apply. This was, of course, nonsense. Instead, every single national, regional, and local law in effect today anywhere in the world applies to anything you do to the extent that said law can be enforced. --Lucky
RE: Photographer Arrested For Taking Pictures Of Vice President'S Hotel
James A. Donald wrote: In general wars lead to a major temporary reduction in liberty, but a smaller permanent reduction in liberty. Unfortunately the war on terror will probably never end, so there will be no recovery. I heard some governmental official on the radio the other day (I paid attention too late to catch the name) that the War on Terrorism should be won in about 60 years, at which point the American citizens would see their civil liberties returned. Obviously, only traitors, agitators, and other enemy combatants would make the outrageous claim that this war will likely last perpetually. --Lucky
RE: How to Stop Telemarketers...
Adam Stenseth wrote: Just for my own edification, does this apply to landline service as well(or other government-sanctioned monopolies)? For example, are your calling habits and landline number assets of your phone company? Many of them seem to think so. Yes, they are. Just as the details of your credit card transactions are the property of the credit card company. Which is why your detailed transaction records, including your name, are available for sale from your credit company to anybody that wants to buy thousands of them. --Lucky
RE: Build It Rolling Your Own Tivo (fwd)
Jamie Lawrence wrote: Jim, you post enough crap from Slashdot to know differently. People are doing it. I have a whitebox machine (AMD, 256M ram, cheap TV card, 20G disk, $300 a year ago) that does it. It isn't a big deal. Speaking of posting crap...and don't send me private email. Don't worry about me sending private email in the future... You're not only a complete idiot, but you're rude as fuck as well. It never ceases to amaze me that there are subscribers to this list that don't have Choate filtered. This must be some weird list to read without a Choate procmail filter... --Lucky, who probably should go back to filtering on Choate in the body text of emails, not just in the headers. I didn't even need to see that email.
RE: Build It Rolling Your Own Tivo (fwd)
Jamie Lawrence wrote: Jim, you post enough crap from Slashdot to know differently. People are doing it. I have a whitebox machine (AMD, 256M ram, cheap TV card, 20G disk, $300 a year ago) that does it. It isn't a big deal. Speaking of posting crap...and don't send me private email. Don't worry about me sending private email in the future... You're not only a complete idiot, but you're rude as fuck as well. It never ceases to amaze me that there are subscribers to this list that don't have Choate filtered. This must be some weird list to read without a Choate procmail filter... --Lucky, who probably should go back to filtering on Choate in the body text of emails, not just in the headers. I didn't even need to see that email.
RE: How to Stop Telemarketers...
Adam Stenseth wrote: Just for my own edification, does this apply to landline service as well(or other government-sanctioned monopolies)? For example, are your calling habits and landline number assets of your phone company? Many of them seem to think so. Yes, they are. Just as the details of your credit card transactions are the property of the credit card company. Which is why your detailed transaction records, including your name, are available for sale from your credit company to anybody that wants to buy thousands of them. --Lucky
RE: How to Stop Telemarketers...
Harmon Seaver wrote: Tim mentioned cell phones and the lack of telemarketing calls on his, but really that's only because, at this point at least, the cellphone number lists haven't been sold. This might change in the near future, as several wireless providers have been considering selling their subscriber lists. It's hard to see how they could do this, however, since, unlike landline calls -- annoying enough -- spam calls to your cellphone would cost *you* money. Given this fact, one wonders why the cell phone providers have not yet made the list available for download by anybody. Well, they'll figure it out in due time. --Lucky
RE: stego building
Anonymous wrote quoting Lucky: A reasonable guess, but wrong. The building is a computing and processing center for Bank of America. That's where your checks go after you deposit them at the bank. The CO for this area is a few blocks away on Mc Coppin. The brick building with the Pac Bell logo on it. You can see the frame through the windows. Yes, this CO has been around for long enough to have windows. Both wrong. BA building is accross the mentioned one (accross 11th) and clearly marked. There are two BofA buildings on either side of 11th Street. One is housing a BofA branch with numerous ATMs outside. That building is indeed clearly marked as a BofA building. But that's not the building in question. The building in question is the one across 11th, which has its building entrance on Market next to a ground-level convenience store. While the ground level of that building houses stores, the remainder of the building is occupied by BofA's processing center. The CO is metal-plated pacbel building on Folsom and 2nd. Well, of course there is more than one CO in San Francisco. The CO closed to the mystery building is the CO on Mc Coppin. As I pointed out in my original email, you can see the frame through the windows. FYI, Mc Coppin is *a lot* closer to 11th Market than is 2nd and Folsom. --Lucky
RE: stego building
Anonymous wrote quoting Lucky: A reasonable guess, but wrong. The building is a computing and processing center for Bank of America. That's where your checks go after you deposit them at the bank. The CO for this area is a few blocks away on Mc Coppin. The brick building with the Pac Bell logo on it. You can see the frame through the windows. Yes, this CO has been around for long enough to have windows. Both wrong. BA building is accross the mentioned one (accross 11th) and clearly marked. There are two BofA buildings on either side of 11th Street. One is housing a BofA branch with numerous ATMs outside. That building is indeed clearly marked as a BofA building. But that's not the building in question. The building in question is the one across 11th, which has its building entrance on Market next to a ground-level convenience store. While the ground level of that building houses stores, the remainder of the building is occupied by BofA's processing center. The CO is metal-plated pacbel building on Folsom and 2nd. Well, of course there is more than one CO in San Francisco. The CO closed to the mystery building is the CO on Mc Coppin. As I pointed out in my original email, you can see the frame through the windows. FYI, Mc Coppin is *a lot* closer to 11th Market than is 2nd and Folsom. --Lucky
RE: stego building
Major wrote: At 11:49 PM 11/24/02 +0100, Tarapia Tapioco wrote: There is a huge concrete building, hardly any windows, occupying the whole block-width between Market and Mission streets in san francisco, one side being 11th street. Funny thing is that it has no markings at all. The main entrance seems to be at 14xx Market, with visible security. Any clues appreciated. Telco central office. Lots of copper loop I/O, and a big switch. Used to be mechanical crossbars. Probably a diesel generator somewhere. A reasonable guess, but wrong. The building is a computing and processing center for Bank of America. That's where your checks go after you deposit them at the bank. The CO for this area is a few blocks away on Mc Coppin. The brick building with the Pac Bell logo on it. You can see the frame through the windows. Yes, this CO has been around for long enough to have windows. --Lucky Green
RE: Torture done correctly is a terminal process
Adam wrote: The Russians, Americans and I believe others have moved from physical to psychological methods which have proven to work better than actual physical pain. I recall reading a story on Abdul Murad, the Al Qaeda member arrested in 1995 in the Philipines, where the way they finally got him to talk ws threatening him with being turned over to the Israelis. I recently obtained an illuminating recording of a speech by a judge sitting on the 9th Circuit Court of Appeals which was given before the San Francisco Commonwealth Club. In said recording, the honorable judge proposes the issuance of formal federal torture warrants. The reader may or may not take comfort in the fact that the honorable judge firmly insists that the needles he proposes to be inserted under the fingernails of suspects should be sterile. Clearly, at least hygiene has progressed in the last 300 years. --Lucky Green
RE: Emergency Coercive Unit
Tyler wrote: b) Downstairs and across the street in front of Starbucks I just saw two NYC cops holding what looked like AK-47s...on their backs it said Emergency Coercive Unit. A URL with pictures of that team would be appreciated. --Lucky
Transparent drive encryption now in FreeBSD
FreeBSD's 5.0 release, due out in a couple of weeks, will offer much anticipated transparent mass storage encryption. Subscribers to this list so inclined are encouraged to review and test this new feature. URLs: http://www.freebsd.org/cgi/cvsweb.cgi/src/sbin/gbde/ http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/geom/bde/ Thanks, --Lucky Green
RE: Transparent drive encryption now in FreeBSD
Tyler wrote: Sorry, I'm new, but does this refer to the notion of splitting up a document holographically, and placing the various pieces of numerous servers throughout the 'Net? (Any one piece will probably not contain a complete copy of the information, and is encrypted too, sot that it is not possible to say that Server X holds forbidden piece of info Y.) Andas I remember, removal of any one (or multiple) pieces on varying servers will do nothing towards elimating that content from the Universe. FreeBSD's new GBDE subsystem has a different objective: it simply provides for local drive-level encryption. I called it a mass storage encryption system since the encryption is not necessarily limited to hard drives, but could be used for other file systems, such as those on a USB token or MemoryStick. The URLs in my original post explain some of the details of what GBDE offers. [...] FreeBSD's 5.0 release, due out in a couple of weeks, will offer much anticipated transparent mass storage encryption. Subscribers to this list so inclined are encouraged to review and test this new feature. URLs: http://www.freebsd.org/cgi/cvsweb.cgi/src/sbin/gbde/ http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/geom/bde/ Thanks, --Lucky Green _ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus
Transparent drive encryption now in FreeBSD
FreeBSD's 5.0 release, due out in a couple of weeks, will offer much anticipated transparent mass storage encryption. Subscribers to this list so inclined are encouraged to review and test this new feature. URLs: http://www.freebsd.org/cgi/cvsweb.cgi/src/sbin/gbde/ http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/geom/bde/ Thanks, --Lucky Green
RE: Intel's LaGrab
Tim wrote: Microsoft calls its technology Palladium. Intel dubs it LaGrande. I say we call it LaGrab. Has anybody on the list seen any official specs, datasheets, etc. for Intel's LaGrande feature set? Any documents that could be donated to Cryptome's collection? So far, all I have been able to locate are vague press releases, marketing blather, and wild-eyed promises of hack-proofing computers. TIA, --Lucky
RE: Intel's LaGrab
Tim wrote: Microsoft calls its technology Palladium. Intel dubs it LaGrande. I say we call it LaGrab. Has anybody on the list seen any official specs, datasheets, etc. for Intel's LaGrande feature set? Any documents that could be donated to Cryptome's collection? So far, all I have been able to locate are vague press releases, marketing blather, and wild-eyed promises of hack-proofing computers. TIA, --Lucky
RE: What email encryption is actually in use?
Peter wrote [about the benefits of STARTTLS]: As opposed to more conventional encryption, where you're protecting nothing at any point along the chain, because 99.99% of the user base can't/won't use it. In any case most email is point-to-point, which means you are protecting the entire chain (that is, if I send you mail it may go through a few internal machines here or there, but once it hits the WAN it's straight from my gateway to yours). I must concur with Peter. The overwhelming majority of email recipients with whom I routinely exchange PGP encrypted email operates their own MTAs, located within their trust boundaries. Which should come as no surprise, since those with whom I discuss topics requiring secure communications tend to be conscious of security and thus like to be able to control the properties of their MTA and other network services. I also agree that current MTAs' implementations of STARTTLS are only a first step. At least in postfix, the only MTA with which I am sufficiently familiar to form an opinion, it appears impossible to require that certs presented by trusted parties match a particular hash while certs presented by untrusted MTAs can present any certificate they desire to achieve EDH-level security. I am aware that the certs presented by trusted parties could of course all be signed by the same CA, but this is an unworkable model in personal communications. What is required in practice is a list of trusted MTAs with corresponding hashes implemented at the MTA level. --Lucky Green
RE: What is the truth of the anti war rallys?
James wrote: Supposedly tens of thousands turned up, forty two thousand in San Francisco Yet oddly, the photos of marches that I see look more like forty in San Francisco, and four hundred in Washington. Perhaps there were a lot more out of frame, but that is an odd way to photograph a demonstration. Does anyone know the truth from his own eyes, or a more complete set of images? I can't speak to the peace marches this time around we are in war with Oceania, but last time when Bush senior attacked Iraq a peace march of at least a thousand people went right past my apartment in San Francisco. --Lucky
RE: What is the truth of the anti war rallys?
James wrote: Supposedly tens of thousands turned up, forty two thousand in San Francisco Yet oddly, the photos of marches that I see look more like forty in San Francisco, and four hundred in Washington. Perhaps there were a lot more out of frame, but that is an odd way to photograph a demonstration. Does anyone know the truth from his own eyes, or a more complete set of images? I can't speak to the peace marches this time around we are in war with Oceania, but last time when Bush senior attacked Iraq a peace march of at least a thousand people went right past my apartment in San Francisco. --Lucky
RE: What email encryption is actually in use?
Ben wrote: Lucky Green wrote: I also agree that current MTAs' implementations of STARTTLS are only a first step. At least in postfix, the only MTA with which I am sufficiently familiar to form an opinion, it appears impossible to require that certs presented by trusted parties match a particular hash while certs presented by untrusted MTAs can present any certificate they desire to achieve EDH-level security. This is probably a stupid question, but... why would you want to do this? To protect against MIM attacks on the encrypted tunnel between the trust domains represented by my friend's MTA and my MTA. --Lucky Green
RE: What email encryption is actually in use?
Peter wrote [about the benefits of STARTTLS]: As opposed to more conventional encryption, where you're protecting nothing at any point along the chain, because 99.99% of the user base can't/won't use it. In any case most email is point-to-point, which means you are protecting the entire chain (that is, if I send you mail it may go through a few internal machines here or there, but once it hits the WAN it's straight from my gateway to yours). I must concur with Peter. The overwhelming majority of email recipients with whom I routinely exchange PGP encrypted email operates their own MTAs, located within their trust boundaries. Which should come as no surprise, since those with whom I discuss topics requiring secure communications tend to be conscious of security and thus like to be able to control the properties of their MTA and other network services. I also agree that current MTAs' implementations of STARTTLS are only a first step. At least in postfix, the only MTA with which I am sufficiently familiar to form an opinion, it appears impossible to require that certs presented by trusted parties match a particular hash while certs presented by untrusted MTAs can present any certificate they desire to achieve EDH-level security. I am aware that the certs presented by trusted parties could of course all be signed by the same CA, but this is an unworkable model in personal communications. What is required in practice is a list of trusted MTAs with corresponding hashes implemented at the MTA level. --Lucky Green
Best Windows XP drive encryption program?
What are folks' recommendations here for drive encryption programs under Windows XP? Must encrypt the entire hard drive, loading before the OS, and support NTFS. I am in particular interested in first-hand experiences. Thanks, --Lucky Green
RE: Prosecutors' Contention That Hotmail E-mail Is Extremely Difficult To Trace
James wrote: On 5 Sep 2002 at 16:48, Steve Schear wrote: 3. After September 11, 2001, the FBI learned that Moussaoui had used a computer at Kinko s, in Eagan, Minnesota, to connect to the internet. When the FBI learned that Moussaoui had used a computer at Kinko s, the FBI investigated that Kinko s store and was informed that the Kinko s had since erased the data from its computers, as is Kinko s regular practice. Accordingly, the FBI did not seize the computers from Kinko s, Eagan, Minnesota. Moral: Always make erasing unneeded data a regular practice, if you want to keep your computers. Absolutely. Furthermore, encourage your customers to encrypt their data: Some European ISPs, fed up with the costs of complying with interception warrants and subpoenas, have begun to offer discounts to customers that exclusively utilize encrypting protocols. The logic being that it is cheaper to notify law enforcement that the ISP is unable to tap the information due to the link being encrypted than it is to tap a link. --Lucky Green
RE: Prosecutors' Contention That Hotmail E-mail Is Extremely Difficult To Trace
James wrote: On 5 Sep 2002 at 16:48, Steve Schear wrote: 3. After September 11, 2001, the FBI learned that Moussaoui had used a computer at Kinko s, in Eagan, Minnesota, to connect to the internet. When the FBI learned that Moussaoui had used a computer at Kinko s, the FBI investigated that Kinko s store and was informed that the Kinko s had since erased the data from its computers, as is Kinko s regular practice. Accordingly, the FBI did not seize the computers from Kinko s, Eagan, Minnesota. Moral: Always make erasing unneeded data a regular practice, if you want to keep your computers. Absolutely. Furthermore, encourage your customers to encrypt their data: Some European ISPs, fed up with the costs of complying with interception warrants and subpoenas, have begun to offer discounts to customers that exclusively utilize encrypting protocols. The logic being that it is cheaper to notify law enforcement that the ISP is unable to tap the information due to the link being encrypted than it is to tap a link. --Lucky Green
RE: S/MIME in Outlook -- fucked.
Meyer Wolfsheim wrote: ... just making certain Lucky has seen this gem. Lucky reads Bugtraq daily. :) --Lucky Green
RE: S/MIME in Outlook -- fucked.
Meyer Wolfsheim wrote: ... just making certain Lucky has seen this gem. Lucky reads Bugtraq daily. :) --Lucky Green
RE: right MTA for crypto support
Eric wrote: On Tue, Aug 27, 2002 at 11:53:08AM +0200, Eugen Leitl wrote: I'm getting rather pissed at diverse wiretap legislations making the global rounds (lately EU is making noises towards storing a one year deep FIFO of all email and browsing traffic for all users), and would like to run my own MTA, with MX fallback to ISPs. I would like to have secure MUA-MTA (IMAP/SSL POP/SSL and MTA-MTA (if the other end supports it). lne.com's sendmail now supports START_TLS. Not that that adds any security to cpunks list mail of course. But it does increase the amount of encrypted traffic. There are a bunch of projects that either work on or have completed integration of PGP at the MTA-level. A post to the OpenPGP lists should round up the candidates. Either way, I agree with Eric that turning on STARTTLS support in MTA's has become so easy that I would be hard pressed to come up with reasons why one wouldn't. I know that enabling STARTTLS is trivial in postfix and I am told that STARTTLS ships with exim and at least the Debian build of sendmail. Either way, I would recommend to first enable STARTTLS in your MTA and only after that start looking at PGP integrations. (I fully understand that STARTTLS and PGP fulfill different needs and address different thread models). --Lucky Green
RE: TCPA hack delay appeal
AARG! Wrote: It seems that there is (a rather brilliant) way to bypass TCPA (as spec-ed.) I learned about it from two separate sources, looks like two independent slightly different hacks based on the same protocol flaw. Undoubtedly, more people will figure this out. Hopefully some of those people will not limit themselves to hypothetical attacks against The Spec, but will actually test those supposed attacks on shipping TPMs. Which are readily available in high-end IBM laptops. --Lucky Green
RE: TCPA hack delay appeal
AARG! Wrote: It seems that there is (a rather brilliant) way to bypass TCPA (as spec-ed.) I learned about it from two separate sources, looks like two independent slightly different hacks based on the same protocol flaw. Undoubtedly, more people will figure this out. Hopefully some of those people will not limit themselves to hypothetical attacks against The Spec, but will actually test those supposed attacks on shipping TPMs. Which are readily available in high-end IBM laptops. --Lucky Green
RE: A faster way to factor prime numbers found?
Gary Jeffers Sent: Tuesday, August 13, 2002 3:07 PM To: [EMAIL PROTECTED] Subject: A faster way to factor prime numbers found? A faster way to factor prime numbers found? AFICT, the proposed algorithm is for a test for primality and does not represent an algorithm to factor composites. My fellow Cypherpunks, I found an interesting report of a newly developed algorithm for factoring prime numbers. It was on the very interesting http://www.whatreallyhappened.com site. - check that site out! The 1st link is titled: Mathematicians in India find a faster way to determine prime numbers. http://www.iitk.ac.in/infocell/announce/algori thm The 2nd link is titled: Here is the algorithm! http://www.whatreallyhappened.com/primality.pdf Yours Truly, Gary Jeffers Beat State!!! and all the many other oppressors!
RE: A faster way to factor prime numbers found?
Gary Jeffers Sent: Tuesday, August 13, 2002 3:07 PM To: [EMAIL PROTECTED] Subject: A faster way to factor prime numbers found? A faster way to factor prime numbers found? AFICT, the proposed algorithm is for a test for primality and does not represent an algorithm to factor composites. My fellow Cypherpunks, I found an interesting report of a newly developed algorithm for factoring prime numbers. It was on the very interesting http://www.whatreallyhappened.com site. - check that site out! The 1st link is titled: Mathematicians in India find a faster way to determine prime numbers. http://www.iitk.ac.in/infocell/announce/algori thm The 2nd link is titled: Here is the algorithm! http://www.whatreallyhappened.com/primality.pdf Yours Truly, Gary Jeffers Beat State!!! and all the many other oppressors!
RE: Seth on TCPA at Defcon/Usenix
David wrote: AARG! Anonymous wrote: 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. Well, sure. It's certainly how I had always envisioned one might build a secure Document Revocation List using TCPA or Palladium. I didn't realize this sort of thing would need explaining; I assumed it would be obvious to cypherpunk types. But I'm glad this risk is now clear. To ensure priority for my Monday filings, I must point out at this time that while AARG and David's methods of implementing a DRL are certainly feasible, I believe a preferred method of implementing a DRL would be to utilize features offered by an infrastructure, such as Palladium, that supports time-limited documents: rather than requiring online access whenever the document is attempted to be displayed, the document's display permissions would be renewed periodically. If the display software misses one or more updates, the document display software will cease to display the document. BTW, does anybody here know if there is still an email time stamping server in operation? The references that I found to such servers appear to be dead. Thanks, --Lucky
RE: Seth on TCPA at Defcon/Usenix
David wrote: AARG! Anonymous wrote: 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. Well, sure. It's certainly how I had always envisioned one might build a secure Document Revocation List using TCPA or Palladium. I didn't realize this sort of thing would need explaining; I assumed it would be obvious to cypherpunk types. But I'm glad this risk is now clear. To ensure priority for my Monday filings, I must point out at this time that while AARG and David's methods of implementing a DRL are certainly feasible, I believe a preferred method of implementing a DRL would be to utilize features offered by an infrastructure, such as Palladium, that supports time-limited documents: rather than requiring online access whenever the document is attempted to be displayed, the document's display permissions would be renewed periodically. If the display software misses one or more updates, the document display software will cease to display the document. BTW, does anybody here know if there is still an email time stamping server in operation? The references that I found to such servers appear to be dead. Thanks, --Lucky
RE: Signing as one member of a set of keys
Anonymous wrote: Here is the signature block from the ring signature program which got truncated. I'll try sending it through a few different anon remailers until it gets through. Replace the lines from the earlier posting starting with the END PGP PUBLIC KEY BLOCK line. I seem to still have problems with the signature block. If somebody on this list has a good copy, could you please place it on a web page and publish the URL? If nobody has a good copy, could perhaps Anonymous try a different method of posting, such as uuencoding? Thanks, --Lucky
FAQ: How will Microsoft respond to Lucky's patent application?
not anticipate that Microsoft will challenge the patent. Lastly, I feel obliged to mention that it is quite irrelevant what I, Microsoft, or the subscribers to this list believe to be the case with respect to my patent application. All that matters is what the patent examiner at the USPTO believes. Unless one of the subscribers to this list happens to work as a patent examiner. --Lucky Green
Utilizing Palladium against software piracy
I would like to again thank the Palladium team, in particular Peter Biddle, for participating in yesterday's panel at the USENIX Security conference on Palladium and TCPA. Unfortunately I do not have the time at the moment to write up the many valuable and informative points made during the panel discussion. I will, however, highlight one such issue: As Peter pointed out, while the Palladium effort was started to meet the content protection requirements of digital video content providers, he also pointed out that Microsoft and its Palladium group have so far been unable to determine a method in which Palladium could be utilized to assist in the efforts against application software piracy. As Peter mentioned, the Palladium team on several occasions had to tell the Microsoft's anti-piracy group that Palladium is unsuitable to assist in software (as distinct from content) licensing and anti-piracy efforts. Since Microsoft is not aware of a method to utilize the Palladium environment in the enforcement of software licenses, Peter argued, Microsoft does not intend to and will not utilize Palladium to assist in the enforcement of software licensing. 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. --Lucky Green
RE: Challenge to TCPA/Palladium detractors
Anonymous wrote: Matt Crawford replied: Unless the application author can predict the exact output of the compilers, he can't issue a signature on the object code. The compilers then have to be inside the trusted base, checking a signature on the source code and reflecting it somehow through a signature they create for the object code. It's likely that only a limited number of compiler configurations would be in common use, and signatures on the executables produced by each of those could be provided. Then all the app writer has to do is to tell people, get compiler version so-and-so and compile with that, and your object will match the hash my app looks for. DEI The above view may be overly optimistic. IIRC, nobody outside PGP was ever able to compile a PGP binary from source that matched the hash of the binaries built by PGP. --Lucky Green
Utilizing Palladium against software piracy
I would like to again thank the Palladium team, in particular Peter Biddle, for participating in yesterday's panel at the USENIX Security conference on Palladium and TCPA. Unfortunately I do not have the time at the moment to write up the many valuable and informative points made during the panel discussion. I will, however, highlight one such issue: As Peter pointed out, while the Palladium effort was started to meet the content protection requirements of digital video content providers, he also pointed out that Microsoft and its Palladium group have so far been unable to determine a method in which Palladium could be utilized to assist in the efforts against application software piracy. As Peter mentioned, the Palladium team on several occasions had to tell the Microsoft's anti-piracy group that Palladium is unsuitable to assist in software (as distinct from content) licensing and anti-piracy efforts. Since Microsoft is not aware of a method to utilize the Palladium environment in the enforcement of software licenses, Peter argued, Microsoft does not intend to and will not utilize Palladium to assist in the enforcement of software licensing. 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. --Lucky Green
RE: White House Sounds Call For New Internet Standards
Steve wrote: The Bush administration's cyber security czar, Richard Clarke, said it might be time to replace the creaky, cranky 20-year-old protocols that drive the Internet with standards better able to accommodate a flood of new wireless devices. Wireless devices, it is feared, may introduce large security holes to the network. The White House is working with the private sector to draft a national plan to secure the country's most vital computer networks from cyber attack. How about IPv6 with IPSEC? --Lucky
RE: IP: SSL Certificate Monopoly Bears Financial Fruit
RJ Harvey wrote: Thanks for the tip! I just got a new cert from Geotrust, and it was such an amazing contrast to those I've gotten from Verisign and Thawte! They apparently take the verification info from the whois data on the site, and you really can do the process from start to finish in 10 minutes or so. I believe that Geotrust has come up with an excellent new model to make money out of the CA business with minimum hassle to the customer while reducing Geotrust's vetting costs down to next to zero. Their introduction of this new model was one of the more interesting news at this year's otherwise rather bland RSA Conference. The cert shows that it's issued by Equifax, however. The cert shows as being issued by Equifax because Geotrust purchased Equifax's root embedded in major browsers since MSIE 5 on the secondary market. (Geotrust purchased more than just the root). --Lucky Green
RE: DNA databases to be classified
keyser-soze wrote: Scientists build polio virus from scratch Scientists have built the virus that causes polio from scratch in the lab, using nothing more than genetic sequence information from public databases and readily available technology. The feat proves that even if all the polio virus in the world were destroyed, it would be easily possible to resurrect the crippling disease. It also raises the worrying possibility that bioterrorists could use a similar approach to create devastating diseases such as ebola and smallpox without having to gain access to protected viral stocks. I hope they don't try to patent this since I produced prior art for the in vitro generation of human pathogens from genetic sequences going back to at least 1995. To quote Eric Hughes: In the end it is all software. --Lucky Green
Bluetooth PC adapter supporting headset profile?
[Yes, there is a crypto relevance to this post]. I am trying to find a Bluetooth adapter that will permit the use of a Bluetooth headset as the input to a PC's sound mixer under Windows XP. Various websites claim that such products exist, but attempts to purchase such devices in my experience invariably lead to other websites that require the installation of double-byte character sets which I would not be able to read at any rate. If you have first-hand experience using a PC Bluetooth adapter with a Bluetooth headset, please get in touch with me. TIA, --Lucky Green
RE: Ross's TCPA paper
Peter wrote (potentially quoting somebody else) From a purely economic perspectice, I can't see how this will fly. I'll pull a random figure of $5 out of thin air (well, I saw it mentioned somewhere but can't remember the source) as the additional manufacturing cost for the TCPA hardware components. $5 marginal cost for the inclusion of a TPM would have been flat-out unacceptable to the motherboard manufacturers. --Lucky Green
RE: IP: SSL Certificate Monopoly Bears Financial Fruit
Adam wrote: On Fri, Jul 12, 2002 at 11:18:12AM -0400, Trei, Peter wrote: A 'second hand' root key seems to have some trust issues | - the thing you are buying is the private half of a public key pair | but that's just a piece of information. How can you be sure that, | as purchaser, you are the *only* possessor of the key, and no one else | has another copy (the seller, for example)? Who cares? If I can get a key thats in the main browsers for 90% off, who cares if other people have it? I understand that getting the public half of the 2 main browsers will run you about $250k in fees, plus all the setup work. If I can buy a slightly used Ncipher box whose public key bits are in the browsers for a 10th to a 5th of that, the extra copies of the bits aren't all that worrisome to me. Precisely. Nor would worrying make any difference, since all CAs preinstalled into the browser are equal from a user perspective. The security your CA, or VeriSign's CA, or anybody's CA can afford their customer is subject to an upper bound set by the preinstalled CA with the laxest certificate issuance standards in existence. In other words, anybody who selects a public CA on a factor other than price likely fails to understand the trust models that underlie today's use of Certificate Authorities. However, $250k will not nearly get you into the major browsers. Getting into Netscape is easy. You just hand them the cash and the floppy with your public key. Getting into MSIE is a lot harder. MSFT has never charged to include a CA's key in MSIE and MSFT does not intend on charging in the future. But after the root CA bonanza for MSIE 5, MSFT instituted policy changes. To get your CA's key included in MSIE, the CA must have passed an SAS 70 audit. (The CA also must offer its certificates to the public). The infrastructure, policy, staff, and auditing costs of passing such an audit will run you upwards of $500k. By the end of the day, getting a new root into the browsers will cost you about, give or take a few hundred k, $1M. Which makes the slightly used nCipher box an even better value. :-) --Lucky Green
Bluetooth PC adapter supporting headset profile?
[Yes, there is a crypto relevance to this post]. I am trying to find a Bluetooth adapter that will permit the use of a Bluetooth headset as the input to a PC's sound mixer under Windows XP. Various websites claim that such products exist, but attempts to purchase such devices in my experience invariably lead to other websites that require the installation of double-byte character sets which I would not be able to read at any rate. If you have first-hand experience using a PC Bluetooth adapter with a Bluetooth headset, please get in touch with me. TIA, --Lucky Green
RE: DNA databases to be classified
keyser-soze wrote: Scientists build polio virus from scratch Scientists have built the virus that causes polio from scratch in the lab, using nothing more than genetic sequence information from public databases and readily available technology. The feat proves that even if all the polio virus in the world were destroyed, it would be easily possible to resurrect the crippling disease. It also raises the worrying possibility that bioterrorists could use a similar approach to create devastating diseases such as ebola and smallpox without having to gain access to protected viral stocks. I hope they don't try to patent this since I produced prior art for the in vitro generation of human pathogens from genetic sequences going back to at least 1995. To quote Eric Hughes: In the end it is all software. --Lucky Green
RE: IP: SSL Certificate Monopoly Bears Financial Fruit
Adam wrote: On Fri, Jul 12, 2002 at 11:18:12AM -0400, Trei, Peter wrote: A 'second hand' root key seems to have some trust issues | - the thing you are buying is the private half of a public key pair | but that's just a piece of information. How can you be sure that, | as purchaser, you are the *only* possessor of the key, and no one else | has another copy (the seller, for example)? Who cares? If I can get a key thats in the main browsers for 90% off, who cares if other people have it? I understand that getting the public half of the 2 main browsers will run you about $250k in fees, plus all the setup work. If I can buy a slightly used Ncipher box whose public key bits are in the browsers for a 10th to a 5th of that, the extra copies of the bits aren't all that worrisome to me. Precisely. Nor would worrying make any difference, since all CAs preinstalled into the browser are equal from a user perspective. The security your CA, or VeriSign's CA, or anybody's CA can afford their customer is subject to an upper bound set by the preinstalled CA with the laxest certificate issuance standards in existence. In other words, anybody who selects a public CA on a factor other than price likely fails to understand the trust models that underlie today's use of Certificate Authorities. However, $250k will not nearly get you into the major browsers. Getting into Netscape is easy. You just hand them the cash and the floppy with your public key. Getting into MSIE is a lot harder. MSFT has never charged to include a CA's key in MSIE and MSFT does not intend on charging in the future. But after the root CA bonanza for MSIE 5, MSFT instituted policy changes. To get your CA's key included in MSIE, the CA must have passed an SAS 70 audit. (The CA also must offer its certificates to the public). The infrastructure, policy, staff, and auditing costs of passing such an audit will run you upwards of $500k. By the end of the day, getting a new root into the browsers will cost you about, give or take a few hundred k, $1M. Which makes the slightly used nCipher box an even better value. :-) --Lucky Green
RE: IP: SSL Certificate Monopoly Bears Financial Fruit
James wrote: On 11 Jul 2002 at 1:22, Lucky Green wrote: Trusted roots have long been bought and sold on the secondary market as any other commodity. For surprisingly low amounts, you too can own a trusted root that comes pre-installed in 95% of all web browsers deployed. How much, typically? I'd rather not state the exact figures. A search of SEC filings may or may not turn up further details. And who actually owns these numerous trusted roots? I am not sure I understand the question. --Lucky
TPM cost constraint [was: RE: Revenge of the WAVEoid]
Bill wrote: At 10:07 PM 06/26/2002 -0700, Lucky Green wrote: An EMBASSY-like CPU security co-processor would have seriously blown the part cost design constraint on the TPM by an order of magnitude or two. Compared to the cost of rewriting Windows to have a infrastructure that can support real security? Maybe, but I'm inclined to doubt it, especially since most of the functions that an off-CPU security co-processor can successfully perform are low enough performance that they could be done on a PCI or PCMCIA card, without requiring motherboard space. Upon re-reading the paragraph I wrote, I can see how the text might have been ambiguous. I was trying to express that there was a cost constraint on the part. Adding the cost of an EMBASSY or SEE environment to the purchase of every new PC is more than the market for bare-bones or even mid-range PC's will bear. --Lucky
TPM cost constraint [was: RE: Revenge of the WAVEoid]
Bill wrote: At 10:07 PM 06/26/2002 -0700, Lucky Green wrote: An EMBASSY-like CPU security co-processor would have seriously blown the part cost design constraint on the TPM by an order of magnitude or two. Compared to the cost of rewriting Windows to have a infrastructure that can support real security? Maybe, but I'm inclined to doubt it, especially since most of the functions that an off-CPU security co-processor can successfully perform are low enough performance that they could be done on a PCI or PCMCIA card, without requiring motherboard space. Upon re-reading the paragraph I wrote, I can see how the text might have been ambiguous. I was trying to express that there was a cost constraint on the part. Adding the cost of an EMBASSY or SEE environment to the purchase of every new PC is more than the market for bare-bones or even mid-range PC's will bear. --Lucky
RE: Ross's TCPA paper
Hadmut Danisch wrote: On Wed, Jul 03, 2002 at 10:54:43PM -0700, Bill Stewart wrote: At 12:59 AM 06/27/2002 -0700, Lucky Green wrote: I fully agree that the TCPA's efforts offer potentially beneficial effects. Assuming the TPM has not been compromised, the TPM should enable to detect if interested parties have replaced you NIC with the rarer, but not unheard of, variant that ships out the contents of your operating RAM via DMA and IP padding outside the abilities of your OS to detect. It can? I thought that DMA was there to let you avoid bothering the CPU. The Alternate NIC card would need to have a CPU of its own to do a good job of this, but that's not hard. I don't think so. As far as I understood, the bus system (PCI,...) will be encrypted as well. You'll have to use a NIC which is certified and can decrypt the information on the bus. Obviously, you won't get a certification for such an network card. You won't and Bill won't. But those who employ such NIC's will have no difficulty obtaining certification. But this implies other problems: You won't be able to enter a simple shell script through the keyboard. If so, you could simple print protected files as a hexdump or use the screen (or maybe the sound device or any LED) as a serial interface. Since you could use the keyboard to enter a non-certified program, the keyboard is to be considered as a nontrusted device. This means that you either * have to use a certified keyboard which doesn't let you enter bad programs * don't have a keyboard at all * or are not able to use shell scripts (at least not in trusted context). This means a strict separation between certified software and data. Sure you can use shell scripts. Though I don't understand how a shell script will help you in obtaining a dump of the protected data since your script has insufficient privileges to read the data. Nor can you give the shell script those privileges since you don't have supervisor mode access to the CPU. How does your shell script plan to get past the memory protection? What am I missing? --Lucky
RE: Ross's TCPA paper
David wrote: It's not clear that enabling anti-competitive behavior is good for society. After all, there's a reason we have anti-trust law. Ross Anderson's point -- and it seems to me it's one worth considering -- is that, if there are potentially harmful effects that come with the beneficial effects, maybe we should think about them in advance. I fully agree that the TCPA's efforts offer potentially beneficial effects. Assuming the TPM has not been compromised, the TPM should enable to detect if interested parties have replaced you NIC with the rarer, but not unheard of, variant that ships out the contents of your operating RAM via DMA and IP padding outside the abilities of your OS to detect. However, enabling platform security, as much as might be stressed otherwise by the stakeholders, has never been the motive behind the TCPA. The motive has been DRM. Does this mean that one should ignore the benefits that TCPA might bring? Of course not. But it does mean that one should carefully weigh the benefits against the risks. --Lucky Green
RE: DRMs vs internet privacy (Re: Ross's TCPA paper)
Adam Back wrote: I don't mean that you would necessarily have to correlate your viewing habits with your TrueName for DRM systems. Though that is mostly (exclusively?) the case for current deployed (or at least implemented with a view of attempting commercial deployment) copy-mark (fingerprint) systems, there are a number of approaches which have been suggested, or could be used to have viewing privacy. The TCPA specs were carefully designed to permit the user to obtain multiple certificates from multiple CA's and thus, if, and that's a big if, the CA's don't collude and furthermore indeed discard the true name identities of the customer, utilize multiple separate identities for various online applications. I.e., the user could have one cert for their True Name, one used to enable Microsoft Office, and one to authenticate the user to other online services. It is very much the intent of the TCPA to permit the use of pseudonymous credentials for many, if not most, applications. Otherwise, the TCPA's carefully planned attempts at winning over the online liberty groups would have been doomed from the start. --Lucky Green
RE: Ross's TCPA paper
David wrote: It's not clear that enabling anti-competitive behavior is good for society. After all, there's a reason we have anti-trust law. Ross Anderson's point -- and it seems to me it's one worth considering -- is that, if there are potentially harmful effects that come with the beneficial effects, maybe we should think about them in advance. I fully agree that the TCPA's efforts offer potentially beneficial effects. Assuming the TPM has not been compromised, the TPM should enable to detect if interested parties have replaced you NIC with the rarer, but not unheard of, variant that ships out the contents of your operating RAM via DMA and IP padding outside the abilities of your OS to detect. However, enabling platform security, as much as might be stressed otherwise by the stakeholders, has never been the motive behind the TCPA. The motive has been DRM. Does this mean that one should ignore the benefits that TCPA might bring? Of course not. But it does mean that one should carefully weigh the benefits against the risks. --Lucky Green
Two additional TCPA/Palladium plays
to a court order, as might be given if the author of the document were to distribute DeCSS v3 or Scientology scriptures in the future DRM protected format. All that is required to perform such an administrative invalidation of a document is either a sample copy of the document from which one can obtain its globally unique ID, the serial number of the application that created the document, or the public key of the person who licensed the application. (Other ways to exist but are omitted in the interest of brevity). --Lucky Green
RE: Revenge of the WAVEoids: Palladium Clues May Lie In AMD Motherboard Design
Bob wrote quoting Mark Hachman: The whitepaper can not be considered a roadmap to the design of a Palladium-enabled PC, although it is one practical solution. The whitepaper was written at around the time the Trusted Computing Platform Association (TCPA) was formed in the fall of 2000; both Wave and AMD belong to the TCPA. And, while Palladium uses some form of CPU-level processing of security algorithms, the AMD-Wave whitepaper's example seems wholly tied to an off-chip security processor, the EMBASSY. An EMBASSY-like CPU security co-processor would have seriously blown the part cost design constraint on the TPM by an order of magnitude or two. I am not asserting that security solutions that require special-purpose CPU functionality are not in the queue, they very much are, but not in the first phase. This level of functionality has been deferred to a second phase in which security processing functionality can be moved into the core CPU, since a second CPU-like part is unjustifiable from a cost perspective. Given the length of CPU design cycles and the massive cost of architecting new functionality into a processor as complex as a modern CPU, we may or may not see this functionality shipping. Much depends on how well phase 1 of the TCPA effort fares. --Lucky
Two additional TCPA/Palladium plays
to a court order, as might be given if the author of the document were to distribute DeCSS v3 or Scientology scriptures in the future DRM protected format. All that is required to perform such an administrative invalidation of a document is either a sample copy of the document from which one can obtain its globally unique ID, the serial number of the application that created the document, or the public key of the person who licensed the application. (Other ways to exist but are omitted in the interest of brevity). --Lucky Green
RE: DRMs vs internet privacy (Re: Ross's TCPA paper)
Adam Back wrote: I don't mean that you would necessarily have to correlate your viewing habits with your TrueName for DRM systems. Though that is mostly (exclusively?) the case for current deployed (or at least implemented with a view of attempting commercial deployment) copy-mark (fingerprint) systems, there are a number of approaches which have been suggested, or could be used to have viewing privacy. The TCPA specs were carefully designed to permit the user to obtain multiple certificates from multiple CA's and thus, if, and that's a big if, the CA's don't collude and furthermore indeed discard the true name identities of the customer, utilize multiple separate identities for various online applications. I.e., the user could have one cert for their True Name, one used to enable Microsoft Office, and one to authenticate the user to other online services. It is very much the intent of the TCPA to permit the use of pseudonymous credentials for many, if not most, applications. Otherwise, the TCPA's carefully planned attempts at winning over the online liberty groups would have been doomed from the start. --Lucky Green
RE: Revenge of the WAVEoids: Palladium Clues May Lie In AMD Motherboard Design
Bob wrote quoting Mark Hachman: The whitepaper can not be considered a roadmap to the design of a Palladium-enabled PC, although it is one practical solution. The whitepaper was written at around the time the Trusted Computing Platform Association (TCPA) was formed in the fall of 2000; both Wave and AMD belong to the TCPA. And, while Palladium uses some form of CPU-level processing of security algorithms, the AMD-Wave whitepaper's example seems wholly tied to an off-chip security processor, the EMBASSY. An EMBASSY-like CPU security co-processor would have seriously blown the part cost design constraint on the TPM by an order of magnitude or two. I am not asserting that security solutions that require special-purpose CPU functionality are not in the queue, they very much are, but not in the first phase. This level of functionality has been deferred to a second phase in which security processing functionality can be moved into the core CPU, since a second CPU-like part is unjustifiable from a cost perspective. Given the length of CPU design cycles and the massive cost of architecting new functionality into a processor as complex as a modern CPU, we may or may not see this functionality shipping. Much depends on how well phase 1 of the TCPA effort fares. --Lucky
RE: Steven Levy buys Microsoft's bullshit hook, line, and sinker
Bram wrote: http://www.msnbc.com/news/770511.asp?cp1=1 Of course, the TCPA has nothing to do with security or privacy, since those are OS-level things. All it can really do is ensure you're running a particular OS. It's amazing the TCPA isn't raising all kinds of red flags at the justice department already - it's the most flagrant attempt to stifle competition I've ever seen. [Bram is correct, stifling competition is one of the many features TCPA will enable. In more ways than one. And for more players than just Microsoft]. Coincidentally, Steven Levy's article that Bram is citing also helps answer Mr. Anonymous's question with which he challenged Ross and myself earlier today. First, however, I must apologize to the reader for my earlier, now incorrect, statement that TCPA member companies would deny that DRM is an objective of the TCPA. I had been unaware that, as evidenced by the publication of the Newsweek article, the public phase of the TCPA effort had already begun. What a bizarre coincidence for this phase, after all those years the TCPA effort and its predecessors have been underway, (the design, and in fact the entire architecture, has morphed substantially over the years) to be kicked off the very day of my post. [Tim: do you recall when we had the discussion about the upcoming encrypted op code chips at a Cypherpunks meeting in a Stanford lecture hall? Was that 1995 or 1996? It cannot have been later; I know that I was still working for DigiCash at the time because I remember giving a talk on compact endorsement signatures at the same meeting]. From Levy's article: Palladium [Microsoft's TCPA-based technology - LG] is being offered to the studios and record labels as a way to distribute music and film with digital rights management (DRM). This could allow users to exercise fair use (like making personal copies of a CD) and publishers could at least start releasing works that cut a compromise between free and locked-down. But a more interesting possibility is that Palladium could help introduce DRM to business and just plain people. It's a funny thing, says Bill Gates. We came at this thinking about music, but then we realized that e-mail and documents were far more interesting domains.' Another paragraph of the Newsweek article has this to say: In 1997, Peter Biddle, a Microsoft manager who used to run a paintball arena, was the company's liason to the DVD-drive world. Naturally, he began to think of ways to address Hollywood's fear of digital copying. He hooked up with [...] researchers Paul England and John Manferdelli, and they set up a skunkworks operation, stealing time from their regular jobs to pursue a preposterously ambitious idea-creating virtual vaults in Windows to protect information. They quickly understood that the problems of intellectual property were linked to problems of security and privacy. They also realized that if they wanted to foil hackers and intruders, at least part of the system had to be embedded in silicon, not software. Well, now that Bill Gates himself is being quoted stating that DRM was a driver behind the technology the TCPA is enabling (Microsoft is one of the companies that founded the TCPA and should be in a position to know), does Mr. Anonymous consider this sufficient evidence that the TCPA is being designed for the support of digital rights management (DRM) applications? Or does Anonymous continue to believe Ross and Lucky are making this stuff up out of whole cloth? To answer Anonymous's question as to whether the the TCPA [is] really, as [Ross and Lucky] claim, a secretive effort to get DRM hardware into consumer PCs?, I am not sure I would exactly call this fact a secret at this point. (Though by no means are all cards already on the table). DRM is a significant objective of some of the TCPA's member companies, which includes Microsoft. There are of course other objectives. Some of which Ross published, some which I mentioned, some which Steven Levy has published (though he largely fell for the designated bait and missed the numerous hooks), some which Bram has realized, and some which have yet to be talked about. Some desirable, some questionable, and a lot of them downright scary. Sincerely, --Lucky Green
RE: Ross's TCPA paper
Pete Chown wrote quoting Ross: You need a valid signature on the binary, plus a cert to use the TCPA PKI. That will cost you money (if not at first, then eventually). I think it would be a breach of the GPL to stop people redistributing the signature: You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License. The application or OS vendor can in confidence distribute not just the code, but also the also the signature and cert. In fact, the application vendor can distribute absolutely everything they have access to themselves and you still won't be able to run the application in trusted mode. The cert that enables an application to run in trusted mode is tied to a specific TPM and therefore to a specific motherboard. For this cert to work on another motherboard without a new and different cert, the software vendor would need to extract the 2048-bit secret RSA key [1] from their own motherboard's TPM, make the secret key available for download, followed by the customer importing the key into their own TPM. The TPM, for obvious reasons, offers no facilities to export or import the TPM's internal keys. The GPL cannot possibly require a software author to distribute a hardware crack with their software or be in violation of the GPL. Distributing a crack for TPM's is distributing an infringement device and as such is illegal under US law. Even if the GPL were to be modified to mandate what is technically near impossible to a software vendor to achieve, even this layperson knows that contracts that require illegal acts are unenforceable. Note that I am not referring to acts that might be illegal in the future under the Hollings bill. Doing the above is illegal today. The GPL might be modified to require that the application vendor do whatever is necessary for a user to utilize an application in the way the user deems fit (i.e. in privileged mode), but that would put the GPL into very dangerous, and I believe thoroughly undesirable, territory. With such modifications, the hypothetical new GPL would mandate, to use Richard Stallman's terminology, not just freedom of speech, but free beer as well. That has never been the intend of the GPL. Furthermore, the certs required to run the OS or application will in may cases be issued by a party other than the application author or vendor. To continue using Richard's terminology, to cover this case the GPL would need to be rewritten to mandate that a third-party provide the free beer. I will leave it to the attorneys on this list to elucidate on the legal deficiencies of such a hypothetical contract, since I am not an attorney I will simply state that I sincerely doubt such contract would hold up in litigation. Of course I do not believe the FSF would make such changes. Which gets us back to Ross's point that the TCPA threatens the core of the GPL, from which this discussion started. For completeness I would like to state that I have no personal stake in the continued enforceability of the GPL, being a long-time supporter of the BSD licensing scheme myself. [1] 1024-bit RSA keys were rejected during the design phase of the TPM by members of the TCPA, which, as Anonymous pointed out in a previous post, contains several well-known crypto companies. The TCPA's website, which only makes specs, but not design documents, available to the public, unfortunately does not provide any documentation which reasoning lead to this decision. --Lucky Green
RE: Steven Levy buys Microsoft's bullshit hook, line, and sinker
Bram wrote: http://www.msnbc.com/news/770511.asp?cp1=1 Of course, the TCPA has nothing to do with security or privacy, since those are OS-level things. All it can really do is ensure you're running a particular OS. It's amazing the TCPA isn't raising all kinds of red flags at the justice department already - it's the most flagrant attempt to stifle competition I've ever seen. [Bram is correct, stifling competition is one of the many features TCPA will enable. In more ways than one. And for more players than just Microsoft]. Coincidentally, Steven Levy's article that Bram is citing also helps answer Mr. Anonymous's question with which he challenged Ross and myself earlier today. First, however, I must apologize to the reader for my earlier, now incorrect, statement that TCPA member companies would deny that DRM is an objective of the TCPA. I had been unaware that, as evidenced by the publication of the Newsweek article, the public phase of the TCPA effort had already begun. What a bizarre coincidence for this phase, after all those years the TCPA effort and its predecessors have been underway, (the design, and in fact the entire architecture, has morphed substantially over the years) to be kicked off the very day of my post. [Tim: do you recall when we had the discussion about the upcoming encrypted op code chips at a Cypherpunks meeting in a Stanford lecture hall? Was that 1995 or 1996? It cannot have been later; I know that I was still working for DigiCash at the time because I remember giving a talk on compact endorsement signatures at the same meeting]. From Levy's article: Palladium [Microsoft's TCPA-based technology - LG] is being offered to the studios and record labels as a way to distribute music and film with digital rights management (DRM). This could allow users to exercise fair use (like making personal copies of a CD) and publishers could at least start releasing works that cut a compromise between free and locked-down. But a more interesting possibility is that Palladium could help introduce DRM to business and just plain people. It's a funny thing, says Bill Gates. We came at this thinking about music, but then we realized that e-mail and documents were far more interesting domains.' Another paragraph of the Newsweek article has this to say: In 1997, Peter Biddle, a Microsoft manager who used to run a paintball arena, was the company's liason to the DVD-drive world. Naturally, he began to think of ways to address Hollywood's fear of digital copying. He hooked up with [...] researchers Paul England and John Manferdelli, and they set up a skunkworks operation, stealing time from their regular jobs to pursue a preposterously ambitious idea-creating virtual vaults in Windows to protect information. They quickly understood that the problems of intellectual property were linked to problems of security and privacy. They also realized that if they wanted to foil hackers and intruders, at least part of the system had to be embedded in silicon, not software. Well, now that Bill Gates himself is being quoted stating that DRM was a driver behind the technology the TCPA is enabling (Microsoft is one of the companies that founded the TCPA and should be in a position to know), does Mr. Anonymous consider this sufficient evidence that the TCPA is being designed for the support of digital rights management (DRM) applications? Or does Anonymous continue to believe Ross and Lucky are making this stuff up out of whole cloth? To answer Anonymous's question as to whether the the TCPA [is] really, as [Ross and Lucky] claim, a secretive effort to get DRM hardware into consumer PCs?, I am not sure I would exactly call this fact a secret at this point. (Though by no means are all cards already on the table). DRM is a significant objective of some of the TCPA's member companies, which includes Microsoft. There are of course other objectives. Some of which Ross published, some which I mentioned, some which Steven Levy has published (though he largely fell for the designated bait and missed the numerous hooks), some which Bram has realized, and some which have yet to be talked about. Some desirable, some questionable, and a lot of them downright scary. Sincerely, --Lucky Green
RE: Ross's TCPA paper
Anonymous writes: Lucky Green writes regarding Ross Anderson's paper at: Ross and Lucky should justify their claims to the community in general and to the members of the TCPA in particular. If you're going to make accusations, you are obliged to offer evidence. Is the TCPA really, as they claim, a secretive effort to get DRM hardware into consumer PCs? Or is it, as the documents on the web site claim, a general effort to improve the security in systems and to provide new capabilities for improving the trustworthiness of computing platforms? Anonymous raises a valid question. To hand Anonymous additional rope, I will even assure the reader that when questioned directly, the members of the TCPA will insist that their efforts in the context of TCPA are concerned with increasing platform security in general and are not targeted at providing a DRM solution. Unfortunately, and I apologize for having to disappoint the reader, I do not feel at liberty to provide the proof Anonymous is requesting myself, though perhaps Ross might. (I have no first-hand knowledge of what Ross may or may not be able to provide). I however encourage readers familiar with the state of the art in PC platform security to read the TCPA specifications, read the TCPA's membership list, read the Hollings bill, and then ask themselves if they are aware of, or can locate somebody who is aware of, any other technical solution that enjoys a similar level of PC platform industry support, is anywhere as near to wide-spread production as TPM's, and is of sufficient integration into the platform to be able to form the platform basis for meeting the requirements of the Hollings bill. Would Anonymous perhaps like to take this question? --Lucky Green
RE: CP meet at H2K2?
David wrote: On Thu, 20 Jun 2002, Greg Newby wrote: the next couple of days. I'm thinking of a CP meet Saturday night July 12. Anyone else gonna be there? I should be there, since I'm free and in the area. In a similar vein, who's going to be at DEF CON? I won't be at H2K2, but I will be at DEFCON. My girlfriend has the last day of her California Bar exam the day before the conference; parties are anticipated. :-) My room is at the St. Tropez, easily identifiable by the Gladsen flag flying from a second story balcony overlooking the pool. --Lucky
RE: Ross's TCPA paper
Mike wrote quoting Lucky: trusted here means that the members of the TCPA trust that the TPM will make it near impossible for the owner of that motherboard to access supervisor mode on the CPU without their knowledge, they trust that the TPM will enable them to determine remotely if the customer has a kernel-level debugger loaded, and they trust that the TPM will prevent a user from bypassing OS protections by installing custom PCI cards to read out memory directly via DMA without going through the CPU. I don't see how they expect this to work. We've already got cheap rip off motherboards, who's gonna stop cheap rip off TPM's that ain't really T? I think it moves the game into a smaller field where the players all have some bucks to begin with, but somebody will create a TPM that looks like the real thing, but runs cypherpunk code just fine. I agree with your assertion that TPM's can't prevent DRM from being broken. Nor is this the intent of introducing TPM's. The vendors have realized that they have to raise the technical bar only so high to keep those most inclined to break their systems (i.e. 16-year old Norwegians) from doing so. Those that have the knowledge and resources to break TCPA systems either won't have the time because they are engaged in gainful employment, won't be willing to take the risk, because they have accumulated sufficient material possessions to be unwilling to risk losing their possessions, not to mention their freedom, in litigation, or will break the security for their own gain, but won't release the crack to the public. Criminal enterprise falls into the latter category. The content vendors, which in this case includes the operating system and application vendors, dislike, but can live with, major criminal enterprise being the only other party to have unfettered access, since criminal enterprise is just another competitor in the market place. Most business models can survive another competitor. Where business models threaten to collapse is when the marginal cost of an illegal copy goes to zero and the public at large can obtain your goods without payment. I don't know if the TCPA's efforts will prevent this, but in the process of trying to achieve this objective, the average computers users, and even many advanced computer users, will find themselves in a new relationship with their PC: that of a pure consumer, with only the choices available to them the what the 180 TCPA's members digital signatures permit. Cloning TPM's is difficult, though not impossible. Note that all TPM's unique initial internal device keys are signed at time of manufacture by a derivative of the TCPA master key. Unless you are one of the well-known chipset or BIOS manufacturers, you can't get your TPM products signed. It is theoretically possible, though far from easy, to clone an entire TPM, keys and all. However, the moment those fake TPM's show up in the market place, their keys will simply be listed in the next CRL update. And if your OS and TPM's miss a few CRL updates, your commercial OS and all your applications will stop working. As might in the future your video card, your PCI cards, your hard drive, and your peripherals. You can try to hack around the code in the OS or firmware that performs the checks, as long as you are willing to operate your machine permanently off the Net from then on, because your system will fail the remote integrity checks, but given that this and other security relevant code inside the OS and applications are 3DES encrypted and are only decrypted inside the TPM, you can't just read the object code from disk, but get to first microprobe the decrypted op codes off the bus before taking a debugger to the code. Not a trivial task at today's PC bus speeds. Nor can you get too aggressive with the hacks, since your Fritz may simply flush the keys and leave you with a bunch of 3DES encrypted op codes and no corresponding decryption keys. Reverse engineering turns pretty dim at that point. None of these obstacles are impossible to overcome, but not by Joe Computer User, not by even the most talented 16-year old hacker, and not even by many folks in the field. Sure, I know some that could overcome it, but they may not be willing to do the time for what by then will be a crime. Come to think of it, doing so already is a crime. --Lucky Green
RE: Ross's TCPA paper
Anonymous writes: Lucky Green writes regarding Ross Anderson's paper at: Ross and Lucky should justify their claims to the community in general and to the members of the TCPA in particular. If you're going to make accusations, you are obliged to offer evidence. Is the TCPA really, as they claim, a secretive effort to get DRM hardware into consumer PCs? Or is it, as the documents on the web site claim, a general effort to improve the security in systems and to provide new capabilities for improving the trustworthiness of computing platforms? Anonymous raises a valid question. To hand Anonymous additional rope, I will even assure the reader that when questioned directly, the members of the TCPA will insist that their efforts in the context of TCPA are concerned with increasing platform security in general and are not targeted at providing a DRM solution. Unfortunately, and I apologize for having to disappoint the reader, I do not feel at liberty to provide the proof Anonymous is requesting myself, though perhaps Ross might. (I have no first-hand knowledge of what Ross may or may not be able to provide). I however encourage readers familiar with the state of the art in PC platform security to read the TCPA specifications, read the TCPA's membership list, read the Hollings bill, and then ask themselves if they are aware of, or can locate somebody who is aware of, any other technical solution that enjoys a similar level of PC platform industry support, is anywhere as near to wide-spread production as TPM's, and is of sufficient integration into the platform to be able to form the platform basis for meeting the requirements of the Hollings bill. Would Anonymous perhaps like to take this question? --Lucky Green
Ross's TCPA paper
I recently had a chance to read Ross Anderson's paper on the activities of the TCPA at http://www.cl.cam.ac.uk/ftp/users/rja14/.temp/toulouse.pdf I must confess that after reading the paper I am quite relieved to finally have solid confirmation that at least one other person has realized (outside the authors and proponents of the bill) that the Hollings bill, while failing to mention TCPA anywhere in the text of the bill, was written with the specific technology provided by the TCPA in mind for the purpose of mandating the inclusion of this technology in all future general-purpose computing platforms, now that the technology has been tested, is ready to ship, and the BIOS vendors are on side. Perhaps the Hollings Consumer Broadband and Digital Television Promotion Act bill would be more accurately termed the TCPA Enablement Act. BTW, the module that Ross calls a Fritz in his paper after the author of the bill, long had a name: it is called a Trusted Platform Module (TPM). Granted, in the context of the TCPA and the Hollings bill, the term trusted is used somewhat differently than the customers of future motherboards, which are all slated to include a TPM, might expect: trusted here means that the members of the TCPA trust that the TPM will make it near impossible for the owner of that motherboard to access supervisor mode on the CPU without their knowledge, they trust that the TPM will enable them to determine remotely if the customer has a kernel-level debugger loaded, and they trust that the TPM will prevent a user from bypassing OS protections by installing custom PCI cards to read out memory directly via DMA without going through the CPU. The public and the media now need to somehow, preferably soon, arrive at the next stage of realization: the involvement in the TCPA by many companies who's CEO's wrote the widely distributed open letter to the movie studios, telling the studios, or more precisely -- given that it was an open letter -- telling the public, that mandating DRM's in general-purpose computing platforms may not be a good idea, is indicative of one of two possible scenarios: 1) the CEO's of said computer companies are utterly unaware of a major strategic initiative their staff has been diligently executing for about 3 years, in the case of the principals in the TCPA, such as Intel, Compaq, HP, and Microsoft, several years longer. 2) the CEO's wrote this open letter as part of a deliberate good cop, bad cop ploy, feigning opposition to DRM in general computing platforms to pull the wool over the public's eye for hopefully long enough to achieve widespread deployment of the mother of all DRM solution in the market place. I do not know which of the two potential scenarios holds true. However, I believe public debate regarding the massive change in the way users will interact with their future computers due to the efforts of the TCPA and the Hollings bill would be greatly aided by attempts to establish which of the two scenarios is the fact the case. --Lucky Green
Ross's TCPA paper
I recently had a chance to read Ross Anderson's paper on the activities of the TCPA at http://www.cl.cam.ac.uk/ftp/users/rja14/.temp/toulouse.pdf I must confess that after reading the paper I am quite relieved to finally have solid confirmation that at least one other person has realized (outside the authors and proponents of the bill) that the Hollings bill, while failing to mention TCPA anywhere in the text of the bill, was written with the specific technology provided by the TCPA in mind for the purpose of mandating the inclusion of this technology in all future general-purpose computing platforms, now that the technology has been tested, is ready to ship, and the BIOS vendors are on side. Perhaps the Hollings Consumer Broadband and Digital Television Promotion Act bill would be more accurately termed the TCPA Enablement Act. BTW, the module that Ross calls a Fritz in his paper after the author of the bill, long had a name: it is called a Trusted Platform Module (TPM). Granted, in the context of the TCPA and the Hollings bill, the term trusted is used somewhat differently than the customers of future motherboards, which are all slated to include a TPM, might expect: trusted here means that the members of the TCPA trust that the TPM will make it near impossible for the owner of that motherboard to access supervisor mode on the CPU without their knowledge, they trust that the TPM will enable them to determine remotely if the customer has a kernel-level debugger loaded, and they trust that the TPM will prevent a user from bypassing OS protections by installing custom PCI cards to read out memory directly via DMA without going through the CPU. The public and the media now need to somehow, preferably soon, arrive at the next stage of realization: the involvement in the TCPA by many companies who's CEO's wrote the widely distributed open letter to the movie studios, telling the studios, or more precisely -- given that it was an open letter -- telling the public, that mandating DRM's in general-purpose computing platforms may not be a good idea, is indicative of one of two possible scenarios: 1) the CEO's of said computer companies are utterly unaware of a major strategic initiative their staff has been diligently executing for about 3 years, in the case of the principals in the TCPA, such as Intel, Compaq, HP, and Microsoft, several years longer. 2) the CEO's wrote this open letter as part of a deliberate good cop, bad cop ploy, feigning opposition to DRM in general computing platforms to pull the wool over the public's eye for hopefully long enough to achieve widespread deployment of the mother of all DRM solution in the market place. I do not know which of the two potential scenarios holds true. However, I believe public debate regarding the massive change in the way users will interact with their future computers due to the efforts of the TCPA and the Hollings bill would be greatly aided by attempts to establish which of the two scenarios is the fact the case. --Lucky Green
RE: Sci Journals, authors, internet
Peter wrote: (Hmm, I wonder if it can be argued that making stuff intended for public distribution inaccessible violates the creator's moral rights? I know that doesn't apply in the US, but in other countries it might work. Moral rights can't be assigned, so no publisher can take that away from you. Peter has an interesting point, since in addition to common law applies to a trend in copyright that is prevalent in Europe (and presumably some other countries), but rather alien to the US, taking that trend further. For those readers not familiar with this trend, there is the gist of it: Everybody on this list knows that what buyers of bit strings may or not do with such bit strings, under pain of incarceration and, should you resist that effectively, death, is under global attack by the MPAA and its cohorts. What US observers are frequently less aware of is that the same right is as much under attack, albeit for very different reasons, by the European cultural elite which has been as effective as the MPAA in working on their shared goal of dismantling what in the US would be called the doctrine of first sale. In brief, this doctrine states that if you buy a book, painting, or DVD, you may read or watch it for as many times as you please (including not at all), loan it to your friends, donate it to a library, sell it to somebody else, or chuck it out with the trash. The MPAA desires to dismantle the doctrine of first sale for the easily understandable reason that the MPAA's members would like to approximate as closely as possible to a state in which each person watching a movie has to pay the studios each time the DVD is watched. If the technology existed at a cost acceptable for a consumer device to count the number of people present in a room watching a particular DVD, the MPAA likely would lobby Congress to mandate that technology's inclusion to permit for the collection of per-watcher/watching licensing fees. The other half of the shears cutting away at the public's right to entertain themselves with the artwork they purchased in any way they please is represented by parts of the art culture of significant political clout, in particular in Europe. Bills are pending or have already passed, that make it illegal for a buyer of a work of art to simply dispose of the work, or use it as kindling in his fireplace, once he no longer desires to own it. No, you can't just burn that painting you bought from some street corner painter five years ago. Though you are permitted to give the painting back to the artist. Without compensation, of course. Between the corporate objective of charging the readers of a book each time they read it and the elitist objective of forcing the buyer to read a book they bought at least on occasion, with both groups united in their zeal to impose their respective view points onto the public by force of law and the men with sub-machine guns the law employs, the future of copyright proves to be interesting. But you already knew that part. While the European art circles clamoring for such moral right protection acts would undoubtedly denounce the assertion that they are working hand in glove with the MPAA's objective of dismantling the doctrine of first sale to the detriment of society, the two groups in fact are natural allies or pawns, depending on their level of awareness of the situation. Undoubtedly this has not been overlooked by the MPAA, though I suspect the European artists are blissfully unaware of how they have helped and continue to help to grease the MPAA's skids. --Lucky
