This is more than just an issue with saved games. The hidden state information is transmitted out to all clients to keep them in sync. One game piece can include both hidden information and open information. Clients other than the owner of the piece can manipulate some aspects of that piece, and must maintain that ‘hidden’ state, and be able to transmit it on to further clients.
Theoretically, it should be possible to isolate the ‘hidden’ state and use Public Key Cryptography to keep it from being read in the clear by other clients.
This is a really fundamental issue that is vital to get right from the start.
But making savegame files completely human-readable XML seems to me
problematic if that savegame file contains hidden piece information
– it would be perhaps too easy for someone to sneak a peak at his
opponent. Unless you’d find a way to encrypt or otherwise serialize
hidden information.
This is more than just an issue with saved games. The hidden state
information is transmitted out to all clients to keep them in sync. One
game piece can include both hidden information and open information.
Clients other than the owner of the piece can manipulate some aspects of
that piece, and must maintain that ‘hidden’ state, and be able to
transmit it on to further clients.
Theoretically, it should be possible to isolate the ‘hidden’ state and
use Public Key Cryptography to keep it from being read in the clear by
other clients.
This is a really fundamental issue that is vital to get right from the
start.
There’s an easy thing, and an impossible thing here. The easy thing is
dealing with static state. (By “static” I mean that a user cannot gain
or lose access to any information while working with the file.) Each
permission group has a key pair. You can think of users as single-member
groups. Everything accessible to a group is encrypted with that group’s
public key. To include group A in group B, you encrypt group B’s private
key with group A’s public key.
This completely solves the problem of hidden information that can be
revealed by the owner of that information only. For example, if I draw
a card, and it’s the sort of game where no one else gets to look at
or take my card, then a public key system works perfectly. You can’t
decrypt the data about my card without my private key, which you don’t
have.
The impossible thing is to have security when one player can take
actions which reveal hidden information, and needs to do so offline.
So, for example, if I need to be able to take any one of your cards, or
flip over one of your pieces, then my computer needs to have access to
the data that’s hidden so it can show me what card I took or the other
side of the piece I flipped. But if my computer has that data, then I
have that data; e.g., I could always reload and check out each of your
cards. There’s no way to reveal information securely offline in a way
that ensures only as much information is revealed as is supposed to be.
Exactly. That will be a built-in limitation. Take the example of the current ‘Invisible’ trait. Only an action by the owner of the invisible trait can make it visible. No action by any non-owner can do this. The hidden ‘state’ in this case is the location of the piece and the state of all traits ‘under’ the invisible trait. And this hidden state needs to be recorded in the saved games which will be human readable, so the hidden state will need to be encrypted within the saved game. Making the saved game somewhat less human readable
I don’t believe I ever suggested this. As in the current Vassal, only the owner of a piece would be able to un-hide or un-obscure it. Non-owner clients will need to maintain this encrypted hidden state, and save it, load it and copy it to other clients, but will not be able to do any operations on it.
The impossible thing is to have security when one player can take
actions which reveal hidden information, and needs to do so offline.
Exactly. That will be a built-in limitation. Take the example of the
current ‘Invisible’ trait. Only an action by the owner of the invisible
trait can make it visible. No action by any non-owner can do this. The
hidden ‘state’ in this case is the location of the piece and the state
of all traits ‘under’ the invisible trait. And this hidden state needs
to be recorded in the saved games which will be human readable, so the
hidden state will need to be encrypted within the saved game. Making the
saved game somewhat less human readable
My point about saves being human-readable is about the nonencrypted
parts (and about the plaintext corresponding to the encrypted parts).
I agree that the ciphertext won’t be human-readable, in any case.
So, for example, if I need to be able to take any one of your cards,
or
flip over one of your pieces, then my computer needs to have access to
the data that’s hidden so it can show me what card I took or the other
side of the piece I flipped.
I don’t believe I ever suggested this. As in the current Vassal, only
the owner of a piece would be able to un-hide or un-obscure it.
Non-owner clients will need to maintain this encrypted hidden state, and
save it, load it and copy it to other clients, but will not be able to
do any operations on it.
Yes. I’d like to make it easy to toggle access restrictions, though, so
that the same module can be used with access restrictions, or offline
without them, as the players choose. (E.g., I have no problem playing
against my usual opponent with unencrypted save data, as he’s not likely
to cheat and having relaxed access restrictions epeditese making moves
which require revealing hidden information.)
Since you are talking about getting standards right early how do you propose to handle double blind situations where one player can inspect some trait(s) of the piece without revealing that action to the owner of the piece?
I am hoping that you will plan a little outside the limits of the traditional tabletop game metaphor. This is where the traditional metaphor breaks down and yet there is a clear demand for such functionality from players. The two ways to compensate for this limitation of the tabletop have been 1) adding some noise to the data returned by the owner of the piece (size, components, location; the best osbscuration that I have seen was in SPI’s Task Force where there was noise in both the searcher’s location and the searched location) or 2) the more perfect means of employing a referee (which unfortunately requires the effort of a third party).
Isn’t this where the module itself could serve as the referee, something a tabletop game cannot do, where the module designer could set parameters for player actions to decrypt (re-encrpyt is probably the better term here) normally enccrypted properties?
