August 2002 - cypherpunks-legacy

Re: Thanks, Lucky, for helping to kill gnutella
by Paul Crowley 11 Aug '02

11 Aug '02

AARG!Anonymous <remailer(a)aarg.net> writes: > Be sure and send a note to the Gnutella people reminding them of all > you're doing for them, okay, Lucky? Do the Gnutella people share your feelings on this matter? I'd be surprised. -- __ Paul Crowley \/ o\ sig(a)paul.ciphergoth.org /\__/ http://www.ciphergoth.org/

1 0

Re: Thanks, Lucky, for helping to kill gnutella (fwd)
by R. A. Hettinga 11 Aug '02

11 Aug '02

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 At 4:12 AM +0000 on 8/11/02, David Wagner wrote: > I hope I don't need to point out that always using the same exit > remailer does *not* prove that he is using just one hop. One can > hold the exit remailer fixed while varying other hops in the path. > Your question seems to be based on a mistaken assumption about how > remailers work. Sorry to give that impression, and, as much as I respect you, and James Donald, who also makes the same assertion about me, both of you would be wrong in assuming that I don't know how remailers work, at least in principle. While I haven't ever built a remailer, I *have* used them on occasion, and I did edit Sameer Parekh's excellent introduction to anonymous remailers for one of the first issues of First Monday, when I was on the editorial board there in the middle 1990's. That said, I would be willing to bet a (very :-)) nominal amount that the esteemed Mr. AAARG! is, or was, in fact, using one hop, at most, though to prove the bet out would be difficult thing to do. In fact, to add further insult to his street cred, or at least kick some dust on his patent-leather penny-loafers, I wouldn't be surprised if the remailer is his own, though that would probably be too stupid even for him to do, and I'm not going to waste my time rooting out, even at a first pass, who runs the AAARG! remailer. I just say I wouldn't be surprised, is all. :-). At the foundation, then, my point is still the same one that I started with: the same, well, idiots, tend use the same outbound remailer hops, usually to the exclusion of all other remailer nodes, and, oddly enough, to the exclusion of all other users of that particular remailer. It becomes quite easy then to filter them out, which is, frankly, nice, at least as far as I'm concerned. Besides Mr. AAARG!, another user of a certain Austrian remailer node comes to mind. Both of those gentlemen, if I were to only charitably call them such, do not vary their output remailers, much less do other potentially clueful things, like actually sign their messages, for instance. Obviously all this might have to do with finding enough working remailers to string together, and, of course, the lack of genuinely any easy to use mixmaster clients out there, even now, and not for actually trying, using a whole bunch of money in a couple of cases. I suppose, given the use of lots of remailers as a platform to heckle ostensibly reasonable discussion from the back benches, if not to actually stalk online and send poison-pen email, it's easy to find their difficulty of use a blessing; though like most people who care about such things, it doesn't help the cause of ubiquitous internet privacy too much. Maybe we need cash, or something. Someday. :-). Ultimately, I think it boils down to genuine gall. If someone like Mr. AAARG! would actually endeavor to instruct the residents of the cryptography list, or even cypherpunks :-), of the utility of shoving a particularly egregious bit of technological emetic down our collective throats, or even the throat of the general public, one would think he would have a better clue about remailer hygiene when he treated us to his current round of venturi-vaporised drivel. So, Mr. AARG! is, probably, just some advanced-degree moke who works at Intel, or is a Waveoid, or other such Wintel digital "rights" "management" IP-control fellow traveller, and, given the paucity of his nocturnal emissions from behind the Great Oz's Green Velvet Curtain, or, better, the elementary answers people here are forced to use to explain more rudimentary things than remailer operations to him, probably helps me, just a smidge, with my assertion about his probable clueless use of the remailer network. Cheers, RAH -----BEGIN PGP SIGNATURE----- Version: PGP 7.5 iQA/AwUBPVX8J8PxH8jf3ohaEQJ0MgCgv3PLVPALWxBzYhkTfINn8jC3WkoAoJ+g nkXbBBPv5oaQVL4qTSP+T0Fu =zqRj -----END PGP SIGNATURE----- -- ----------------- R. A. Hettinga <mailto: rah(a)ibuc.com> The Internet Bearer Underwriting Corporation <http://www.ibuc.com/> 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

