Thanks, Lucky, for helping to kill gnutella
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:
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:
Alan Cox, a veteran Linux developer, says that he's seen this sort of debate before, and he's not against a system that keeps out malicious users using technology. "Years and years ago this came up with a game called Xtrek," Cox says. People were building clients with unfair capabilities to play the space game -- and the solution, says Cox, was to introduce digital signatures. "Unless a client has been signed, it can't play. You could build any client you wanted, but what you can't do is build an Xtrek client that let you play better."
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. 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? --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@wasabisystems.com
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 --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@wasabisystems.com
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 --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@wasabisystems.com
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.
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
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
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.
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 majordomo@wasabisystems.com
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. sws@cs.dartmouth.edu http://www.cs.dartmouth.edu/~sws/ (has ssl link to pgp key) Department of Computer Science, Dartmouth College, Hanover NH USA --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@wasabisystems.com
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.
-- ----------------- R. A. Hettinga <mailto: rah@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' --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@wasabisystems.com
i guess it's appropriate that the world's deepest hole is next to something labelled a "trust territory" :) --Sean :) --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@wasabisystems.com
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 <mailto: rah@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'
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. --------_sunder_@_sunder_._net_------- 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.
participants (11)
-
AARG!Anonymous -
Bram Cohen -
Eric Murray -
Jay Sulzberger -
Jeroen C.van Gelderen -
Mike Rosing -
Pete Chown -
R. A. Hettinga -
Sean Smith -
Seth Johnson -
Sunder