Resume Game

Based on original idea from feedback page.

The current idea is based on secure communication between players, where each player sends an encrypted code that the receiver will only be able to decrypt later on. This will be used to confirm that players are who they claim to be.

Encrypted method

To securely resume a game, public-key cryptography is applied. First, each player has a private key and a public key, which is randomly generated one-time by W:A.

When the game begins, the player's public keys are shared, so that only the sender and receiver can read the exchanged messages. The players then exchange messages with codes, that are encrypted to the receiver, which will be later decrypted if the game is suspended. The codes are saved in the replay, with decryption codes.

The game is suspended at the end of a turn, when all players agree to do so. The host would type in the command '/suspend' during a turn, and when the turn's completed, the game would pause. All players would need to agree to suspend the game.

When a game is about to resume, the players send a second message, decrypting the first, and the players confirm that they have decrypted the message to the original sender.

E.g. An encrypted message was sent to players when game is suspended. The decryption message sent when the game resumes:

• P1 to P2: ANR
• P1 to P3: TXP
• P2 to P1: QCH
• P2 to P3: IZT
• P3 to P1: WGG
• P3 to P2: RLD

Which decrypts the original message:

• P1 to P2: Code is 527
• P1 to P3: Code is 167
• P2 to P1: Code is 502
• P2 to P3: Code is 119
• P3 to P1: Code is 293
• P3 to P2: Code is 954

The messages are returned to sender:

• P2 to P1: Your code was 527
• P3 to P1: Your code was 167
• P1 to P2: Your code was 502
• P3 to P2: Your code was 119
• P1 to P3: Your code was 293
• P2 to P3: Your code was 954

When the codes are confirmed, the game resumes.

Notes

The addition of an encrypted message between two people, that can only be unlocked when the game resumes, means that third-parties will find it difficult to takeover a player's team without permission, even with the help of other players.

It may be possible to work around this, after obtaining the resume codes. A centralised server may be a better option, though this adds a single-point-of-failure to the method.

Signed method

A second option is to confirm that a player played in a game, using a signature in the replay that only the developer can read.

A developer releases a public key, again using public-key cryptography, and the player sends a message to the developer using the key, which includes their own public key, along with a signature.

When the game starts, the players add the signature to the replay using the developer's key, along with additional information on the game itself. The developer is the only person who can read all of the signatures in the replay.

Every time the game is resumed, the signature is added, along with info on the game.

E.g. Alice's signature is 8204610382, and Bob's 6206100293. The message Alice embeds in the replay:

• Name: Alice
• Signature: 8204610382
• Date: 2009-01-01 00:00 GMT
• Players: Alice, Bob
• Game time: 00:00:00
• Turn number: 0

And Bob's:

• Name: Bob
• Signature: 6206100293
• Date: 2009-01-01 00:00 GMT
• Players: Alice, Bob
• Game time: 00:00:00
• Turn number: 0

When resuming, the information is copied, but the game time and turn number would be different.

Different players can resume the game, e.g. Chris takes over from Alice, but Alice's second signature and information will be missing.

This method means that a developer can always tell if players were playing after resuming a game.

Notes

Of course, the developer and player's private keys must be kept secure, and a backup plan, such as more than one developer key, and ability to revoke a key, may be necessary.