Re: Thanks, Lucky, for helping to kill gnutella

[Sunder]

Ok Mr. Smarty Pants Aarg! Anonymous remailer user, you come up with such a
method.  Cypherpunsk write code, yes?  So write some code.

Meanwhile, this is why it can't be done:

If you have a client that sends a signature of it's binary back to it's
mommy, you can also have a rogue client that sends the same signature back
to it's mommy, but is a different binary.

So how does mommy know which is the real client, and which is the rogue
client?

After all, the rogue could simply keep a copy of the real client's binary,
and send the checksum/hash for the real copy, but not run it.


If you embedd one half of a public key in the real client, what's to stop
the attacker from reverse engineering the real client and extracting the
key, then sign/encrypt things with that half of the key?  Or to patch the
client using a debugger so it does other things also?  Or runs inside an
emulator where every operation it does is logged - so that a new rogue can
be built that does the same?  Or runs under an OS whose kernel is patched
to allow another process to access your client's memory and
routines? Or has modded dynamic libraries which your client depends on 
to do the same, etc.


Show us the code instead of asking us to write it for you.  I say, you
can't do it.  Prove me wrong.  As long as you do not have full exclusive
control of the client hardware, you can't do what you ask with any degree
of confidence beyond what security through obscurity buys you.  In the
end, if someone cares enough, they will break it.


All this pointless bickering has already been discussed:  A long while
ago, Dennis Ritchie of K&R discussed how he introduced a backdoor into
login.c, then modified the C compiler to recognize when login.c was
compiled, and had it inject the back door, then removed the changes to
login.c.

How do you propose to have a client run in a hostile environment and
securely authenticate itself without allowing rogues to take over it's
function or mimic it?


Either propose a way to do what you're asking us to do - which IMHO is
impossible without also having some sort of cop out such as having trusted
hardware, or go away and shut the fuck up.

--Kaos-Keraunos-Kybernetos---
 + ^ + :NSA got $20Bill/year|Passwords are like underwear. You don't /|\
  \|/  :and didn't stop 9-11|share them, you don't hang them on your/\|/\
<--*-->:Instead of rewarding|monitor, or under your keyboard, you   \/|\/
  /|\  :their failures, we  |don't email them, or put them on a web  \|/
 + v + :should get refunds! |site, and you must change them very often.
[EMAIL PROTECTED] http://www.sunder.net 

On Fri, 9 Aug 2002, AARG! Anonymous wrote:

> If only there were a technology in which clients could verify and yes,
> even trust, each other remotely.  Some way in which a digital certificate
> on a program could actually be verified, perhaps by some kind of remote,
> trusted hardware device.  This way you could know that a remote system was
> actually running a well-behaved client before admitting it to the net.
> This would protect Gnutella from not only the kind of opportunistic
> misbehavior seen today, but the future floods, attacks and DOSing which
> will be launched in earnest once the content companies get serious about
> taking this network down.

Re: Thanks, Lucky, for helping to kill gnutella

[Seth Johnson]

TCPA and Palladium are content control for the masses.  They
are an attempt to encourage the public to confuse the public
interest issues of content control with the private interest
issues of privacy and security.

Seth Johnson

-- 

[CC] Counter-copyright:
http://cyber.law.harvard.edu/cc/cc.html

I reserve no rights restricting copying, modification or
distribution of this incidentally recorded communication. 
Original authorship should be attributed reasonably, but
only so far as such an expectation might hold for usual
practice in ordinary social discourse to which one holds no
claim of exclusive rights.

Re: Thanks, Lucky, for helping to kill gnutella

[Jim Choate]

