-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Julian Oliver wrote: > yes, this is difficult. the closest you could get would be to sign the binary > with the public key but it still wouldn't defeat the problem of someone > with enough know-how to compile their own client using that same key. it > would however still solve the problem of many clients authenticating > using the same key simultaneously.
First, that doesn't solve the cheating - everybody can sign their (even hacked) client using the valid key. Second, how is the issue of multiple clients using the same key relevant? This is relevant only for copy protection (moot point for OSS game, I hope), not as a protection against cheating. > the public key would be just that, public. the private key however > wouldn't be known to the client. that would reside on the server. > > the source would be open, and the software still free (i think) - in the > sense of this not qualifying as 'Tivoisation' - but the actual key pairing > itself would be secret. > > i send all mail and perform server/website administration using ssh-agents. > what i'm imagining would be like this, but reversed, where the server has the > private key and the signed binary client has the unique public corresponding > key. You cannot do this - give out the public key(s) and claim that the pairing is secret. It is not - each and every key has a well defined mathematical binding to certain private key somewhere. Again, this is not really relevant - I can always extract the correct key from the official client. I could do it even if it is not open source - witness the breaking of Blueray and HD-DVD encryption that actually tried to implement this system - the key was extracted from the binaries, despite heavy obfuscation. I can then re-use the official key with my hacked client. If the client side is untrusted, this is a worthless method, as the Blueray case proves. > without knowing the private key it wouldn't be possible to generate a > new public key. it would however be possible to author a modified client > that "sent junk", as you say, using the same public key. Yes, but I do not need to generate new public key to cheat. Reusing the old one is more than enough. I do not need to run the normal and hacked binaries side by side that are needed in order to trigger the key re-use alarm. Moreover, requiring an unique key for every binary to be actually useful would very likely break GPL, because you are placing additional technical restrictions, but withholding the parts required to make use of the program as intended (the private keys). This clearly breaks GPL v3 (the anti-DRM part - what you are describing is a DRM system, not an anti-cheating system). It could be even argued to break GPL v2, but there it is less clear (as the Tivo case proves). In general, if the client is untrusted, no amount of encryption will save you. It is like a bank sending out a safe full of money using a crooked carrier somewhere to Nigeria or Iraq and expecting the money to come back intact. You can have the best safe in the world, but you are giving it to people who would either steal it while in transit before it gets in the safe (untrusted medium) or have all their time and equipment needed to get in the safe and extract the cargo afterwards (untrusted client). No amount of armour-plating of the safe nor the extra three locks only you are holding the keys from will save the money if the safe gets into an industrial workshop with a really big drill ... (our enterprising hacker extracting the keys ...) Regards, Jan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFHcCN7n11XseNj94gRAreUAJ9x9ylMr4huV8Xhvd2qoO6XE1yRYwCdFB01 fCQUiRfG8gqd1uGfF6d/f/E= =EoDz -----END PGP SIGNATURE----- _______________________________________________ Soya-user mailing list Soya-user@gna.org https://mail.gna.org/listinfo/soya-user
