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.