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.
--------_sunder_ at _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.