There is a better way than the traditional 'client/server' approach
(distributed or not). It addresses each and every one of these issues and
its already written (by the people who invented Unix no less). And it's
Open Source (under it's own license). Even has crypto built in.

Plan 9.

http://plan9.bell-labs.com

And the only user/co-op group (not for long hopefully),

http://open-forge.org

On Sat, 10 Aug 2002, Jeroen C.van Gelderen wrote:

> 
> On Friday, Aug 9, 2002, at 13:05 US/Eastern, AARG!Anonymous wrote:
> > If only...  Luckily the cypherpunks are doing all they can to make sure
> > that no such technology ever exists.  They will protect us from being 
> > able
> > to extend trust across the network.  They will make sure that any open
> > network like Gnutella must forever face the challenge of rogue clients.
> > They will make sure that open source systems are especially vulnerable
> > to rogues, helping to drive these projects into closed source form.
> 
> This argument is a straw man but to be fair: I am looking forward to 
> your detailed proof that the only way to protect a Gnutella-like 
> network from rogue clients is a Palladium-like system. You are so 
> adamant that I have to assume you have such proof sitting right on your 
> desk. Please share it with us.
> 
> -J
> 
> 
> -
> The Cryptography Mailing List
> Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
> 


 --


  Conform and be dull..J. Frank Dobie

 [EMAIL PROTECTED] www.ssz.com
 [EMAIL PROTECTED]  www.open-forge.org

Re: Thanks, Lucky, for helping to kill gnutella

[Bram Cohen]

AARG!Anonymous wrote:

> I will just point out that it was not my idea, but rather that Salon
> said that the Gnutella developers were considering moving to authorized
> clients.  According to Eric, those developers are "fundamentally stupid."
> According to Bram, the Gnutella developers don't understand their
> own protocol, and they are supporting an idea which will not help.
> Apparently their belief that clients like Qtrax are hurting the system
> is totally wrong, and keeping such clients off the system won't help.

You can try running a sniffer on it yourself. Gnutella traffic is almost
all search queries. 

> As far as Freenet and MojoNation, we all know that the latter shut down,
> probably in part because the attempted traffic-control mechanisms made
> the whole network so unwieldy that it never worked. 

Mojo Nation actually had a completely excessive amount of bandwidth
donated to it. There was a problem that people complained of losing mojo
when running a server due to the total amount of upload being greater than
the total amount of download. The main user experience disaster in Mojo
Nation was that the retrieval rate for files was very bad, mostly due to
the high peer churn rate.

> At least in part this was also due to malicious clients, according to
> the analysis at http://www.cs.rice.edu/Conferences/IPTPS02/188.pdf.

Oh gee, that paper mostly talks about high churn rate too.

In fact, I was one of the main developers of Mojo Nation, and based on
lessons learned from that figured out how to build a system which can cope
with very high churn rates and has good leech resistance. It is now mature
and has had several quite successful deployments.

http://bitconjurer.org/BitTorrent/

Not only are the algorithms used good for leech resistance, they are also
very good at being robust under normal variances in net conditions - in
fact, the decentralized greedy approach to resource allocation outperforms
any known centralized method.

The TCPA, even if it some day works perfectly (which I seriously doubt it
will) would just plain not help with any of the immediate problems in
Gnutella, BitTorrent, or Mojo Nation. I would guess the same is true for
most, if not all other p2p systems.

-Bram Cohen

"Markets can remain irrational longer than you can remain solvent"
-- John Maynard Keynes

Re: Thanks, Lucky, for helping to kill gnutella (fwd)

[David Wagner]

R. A. Hettinga wrote:
>[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?

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.

Re: Thanks, Lucky, for helping to kill gnutella

[Sean Smith]

i guess it's appropriate that the world's deepest
hole is next to something labelled a "trust territory" :)

--Sean

:)

Re: Thanks, Lucky, for helping to kill gnutella

[R. A. Hettinga]

At 4:17 PM -0400 on 8/11/02, Sean Smith wrote:


> i guess it's appropriate that the world's deepest
> hole is next to something labelled a "trust territory" :)

Tears run down my face, I laughed so much. My cheeks hurt, I'm smiling so
hard...


Cheers,
RAH

-- 
-
R. A. Hettinga 
The Internet Bearer Underwriting Corporation 
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'

Re: Thanks, Lucky, for helping to kill gnutella (fwd)

[R. A. Hettinga]

-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 
The Internet Bearer Underwriting Corporation 
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'

Re: Thanks, Lucky, for helping to kill gnutella

[Sean Smith]

Actually, our group at Dartmouth has an NSF "Trusted Computing"
grant to do this, using the IBM 4758 (probably with a different
OS) as the hardware.   

We've been calling the project "Marianas", since it involves a chain of
islands.

--Sean

>If only there were a technology in which clients could verify and yes,
>even trust, each other remotely.  Some way in which a digital certificate
>on a program could actually be verified, perhaps by some kind of remote,
>trusted hardware device.  This way you could know that a remote system was
>actually running a well-behaved client before admitting it to the net.
>This would protect Gnutella from not only the kind of opportunistic
>misbehavior seen today, but the future floods, attacks and DOSing which
>will be launched in earnest once the content companies get serious about
>taking this network down.










-- 
Sean W. Smith, Ph.D. [EMAIL PROTECTED]   
http://www.cs.dartmouth.edu/~sws/   (has ssl link to pgp key)
Department of Computer Science, Dartmouth College, Hanover NH USA

