[MUD-Dev] Trusting the client, encrypting data
J C Lawrence
claw at kanga.nu
Fri Dec 19 20:49:55 New Zealand Daylight Time 2003
On Thu, 18 Dec 2003 10:20:13 +0000
ceo <ceo at grexengine.com> wrote:
> Please examine the earlier posts on this topic; the suggestion was
> that the keys be distributed lazily, on-demand, i.e. "just in time",
> or when the data was about to be used.
An interesting point is to extrapolate this out:
All transmitted game world state is encrypted. Any one of the
computationally cheap ciphers would do, so long as the crack time for
the cipher was significantly longer than the half life of the data.
Every node, every client, is sent continuously send the entire world
state and is (arm wave) perfectly synchronised (well, within logical
Each client possesses a small number of keys which it can use to
decipher a subset of the data that pertains to its user's
A user can only see that aspect of the world which is revealed by the
cipher keys that have been revealed to that user.
This gets particularly interesting when you start looking at using the
key space to segment the world and player population horizontally:
Bubba and Boffo are in the same location in the game world, in front
of fortress Fract.
Bubba and Boffo can both see Bernie, who is also in front of Fortress
Bernie can also see Bubba and Boffo, as they all have the relevant
data keys for each other's data streams.
Bubba however can't see Boffo as he doesn't have the requisite key,
and in fact Bubba can't interact with Boffo because he doesn't have
the key. As such, Boffo is effectively invisible to Bubba. Bubba can
be told by third parties that Boffo is there, but he has no possible
way of detecting that for himself, let alone directly interacting.
Boffo however can see Bubba as he does have the key for Bubba's data
stream, but Boffo can't interact with Bubba as any messages/events he
sends Bubba's way never come back. This is because Bubba can't
decrypt them and thus Bubba's methods never get called to generate
So far so good, but it gets especially interesting when third parties
Boffo now attacks Bernie. As they can decrypt each other's data
streams this is a normal conflict. The interesting viewpoint in this
is Bubba's. Bubba sees Bernie fighting an invisible opponent and
sustaining damage and other physical effects from invisible objects...
Boffo now picks up a sword which Bernie drops. To Bubba's point of
view the sword is now enchanted, self-wielding in fact, and it dances
and swings about thru the air, attacking Boffo and in fact swung by
the invisible Boffo.
A curious definition of magic: the editing of viewpoints so as to
control perception. Somehow this is very reminiscent of a favourite
book, The Veils of Alzaroc (well worth reading). But, onto more mundane
The obvious client-side crack is to run a P2P broadcasting system on
the clients broadcasting keys to the other players so that player's
can share each other's world views. In this way they could defeat the
limited viewpoint constraints. The defence against this is equally
trivial: The world data for each node is encrypted with a key which is
private to that client and different from other clients.
The obvious attack on this is not to share the keys, but to
dynamically share the decrypted data, the results of the processing
the keys they do have against the world.
About the only clear way I can see of handling this is to make the
data streams which each node receives in some way personal to that
node. ie subjectively contextual to that node to such a degree that
the significant transformation is required for one node's data to be
useful to another node.
This has obvious problems:
-- Nodes can use OOB protocols to synchronise and establish a
running transformation process for the data streams.
-- Worse, nodes could undo the personalisation of the data streams
and republish the decrypted data in clear text (as it were) for
import by other nodes.
The obvious control on this is to make the personalisation mapping
dynamic on a set of parameters which are not (entirely) deducible by
the client (eg exact world position, which the client knows only
approximately). This would have the effect of making even the clear
text data streams taken from another client no better than a slightly
time delayed approximation. Bubba can now see that Boffo is in the
room, but his view is fuzzy and has a wobbly latency of 2*RTT (I'm
know I'm ignoring bandwidth concerns everywhere else).
Cute. Sort of a Heisenburg function for your game world. You can see
everything as it may have been, sort of. You can see each discrete
object and data stream for the entire world as it was at some random
point within (say) the last two seconds, but each object can be at a
different point within the 2 second window and there's no clue as to
where in the window each object's view is...and you can see the data you
have keys for in perfectly coherent synchronicity.
Fuzzy spectacles with a hard focus centre.
J C Lawrence
---------(*) Satan, oscillate my metallic sonatas.
claw at kanga.nu He lived as a devil, eh?
http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live.
MUD-Dev mailing list
MUD-Dev at kanga.nu
More information about the MUD-Dev