1 0

Challenge to TCPA/Palladium detractors
by AARG! Anonymous 11 Aug '02

11 Aug '02

I'd like the Palladium/TCPA critics to offer an alternative proposal for achieving the following technical goal: Allow computers separated on the internet to cooperate and share data and computations such that no one can get access to the data outside the limitations and rules imposed by the applications. In other words, allow a distributed network application to create a "closed world" where it has control over the data and no one can get the application to "cheat". IMO this is clearly the real goal of TCPA and Palladium, in technical terms, when stripped of all the emotional rhetoric. As I posted previously, this concept works especially well for open source applications. You could even have each participant compile the program himself, but still each app can recognize the others on the network and cooperate with them. And this way all the participants can know that the applications aren't doing anything different than what they claim. This would be a very powerful capability with many uses that you might find both good and bad. I posted a long message earlier with three examples of privacy-oriented applications: secure game playing, anonymous P2P networking, and untraceable digital cash. In addition it can be used for DRM, restricting access to sensitive business or government data, and similar applications. For those of you who claim that such a technology is not necessarily objectionable in itself, but that the implementations in TCPA and Palladium are flawed, please explain how you could do it better. How can you maximize user control and privacy and minimize the potential for government or corporate takeovers? In other words, what *exactly* is wrong with the way that TCPA and Palladium choose to do things? Can you fix those problems and still achieve the basic goal, above?

10 10

Re: Challenge to TCPA/Palladium detractors
by lynn.wheeler＠firstdata.com 11 Aug '02

11 Aug '02

oops, finger slip that should be http://www.garlic.com/~lynn/2001h.html#61 security proportional to risk aka 2001h.html not 2002h.html .... lynn.wheeler(a)firstdata.com on 8/10/2002 11:25 pm wrote: small discussion of security proportional to risk: http://www.garlic.com/~lynn/2002h.html#61 security proportional to risk

1 0

(no subject)
by darren＠tao.ca 11 Aug '02

11 Aug '02

unsubscribe

1 0

None
by darren＠tao.ca 11 Aug '02

11 Aug '02

unsubscribe

1 0

Re: responding to claims about TCPA
by AARG! Anonymous 11 Aug '02

11 Aug '02

