..on or around Mon, Dec 24, 2007 at 10:24:15PM +0100, Jan Ciger said: > -----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. >
i doubt it is at all possible to entirely defeat cheating, with free-software especially. you can however make it harder by ensuring that one key cannot be used by multiple clients. at the end of the day, efforts would probably be better spent designing an engaging system of play where mutual benefit figures strongly, as opposed to a model where metaphors of singular capital gain (experience points, levelling etc) are primary. cheating, and its behaivoural cousin stealing, only exist under conditions where resources are strategically maldistributed. > > 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. yes of course, but just for one connecting client if the server only recognises one simultaneous connection from a client with the appropriate key. > > > 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). i don't think it breaks the GPL at all. 'Tivoisation' apples to the problem of there being a trigger in hardware that breaks hardware/software functionality if the client is modified, regardless of the fact that the source itself is open. generating keys at the point of distribution concerns a tracking and authentication issue and passes on no primary lack of priviledge under the GPL-compliant terms of the binary distribution (as i understand it). Feliz Navidad, julian -- http://julianoliver.com http://selectparks.net emails containing HTML will not be read. _______________________________________________ Soya-user mailing list [email protected] https://mail.gna.org/listinfo/soya-user