Re: Thanks, Lucky, for helping to kill gnutella (fwd)

[R. A. Hettinga]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

At 4:12 AM + 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 
The Internet Bearer Underwriting Corporation 
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'

Re: Thanks, Lucky, for helping to kill gnutella

[R. A. Hettinga]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I'm genuinely sorry, but I couldn't resist this...

At 12:35 PM -0400 on 8/11/02, Sean Smith wrote:


> Actually, our group at Dartmouth has an NSF "Trusted Computing"
> grant to do this, using the IBM 4758 (probably with a different
> OS) as the hardware.
>
> We've been calling the project "Marianas", since it involves a
> chain of islands.

...and not the world's deepest hole, sitting right next door?

;-)

Cheers,
RAH



> --Sean
>
>>If only there were a technology in which clients could verify and
>>yes, even trust, each other remotely.  Some way in which a digital
>>certificate on a program could actually be verified, perhaps by
>>some kind of remote, trusted hardware device.  This way you could
>>know that a remote system was actually running a well-behaved
>>client before admitting it to the net. This would protect Gnutella
>>from not only the kind of opportunistic misbehavior seen today, but
>>the future floods, attacks and DOSing which will be launched in
>>earnest once the content companies get serious about taking this
>>network down.

-BEGIN PGP SIGNATURE-
Version: PGP 7.5

iQA/AwUBPVafIMPxH8jf3ohaEQIdeACgjD/TkZ2aCzYLwT3hM0nqyU9lZf0An1I4
UHx4YfvVVkNcVcr+5Ambi4Md
=huDN
-END PGP SIGNATURE-

-- 
-
R. A. Hettinga 
The Internet Bearer Underwriting Corporation 
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'

Re: Thanks, Lucky, for helping to kill gnutella

[Paul Crowley]

AARG!Anonymous <[EMAIL PROTECTED]> 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\ [EMAIL PROTECTED]
/\__/ http://www.ciphergoth.org/

Re: Thanks, Lucky, for helping to kill gnutella (fwd)

[James A. Donald]