AARG! wrote: > I asked Eric Murray, who knows something about TCPA, what he thought > of some of the more ridiculous claims in Ross Anderson's FAQ (like the > SNRL), and he didn't respond. I believe it is because he is unwilling > to publicly take a position in opposition to such a famous and respected > figure. John Gilmore replied: > > Many of the people who "know something about TCPA" are constrained > by NDA's with Intel. Perhaps that is Eric's problem -- I don't know. Maybe, but he could reply just based on public information. Despite this he was unable or unwilling to challenge Ross Anderson. > One of the things I told them years ago was that they should draw > clean lines between things that are designed to protect YOU, the > computer owner, from third parties; versus things that are designed to > protect THIRD PARTIES from you, the computer owner. This is so > consumers can accept the first category and reject the second, which, > if well-informed, they will do. I don't agree with this distinction. If I use a smart card chip that has a private key on it that won't come off, is that protecting me from third parties, or vice versa? If I run a TCPA-enhanced Gnutella that keeps the RIAA from participating and easily finding out who is running supernodes (see http://slashdot.org/article.pl?sid=02/08/09/2347245 for the latest crackdown), I benefit, even though the system technically is protecting the data from me. I wrote earlier that if people were honest, trusted computing would not be necessary, because they would keep their promises. Trusted computing allows people to prove to remote users that they will behave honestly. How does that fit into your dichotomy? Society has evolved a myriad mechanisms to allow people to give strong evidence that they will keep their word; without them, trade and commerce would be impossible. By your logic, these protect third parties from you, and hence should be rejected. You would discard the economic foundation for our entire world. > TCPA began in that "protect third parties from the owner" category, > and is apparently still there today. You won't find that out by > reading Intel's modern public literature on TCPA, though; it doesn't > admit to being designed for, or even useful for, DRM. My guess is > that they took my suggestion as marketing advice rather than as a > design separation issue. "Pitch all your protect-third-party products > as if they are protect-the-owner products" was the opposite of what I > suggested, but it's the course they (and the rest of the DRM industry) > are on. E.g. see the July 2002 TCPA faq at: > > http://www.trustedcomputing.org/docs/TPM_QA_071802.pdf > > 3. Is the real "goal" of TCPA to design a TPM to act as a DRM or > Content Protection device? > No. The TCPA wants to increase the trust ... [blah blah blah] > > I believe that "No" is a direct lie. David Grawrock of Intel has an interesting slide presentation on TCPA at http://www.intel.com/design/security/tcpa/slides/index.htm. His slide 3 makes a good point: "All 5 members had very different ideas of what should and should not be added." It's possible that some of the differences in perspective and direction on TCPA are due to the several participants wanting to move in different ways. Some may have been strictly focused on DRM; others may have had a more expansive vision of how trust can benefit all kinds of distributed applications. So it's not clear that you can speak of the "real goal" of TCPA, when there are all these different groups with different ideas. > Intel has removed the first > public version 0.90 of the TCPA spec from their web site, but I have > copies, and many of the examples in the mention DRM, e.g.: > > http://www.trustedcomputing.org/docs/TCPA_first_WP.pdf (still there) > > This TCPA white paper says that the goal is "ubiquity". Another way to > say that is monopoly. Nonsense. The web is ubiquitous, but is not a monopoly. > The idea is to force any other choices out of > the market, except the ones that the movie & record companies want. > The first "scenario" (PDF page 7) states: "For example, before making > content available to a subscriber, it is likely that a service > provider will need to know that the remote platform is trustworthy." That same language is in the Credible Interoperability document presently on the web site at http://www.trustedcomputing.org/docs/Credible_Interoperability_020702.pdf. So I don't think there is necessarily any kind of a cover-up here. > http://www.trustedpc.org/home/pdf/spec0818.pdf (gone now) > > Even this 200-page TCPA-0.90 specification, which is carefully written > to be obfuscatory and misleading, leaks such gems as: "These features > encourage third parties to grant access to by the platform to > information that would otherwise be denied to the platform" (page 14). > "The 'protected store' feature...can hold and manipulate confidential > data, and will allow the release or use of that data only in the > presence of a particular combination of access rghts and software > environment. ... Applications that might benefit include ... delivery > of digital content (such as movies and songs)." (page 15). Yes, DRM can clearly benefit from TCPA/Palladium. And you might be right that they are downplaying that now. But the reason could be that people have focused too much on it as the only purpose for TCPA, just as you have done here. So they are trying to play up the other possibilities so as to get some balance in the discussion. > Of course, they can't help writing in the DRM mindset regardless of > their intent to confuse us. In that July 2002 FAQ again: > > 9. Does TCPA certify applications and OS's that utilize TPMs? > > No. The TCPA has no plans to create a "certifying authority" to > certify OS's or applications as "trusted". The trust model the TCPA > promotes for the PC is: 1) the owner runs whatever OS or > applications they want; 2) The TPM assures reliable reporting of the > state of the platform; and 3) the two parties engaged in the > transaction determine if the other platform is trusted for the > intended transaction. > > "The transaction"? What transaction? They were talking about the > owner getting reliable reporting on the security of their applications > and OS's and -- uh -- oh yeah, buying music or video over the Internet. You are reading an awful lot into this one word "transaction". That doesn't necessarily mean buying digital content. In the abstract sense "transaction" is sometimes used to refer to any exchange of information in a protocol. Even if we do stick to its commercial meaning, it can mean a B2B exchange or any of a wide range of other e-commerce activities. It's not specific to DRM by any means. > Part of their misleading technique has apparently been to present no > clear layman's explanations of the actual workings of the technology. > There's a huge gap between the appealing marketing sound bites -- or > FAQ lies -- and the deliberately dry and uneducational 400-page > technical specs. My own judgement is that this is probably > deliberate, since if the public had an accurate 20-page document that > explained how this stuff works and what it is good for, they would > reject the tech instantly. I agree that the documentation is a problem, but IMO it probably reflects lack of resources rather than obfuscation. I believe that TCPA has many more applications than you and other critics are giving it credit for, and that a good, clear explanation of what it could do would actually gain it support. Do a blog search at daypop.com to see what people are really thinking about TCPA. They read Ross Anderson's TCPA FAQ and take it for gospel. They believe TCPA has serial number revocations and all these other features that are not described in any documents I have seen. A good clear TCPA description could only improve its reputation, which certainly can't go any lower than it is. > Perhaps we in the community should write such a document. Lucky and > Adam Back seem to be working towards it. The similar document about > key-escrow (that CDT published after assembling a panel of experts > including me, Whit, and Matt Blaze) was quite useful in explaining to > lay people and Congressmen what was wrong with it. NSA/DoJ had > trouble countering it, since it was based on the published facts, and > they couldn't impugn the credentials of the authors, nor the > document's internal reasoning. I agree in principle, but I am appalled that you believe that Lucky in particular is heading in the right direction. Adam on the other hand has at least begun to study TCPA and was asking good questions about Palladium before Peter Biddle flew the coop. Will this document say that TCPA is designed to support intelligence agency access to computers? to kill free software? and other such claims from Lucky's presentation? If so, you will only hurt your cause. On the other hand, if you do come up with factual and unbiased information showing both good and bad aspects of TCPA, as I think Adam has come close to doing a few times, then it could be a helpful document. > Intel and Microsoft and anonymous chauvanists can and should criticize > such a document if we write one. That will strengthen it by > eliminating any faulty reasoning or errors of public facts. But they > had better bring forth new exculpating facts if they expect the > authors to change their conclusions. Conclusions should be based on technology. TCPA can be rightly criticized for weak protections of privacy, for ultimately depending on the security of a few central keys and of possibly-weak hardware, and on other technical grounds. But you should not criticize it for supporting DRM, or for making reverse engineering more difficult, because people are under no obligation to give their creative works away for free, or to make it easy for other people to copy their software. Leave your values at home and just present the facts. > They're free to allege that "No > current Microsoft products have Document Revocation Lists", but that > doesn't undermine the conclusion that their architectures make it easy > to secretly implement that feature, anytime they want to. No one has made any such allegation, although presumably it happens to be true. The point in contention is whether TCPA has DRLs! Lucky has claimed this, and Ross claimed the related serial number revocation list, SNRL. Both of them have linked this technology to TCPA/Palladium. Yet as Ross admitted in http://www.chiark.greenend.org.uk/pipermail/ukcrypto/2002-June/019463.html, SNRL's do not need TCPA! In fact, you are perfectly correct that Microsoft architectures would make it easy at any time to implement DRL's or SNRL's. They could do that tomorrow! They don't need TCPA. So why blame TCPA for this feature? TCPA is a technology. You can't take every bad thing Microsoft ever will do and say that TCPA is at fault. I don't even see that TCPA would particularly help with a SNRL, except insofar as TCPA can generally strengthen security in all respects. But remote attestation and sealing, the core TCPA technologies, don't have anything to do with SNRLs. The association of TCPA with SNRLs is a perfect example of the bias and sensationalism which has surrounded the critical appraisals of TCPA. I fully support John's call for a fair and accurate evaluation of this technology by security professionals. But IMO people like Ross Anderson and Lucky Green have disqualified themselves by virtue of their wild and inaccurate public claims. Anyone who says that TCPA has SNRLs is making a political statement, not a technical one. For a credible evaluation, you need people who have no track record of bias with regard to the technology.

