..on or around Mon, Dec 24, 2007 at 03:16:01PM +0100, Jan Ciger said: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Julian Oliver wrote: > > right.. but what about a public/private key like exchange, similar to > > that which we use with SSH? the server generates a unique private key > > and stores that key in a private database matching it to a public key > > which it ships with the binary. just as with SSH, the software to generate > > the key is openly available but the unique public/private key combination > > itself is not easily reproduceable: the server only allows one current > > connection from a signed binary client with the correct corresponding, > > registered public key. > > This doesn't work - how exactly is the client protected against > modification by a public key that *doesn't* depend on the content of the > executable binary? >
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. > Moreover, you cannot make the key secret - if we are speaking about an > open source game, there is nowhere to hide it. 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. > > Public key crypto is not appropriate for this - the same as the music > industry learned in the DRM case. Crypto is designed to work with *both* > ends trusted and assumed secure and the transmission channel insecure - > you are protecting the data in transit. > > If the remote end is untrusted (the game client), no crypto will save > you. In the above example you will only protect the transmitted data > from being sniffed or altered, but the client can still send junk (but > properly authenticated!) and the server will be none the wiser. > 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. cheers, julian -- http://julianoliver.com http://selectparks.net emails containing HTML will not be read. _______________________________________________ Soya-user mailing list Soya-user@gna.org https://mail.gna.org/listinfo/soya-user
