[MUD-Dev] Trusting the client, encrypting data

[J C Lawrence]

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
  consistency constraints).  

  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
  environments.

  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
  Fract.

  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
  return messages.  

So far so good, but it gets especially interesting when third parties
get involved:

  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
matters:

  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.

Hehn.

--
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
https://www.kanga.nu/lists/listinfo/mud-dev