2 1

Re: Thanks, Lucky, for helping to kill gnutella (fwd)
by R. A. Hettinga 11 Aug '02

11 Aug '02

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 At 9:15 AM +0200 on 8/10/02, Eugen Leitl wrote: > I don't try to filter, but to join several sources. Anonymous is an > idiot, but at least an intelligent one. I can't leave him out > without creating a skewed picture of what is going on. No offense meant, of course. To make sure I don't miss stuff like that is why I subscribe to your list anyway, even though I'm also subscribed to most of your sources. It is also why I was glad you caught something he said that confirmed, precisely, why he's still in my killfile. :-). I don't need to raise my blood pressure more than necessary. [Ob Cypherpunks: Seriously, folks. How clueful can someone be who clearly doesn't know how to use more than one remailer hop, as proven by the fact that he's always coming out of the *same* remailer all the time? Even more important, nobody *else* uses that remailer, which is why killfiling the idiot works so well to begin with...] Anyway, on this list in particular, I've found that what any number of smart people say about what the idiot du jour says is much more interesting than what the actual idiot says himself, which is why he can safely reside in a killfile. (Having said more than my share of stupid things here myself in 8 years here, and being no stranger to the odd killfile myself :-), I'm sure lots of peoples' irony meters are pegged, but, by definition, those folks can go fuck themselves, I figure. :-).) Cheers, RAH -----BEGIN PGP SIGNATURE----- Version: PGP 7.5 iQA/AwUBPVV2YsPxH8jf3ohaEQI0mQCeIvBppfM6c2HfCQAyjlLn3w0UCfkAoIA8 NObxG1Bk8BPLraIx3LrjnJbL =dg+p -----END PGP SIGNATURE----- -- ----------------- R. A. Hettinga <mailto: rah(a)ibuc.com> The Internet Bearer Underwriting Corporation <http://www.ibuc.com/> 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