--
On 10 Aug 2002 at 16:25, R. A. Hettinga wrote:
> [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?

The fact that he uses a constant exit remailer does not show that 
he is using a single hop.

I always come out of the same remailer at the end, even though I 
always use about three randomly selected remailers between myself 
and the constant exit remailer.  I always select the same end 
remailer to avoid confusing the audience, and I selected a less 
used exit remailer for the same reason. 

--digsig
 James A. Donald
 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
 c3w9s36+CG9NnfBCbV9lBPm1GKPtff16r/hBMRj2
 2ZIqRKb9UCTCvlWhGVeGUb1eknPEG0ynX12OrTTXM

Re: Thanks, Lucky, for helping to kill gnutella

[R. Hirschfeld]

> Date: Sat, 10 Aug 2002 16:42:52 +0200 (CEST)
> From: Eugen Leitl <[EMAIL PROTECTED]>
> 
> > Calling Lucky a liar is no more illuminating than others calling you
> > an idiot.
> 
> You're confusing a classification for an argument. The argument is over. 
> You can read it up in the archives. If you think there's still anything 
> left to discuss, I've got these plans of the Death Star I could sell 
> you...

I took a look at the archives as you suggested.  If it matters to you,
I wasn't referring to your classification of Anonymous as an idiot
(which I hadn't seen because it wasn't sent to the cryptography list),
but rather to an earlier comment ("Wow.  You must really be an
idiot.") from somebody else.  Looking back at that message, it appears
that it was sent to the cryptography list but not to cypherpunks.

Discussion about TCPA/Pd continues, and I hope that disagreements
needn't degenerate into name-calling.

Re: Thanks, Lucky, for helping to kill gnutella

[Pete Chown]

Anonymous wrote:

> As far as Freenet and MojoNation, we all know that the latter shut down,
> probably in part because the attempted traffic-control mechanisms made
> the whole network so unwieldy that it never worked.

Right, so let's solve this problem.  Palladium/TCPA solves the problem
in one sense, but in a very inconvenient way.  First of all, they stop
you running a client which has been modified in any way -- not just a
client which has been modified to be selfish.  Secondly, they facilitate
the other bad things which have been raised on this list.

> Right, as if my normal style has been so effective.  Not one person has
> given me the least support in my efforts to explain the truth about TCPA
> and Palladium.

The reason for that is that we all disagree with you.  I'm interested to
read your opinions, but I will argue against you.  I'm not interested in
reading flames at all.

-- 
Pete

Re: Thanks, Lucky, for helping to kill gnutella

[Eugen Leitl]

On Sat, 10 Aug 2002, R. Hirschfeld wrote:

> Calling Lucky a liar is no more illuminating than others calling you
> an idiot.

You're confusing a classification for an argument. The argument is over. 
You can read it up in the archives. If you think there's still anything 
left to discuss, I've got these plans of the Death Star I could sell 
you...

Re: Thanks, Lucky, for helping to kill gnutella

[Steve Schear]

At 08:25 PM 8/9/2002 -0700, AARG!Anonymous wrote:
>As far as Freenet and MojoNation, we all know that the latter shut down,
>probably in part because the attempted traffic-control mechanisms made
>the whole network so unwieldy that it never worked.

I worked there and respectfully disagree.  MN never gained a foothold first 
and foremost because of the frequent join/leave problem.

This, in turn, was a direct result of insufficient resources to address 
automated publication of .mp3 header data.  The inability of the client SW 
to automatically create the header data and publish directories full of 
.mp3 files at each client meant users had to expend more much effort to 
make available their content than file-oriented P2P alternatives.  This 
hurdle, when combined with data retention problems related to other MN 
deficiencies, assured that little content was available for DL.  New users 
simply abandoned the effort when they came up empty handed.

The introducer problem could probably have been solved using Usenet 
postings.  The nature of Usenet meant it could scale and was fairly 
resistant legal and technical attacks.  Usenet might also have served for a 
fallback block store but neither approach was ever carefully considered, 
again due to resource limitations.

>At least in part
>this was also due to malicious clients, according to the analysis at
>http://www.cs.rice.edu/Conferences/IPTPS02/188.pdf.

My experience is that the malicious client problem was not a major issue.

[much deleted]

>Lucky can provide all this misinformation, all under the pretence,
>mind you, that this *is* TCPA.  He was educating the audience, mostly
>people who were completely unfamiliar with the system other than some
>vague rumors.  And this is what he presents, a tissue of lies and
>fabrications and unfounded sensationalism.

At Lucky's Defcon talk he stated that he was a participant in the 
development of TCPA.  Can't clearly recall in what capacity he served but 
me recollection is it was as a reviewer.

steve

Re: Thanks, Lucky, for helping to kill gnutella

[R. Hirschfeld]

> Date: Fri, 9 Aug 2002 20:25:40 -0700
> From: AARG!Anonymous <[EMAIL PROTECTED]>

> Right, as if my normal style has been so effective.  Not one person has
> given me the least support in my efforts to explain the truth about TCPA
> and Palladium.

Hal, I think you were right on when you wrote:

  But feel free to make
  whatever assumptions you like about my motives.  All I ask is that you
  respond to my facts.

I, for one, support your efforts, even though I don't agree with some
of your conclusions.  It is clear that you hold a firm opinion that
differs from what many others here believe, so in making your points
you can expect objections to be raised.  You will be more convincing
(at least to me) if you continue to respond to these dispassionately
on the basis of facts and reasoned opinions (your "normal style"?).
Calling Lucky a liar is no more illuminating than others calling you
an idiot.

Re: Thanks, Lucky, for helping to kill gnutella (fwd)

[Eugen Leitl]

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.

On Fri, 9 Aug 2002, R. A. Hettinga wrote:

> At 1:03 AM +0200 on 8/10/02, Some anonymous, and now apparently
> innumerate, idiot in my killfile got himself forwarded to Mr. Leitl's
> cream of cypherpunks list:

p2p DoS resistance and network stability (Re: Thanks, Lucky, for helping to kill gnutella)

[Adam Back]

On Fri, Aug 09, 2002 at 08:25:40PM -0700, AARG!Anonymous wrote:
> Several people have objected to my point about the anti-TCPA efforts of
> Lucky and others causing harm to P2P applications like Gnutella.

The point that a number of people made is that what is said in the
article is not workable: clearly you can't ultimately exclude chosen
clients on open computers due to reverse-engineering.

(With TCPA/Palladium remote attestation you probably could so exclude
competing clients, but this wasn't what was being talked about).

The client exclusion plan is also particularly unworkable for gnutella
because some of the clients are open-source, and the protocol is (now
since original reverse engineering from nullsoft client) also open.

With closed-source implementations there is some obfuscation barrier
that can be made: Kazaa/Morpheus did succeed in frustrating competing
clients due to it's closed protocols and unpublished encryption
algorithm.  At one point an open source group reverse-engineered the
encryption algorithm, and from there the contained kazaa protocols,
and built an interoperable open-source client giFT
http://gift.sourceforge.net, but then FastTrack promptly changed the
unpublished encryption algorithm to another one and then used remote
code upgrade ability to "upgrade" all of the clients.

Now the open-source group could counter-strike if they had
particularly felt motivated to.  For example they could (1)
reverse-engineer the new unpublished encryption algorithm, and (2) the
remote code upgrade, and then (3) do their own forced upgrade to an
open encryption algorithm and (4) disable further forced upgrades.

(giFT instead after the "ugrade" attack from FastTrack decided to
implement their own open protocol "openFT" instead and compete.  It
also includes a general bridge between different file-sharing
networks, in a somewhat gaim like way, if you are familiar with
gaim.)

> [Freenet and Mojo melt-downs/failures...] Both of these are object
> lessons in the difficulties of successful P2P networking in the face
> of arbitrary client attacks.

I grant you that making simultaneously DoS resistant, scalable and
anonymous peer-to-peer networks is a Hard Problem.  Even removing the
anonymous part it's still a Hard Problem.

Note both Freenet and Mojo try to tackle the harder of those two
problems and have aspects of publisher and reader anonymity, so that
they are doing less well than Kazaa, gnutella and others is partly
because they are more ambitious and tackling a harder problem.  Also
the anonymity aspect possibly makes abuse more likely -- ie the
attacker is provided as part of the system tools to obscure his own
identity in attacking the system.  DoSers of Kazaa or gnutella would
likely be more easily identified which is some deterrence.

I also agree that the TCPA/Palladium attested closed world computing
model could likely more simply address some of these problems.

(Lucky slide critique in another post).

Adam
--
http://www.cypherspace.org/adam/

Re: Thanks, Lucky, for helping to kill gnutella

[AARG! Anonymous]

Several people have objected to my point about the anti-TCPA efforts of
Lucky and others causing harm to P2P applications like Gnutella.

Eric Murray wrote:
> Depending on the clients to "do the right thing" is fundamentally
> stupid.

Bran Cohen agrees:
> Before claiming that the TCPA, which is from a deployment standpoint
> vaporware, could help with gnutella's scaling problems, you should
> probably learn something about what gnutella's problems are first. The
> truth is that gnutella's problems are mostly that it's a screamer
> protocol, and limiting which clients could connect would do nothing to fix
> that.

I will just point out that it was not my idea, but rather that Salon
said that the Gnutella developers were considering moving to authorized
clients.  According to Eric, those developers are "fundamentally stupid."
According to Bram, the Gnutella developers don't understand their
own protocol, and they are supporting an idea which will not help.
Apparently their belief that clients like Qtrax are hurting the system
is totally wrong, and keeping such clients off the system won't help.

I can't help believing the Gnutella developers know more about their
own system than Bram and Eric do.  If they disagree, their argument is
not with me, but with the Gnutella people.  Please take it there.

Ant chimes in:
> My copy of "Peer to Peer" (Oram, O'Reilly) is out on loan but I think Freenet
> and Mojo use protocols that require new users to be contributors before they
> become consumers.

Pete Chown echoes:
> If you build a protocol which allows selfish behaviour, you have done
> your job badly.  Preventing selfish behaviour in distributed systems is
> not easy, but that is the problem we need to solve.  It would be a good
> discussion for this list.

As far as Freenet and MojoNation, we all know that the latter shut down,
probably in part because the attempted traffic-control mechanisms made
the whole network so unwieldy that it never worked.  At least in part
this was also due to malicious clients, according to the analysis at
http://www.cs.rice.edu/Conferences/IPTPS02/188.pdf.  And Freenet has been
rendered inoperative in recent months by floods.  No one knows whether
they are fundamental protocol failings, or the result of selfish client
strategies, or calculated attacks by the RIAA and company.  Both of these
are object lessons in the difficulties of successful P2P networking in
the face of arbitrary client attacks.

Some people took issue with the personal nature of my criticism:

> Your personal vendetta against Lucky is very childish.

> This sort of attack doesn't do your position any good.

Right, as if my normal style has been so effective.  Not one person has
given me the least support in my efforts to explain the truth about TCPA
and Palladium.

Anyway, maybe I was too personal in singling out Lucky.  He is far from
the only person who has opposed TCPA.

But Lucky, in his slides at http://www.cypherpunks.to, claims that TCPA's
designers had as one of their objectives "To meet the operational needs
of law enforcement and intelligence services" (slide 2); and to give
privileged access to user's computers to "TCPA members only" (slide 3);
that TCPA has an OS downloading a "serial number revocation list" (SNRL)
which he has provided no evidence for whatsoever (slide 14); that it
loads an "initial list of undesirable applications" which is apparently
another of his fabrications (slide 15); that TCPA applications on startup
load both a serial number revocation list but also a document revocation
list, again a completely unsubstantiated claim (slide 19); that apps then
further verify that spyware is running, another fabrication (slide 20).

He then implies that the DMCA applies to reverse engineering when
it has an explicit exemption for that (slide 23); that the maximum
possible sentence of 5 years is always applied (slide 24); that TCPA is
intended to: defeat the GPL, enable information invalidation, facilitate
intelligence collection, meet law enforcement needs, and more (slide 27);
that only signed code will boot in TCPA, contrary to the facts (slide 28).

He provides more made-up details about the mythical DRL (slide 31);
more imaginary details about document IDs, information monitoring and
invalidation to support law enforcement and intelligence needs, none of
which has anything to do with TCPA (slide 32-33).  As apparent support for
these he provides an out-of-context quote[1] from a Palladium manager,
who if you read the whole article was describing their determination to
keep the system open (slide 34).

He repeats the unfounded charge that the Hollings bill would mandate TCPA,
when there's nothing in the bill that says such a thing (slide 35);
and he exaggerates the penalties in that bill by quoting the maximum
limits as if they are the default (slide 36).

Lucky can provide all this misinformation, all under the pretence,
mind you, that this *is* TCPA.  He was educating the audience, most

Re: Thanks, Lucky, for helping to kill gnutella

[Antonomasia]

From: AARG!Anonymous <[EMAIL PROTECTED]>

> An article on Salon this morning (also being discussed on slashdot),
> http://www.salon.com/tech/feature/2002/08/08/gnutella_developers/print.html,
> discusses how the file-trading network Gnutella is being threatened by
> misbehaving clients.  In response, the developers are looking at limiting
> the network to only authorized clients:

> They intend to do this using digital signatures, and there is precedent
> for this in past situations where there have been problems:

> > Alan Cox,  "Years and years ago this came up with a game

> If only there were a technology in which clients could verify and yes,

> Be sure and send a note to the Gnutella people reminding them of all
> you're doing for them, okay, Lucky?

Now that is resorting to silly accusation.

My copy of "Peer to Peer" (Oram, O'Reilly) is out on loan but I think Freenet
and Mojo use protocols that require new users to be contributors before they
become consumers.  (Leaving aside that Gnutella seems doomed on scalability
grounds.)

Likewise the WAN shooter games have (partially) defended against cheats by
making the client hold no authoritative data and by disqualifying those
that send impossible traffic.  (Excluding wireframe graphics cards is another
matter.)  If I were a serious gamer I'd want 2 communities - one for plain
clients to match gaming skills and another for "cheat all you like" contests
to match both gaming and programming skills.

If the Gnuts need to rework the protocol they should do so.

My objection to this TCPA/palladium thing is that it looks aimed at ending
ordinary computing.  If the legal scene were radically different this wouldn't
be causing nearly so much fuss.  Imagine:
- a DoJ that can enforce monopoly law
- copyright that expires in reasonable time
 (5 years for s/w ? 15 years for books,films,music... ?)
- fair use and first sale are retained
- no concept of indirect infringement (e.g. selling marker pens)
- criminal and civil liability for incorrectly barring access in DRM
- hacking is equally illegal for everybody
- no restriction on making and distributing/selling any h/w,s/w

If Anonymous presents Gnutella for serious comparison with the above issues
I say he's looking in the wrong end of his telescope.

--
##
# Antonomasia   ant notatla.demon.co.uk  #
# See http://www.notatla.demon.co.uk/#
##

Re: Thanks, Lucky, for helping to kill gnutella (fwd)

[R. A. Hettinga]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

At 1:03 AM +0200 on 8/10/02, Some anonymous, and now apparently
innumerate, idiot in my killfile got himself forwarded to Mr. Leitl's
cream of cypherpunks list:


> They will protect us from being able
> to extend trust across the network.

As Dan Geer and Carl Ellison have reminded us on these lists and
elsewhere, there is no such thing as "trust", on the net, or anywhere
else.

There is only risk.


Go learn some finance before you attempt to abstract emotion into the
quantifiable.

Actual numerate, thinking, people gave up on that nonsense in the
1970's, and the guys who proved the idiocy of "trust", showing, like
LaGrange said to Napoleon about god, that the capital markets "had no
need that hypothesis, Sire" ended up winning a Nobel for that proof
the 1990's*.

Cheers,
RAH
*The fact that Scholes and Merton eventually ended up betting on
equity volatility like it was actually predictable and got their
asses handed to them for their efforts is beside the point, of
course. :-).

-BEGIN PGP SIGNATURE-
Version: PGP 7.5

iQA/AwUBPVRgRsPxH8jf3ohaEQIu3gCg0V9JIHnMRJ2GW+aJ1xSEHi5ETcYAn1Db
BgR2WiAxNt/zGx5Iy+uRG+Ws
=JEmi
-END PGP SIGNATURE-

-- 
-
R. A. Hettinga 
The Internet Bearer Underwriting Corporation 
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'

Re: Thanks, Lucky, for helping to kill gnutella

[Bram Cohen]

Antonomasia wrote:

> My copy of "Peer to Peer" (Oram, O'Reilly) is out on loan but I think
> Freenet and Mojo use protocols that require new users to be
> contributors before they become consumers.  (Leaving aside that
> Gnutella seems doomed on scalability grounds.)

Freenet and Mojo Nation have had serious issues in the wild, but my
project, BitTorrent, is currently being used in serious deployment, and
its leech resistance algorithms are proving quite robust - 

http://bitconjurer.org/BitTorrent/

This is a very narrow form of leech resistance, but it may be all that is
needed.

-Bram Cohen

"Markets can remain irrational longer than you can remain solvent"
-- John Maynard Keynes

Re: Thanks, Lucky, for helping to kill gnutella

[Pete Chown]

Anonymous wrote:

> ... the file-trading network Gnutella is being threatened by
> misbehaving clients.  In response, the developers are looking at limiting
> the network to only authorized clients:

This is the wrong solution.  One of the important factors in the
Internet's growth was that the IETF exercised enough control, but not
too much.  So HTTP is standardised, which allows (theoretically) any
browser to talk to any web server.  At the same time the higher levels
are not standardised, so someone who has an idea for a better browser or
web server is free to implement it.

If you build a protocol which allows selfish behaviour, you have done
your job badly.  Preventing selfish behaviour in distributed systems is
not easy, but that is the problem we need to solve.  It would be a good
discussion for this list.

> Not discussed in the article is the technical question of how this can
> possibly work.  If you issue a digital certificate on some Gnutella
> client, what stops a different client, an unauthorized client, from
> pretending to be the legitimate one?

Exactly.  This has already happened with unauthorised AIM clients.  My
freedom to lie allows me to use GAIM rather than AOL's client.  In this
case, IMO, the ethics are the other way round.  AOL seeks to use its
(partial) monopoly to keep a grip on the IM market.  The freedom to lie
mitigates this monopoly to an extent.

-- 
Pete

Re: Thanks, Lucky, for helping to kill gnutella

[Jay Sulzberger]

On Fri, 9 Aug 2002, AARG!Anonymous wrote:

< ... />

> Not discussed in the article is the technical question of how this can
> possibly work.  If you issue a digital certificate on some Gnutella
> client, what stops a different client, an unauthorized client, from
> pretending to be the legitimate one?  This is especially acute if the
> authorized client is open source, as then anyone can see the cert,
> see exactly what the client does with it, and merely copy that behavior.
>
> If only there were a technology in which clients could verify and yes,
> even trust, each other remotely.  Some way in which a digital certificate
> on a program could actually be verified, perhaps by some kind of remote,
> trusted hardware device.  This way you could know that a remote system was
> actually running a well-behaved client before admitting it to the net.
> This would protect Gnutella from not only the kind of opportunistic
> misbehavior seen today, but the future floods, attacks and DOSing which
> will be launched in earnest once the content companies get serious about
> taking this network down.

There are many solutions at the level of "technical protocols" that solve
the projection of these problems down to the low dimensional subspace of
"technical problems".  Some of these "technical protocols" will be part of
a full system which accomplishes the desired ends.  Please contact me
off-list if you willing to spend some money for an implementation.

Your claim, if true, would also demonstrate that no credit card payments
over the Net, no apt-get style updating, no Paypal-like system, no crypto
time-stamp system, etc., can exist today.

>
> If only...  Luckily the cypherpunks are doing all they can to make sure
> that no such technology ever exists.  They will protect us from being able
> to extend trust across the network.  They will make sure that any open
> network like Gnutella must forever face the challenge of rogue clients.
> They will make sure that open source systems are especially vulnerable
> to rogues, helping to drive these projects into closed source form.
>
> Be sure and send a note to the Gnutella people reminding them of all
> you're doing for them, okay, Lucky?

AARG!, this is again unworthy of you.  You are capable of attempting to
confuse and misdirect at a higher level.

You might wish to emphasize that the real difficulties are at the levels
where the reasons for the small usage of GNUPG lie.  That really the
"technical" details of the TCPA/Palladium system hardly matter.  What
TCPA/Palladium will allow is the provision to the masses of even more
powerful brews of fantasy, game playing, advertising, etc..  And that there
will be a small number of hobbyists who use the "unprotected ports of
TCPA/Palladium" for their own limited experiments/amusements/etc..  The
real point of TCPA/Palladium is that a "locus of trust", seemingly
guaranteed by the Powers That Be, will be created, and that the existence
of this same locus, under the facies of "locus of dealmaking/lawyering",
will so reassure the Infotainment Arm of the Englobulators that the Arm
will unleash its extraordinary forces to build and sell ever more
entrancing Palaces of Dreams.  The "unprotected ports" will allow a mostly
self-supporting farm team system which will function without much direct
oversight and little outlay of money by Englobulator Central or any of the
Arms.  The limited freedom of the Farm System, with its convenient pull
strings, for the cases where something large and not controlled by Those
Who Know Best takes off, will be a powerful lure to up and coming future
Talent, who, when the time comes, may be Signed, without today's confusing
and annoying possibility of continued independence.  Indeed, the EULA of
every system might have a section which binds users who display Marketable
Things to an automatic Arbitration of Contract.

oo--JS.

Re: Thanks, Lucky, for helping to kill gnutella

[Mike Rosing]

On Fri, 9 Aug 2002, Jay Sulzberger wrote:

> There are many solutions at the level of "technical protocols" that solve
> the projection of these problems down to the low dimensional subspace of
> "technical problems".  Some of these "technical protocols" will be part of
> a full system which accomplishes the desired ends.  Please contact me
> off-list if you willing to spend some money for an implementation.

Hey!  Tell the Gnutella folks I'll be happy to bid on that too!
I'm pretty sure I can get them a solid solution, especially since it's
just a "technical" problem.

Patience, persistence, truth,
Dr. mike

Re: Thanks, Lucky, for helping to kill gnutella

[Bram Cohen]

AARG!Anonymous wrote:

> If only there were a technology in which clients could verify and yes,
> even trust, each other remotely.  Some way in which a digital certificate
> on a program could actually be verified, perhaps by some kind of remote,
> trusted hardware device.  This way you could know that a remote system was
> actually running a well-behaved client before admitting it to the net.
> This would protect Gnutella from not only the kind of opportunistic
> misbehavior seen today, but the future floods, attacks and DOSing which
> will be launched in earnest once the content companies get serious about
> taking this network down.

Before claiming that the TCPA, which is from a deployment standpoint
vaporware, could help with gnutella's scaling problems, you should
probably learn something about what gnutella's problems are first. The
truth is that gnutella's problems are mostly that it's a screamer
protocol, and limiting which clients could connect would do nothing to fix
that.

Limiting which clients could connect to the gnutella network would,
however, do a decent job of forcing to pay people for one of the
commercial clients. In this way it's very typical of how TCPA works - a
non-solution to a problem, but one which could potentially make money, and
has the support of gullible dupes who know nothing about the technical
issues involved.

> Be sure and send a note to the Gnutella people reminding them of all
> you're doing for them, okay, Lucky?

Your personal vendetta against Lucky is very childish.

-Bram Cohen

"Markets can remain irrational longer than you can remain solvent"
-- John Maynard Keynes

Re: Thanks, Lucky, for helping to kill gnutella

[Eric Murray]

On Fri, Aug 09, 2002 at 10:05:15AM -0700, AARG! Anonymous wrote:
 
> > On Gnutella discussion sites, programmers are discussing a number of
> > technical proposals that would make access to the network contingent
> > on good behavior: If you write code that hurts Gnutella, in other
> > words, you don't get to play. One idea would allow only "clients that
> > you can authenticate" to speak on the network, Fisk says. This would
> > include the five-or-so most popular Gnutella applications, including
> > "Limewire, BearShare, Toadnode, Xolox, Gtk-Gnutella, and Gnucleus." If
> > new clients want to join the group, they would need to abide by a certain
> > communication specification.
> 
> They intend to do this using digital signatures, and there is precedent
> for this in past situations where there have been problems:


Depending on the clients to "do the right thing" is fundamentally stupid.


[..]

 
> Be sure and send a note to the Gnutella people reminding them of all
> you're doing for them, okay, Lucky?

This sort of attack doesn't do your position any good.


Eric