2 1

This MAY be a spam e-mail, but if so it's a REALLY good one!
by John Madsen 11 Aug '02

11 Aug '02

My apologies for sending an unsolicited message, but if you like games, play on the stockmarket or you just wouldn't mind earning a few extra bucks, quid or whatever, I recommend you take a look at this website: <https://members.worldgamesinc.com/agrippa> World Games Inc is a fairly new thing to the net and is to date only really popular in Australia and here in Norway. It looks a bit like one of the tired, old pyramid games at first glance, but differs from those in that there is no sending money upwards through the levels, no buying stuff every week/month or you lose your place, or anything like that. Your only outlay is an initial $195 or equivalent and a further $8 or so every week after 4 weeks. I won't bother with a detailed explanation here, as the website sets out the system very well. There's also a PowerPoint presentation you can download and browse through at your leisure. The system will also feature various games like blackjack, poker and sports betting, which will be implemented in the future. This is no "get rich real quick" scheme, but rather a system which will reward those who are willing to put in a little bit of work now and then over time and, of course, the more effort, the greater the rewards. The bonus for all those who join now, is that the game is really only beginning to spread throughout the rest of the world (there are a very few players in Sweden, the UK, Denmark and the US so far) and getting in early is a definite advantage. My own personal experience so far is very limited, as I held off joining in order to see how my friends did (most of them joined right away) but now I've jumped on the bandwagon myself, since the most industrious of them earn around $200/week (after about 6 weeks). Like I said - no-one is claiming you'll be able to quit your job in six months and move to the Bahamas, but you're just about guaranteed to get your money back and more besides if you can find two people who'll join up below you. My reason for writing this is, of course, almost entirely self-serving. I need more members to join below me, in order that I earn more money. However, any money I earn WILL NOT come out of your money, so it's entirely in your interest too. Spend a few minutes of your time checking it out and you'll see what I mean - it may pay off very handsomely indeed. If you're interested or have any questions, just mail me and I'll get back to you as soon as possible. John M. Madsen (john.m.madsen(a)gmx.net)

1 0

Hy
by frio＠delphi.com 11 Aug '02

11 Aug '02

Obtain a prosperous future, money earning power, and the admiration of all. Diplomas from prestigious non-accredited universities based on your present knowledgeand life experience. No required tests, classes, books, or interviews. Bachelors, masters, MBA, and doctorate (PhD) diplomas available in the field of your choice.No one is turned down. Confidentiality assured. CALL NOW to receive your diploma within days!!! 713-866-8869 Call 24 hours a day, 7 days a week, including Sundays and holidays. ------------------------------------------------------------ WANT TO BE REMOVED? If you don't want to receive this newsletter, replay to this message with your email address in the subject line. STILL GETTING MAIL EVEN AFTER REQUESTING REMOVAL? Remember to include in the subject line the addresses your received this message. Any Vulgarity will be filtered and your request for removal will be deleted ####$$$$@@@@%%%%&&&&****@@@@$$$$####%%%%**** Thank you for listening, Bulkers Warehouse! *@&^#$%#%*@#&%@*%@&#%@^#%^@#&%@#%*@^%@#&*%*@

1 0