Difference between revisions of "Resume Game"
From Worms Knowledge Base
(Added signed method) |
|||
| (2 intermediate revisions by the same user not shown) | |||
| Line 3: | Line 3: | ||
Based on [http://feedback.worms2d.info/pages/general/suggestions/72462 original idea] from feedback page. | Based on [http://feedback.worms2d.info/pages/general/suggestions/72462 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. | |
| − | To securely resume a game, [http://en.wikipedia.org/wiki/Public-key_cryptography public-key cryptography] is applied. First, each player has a private key and public, which is randomly generated one-time by W:A. | + | == Encrypted method == |
| + | |||
| + | To securely resume a game, [http://en.wikipedia.org/wiki/Public-key_cryptography 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. | 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. | + | 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 P2: Code is 527 | ||
* P1 to P3: Code is 167 | * P1 to P3: Code is 167 | ||
| Line 19: | Line 31: | ||
* P3 to P2: Code is 954 | * P3 to P2: Code is 954 | ||
| − | + | The messages are returned to sender: | |
* P2 to P1: Your code was 527 | * P2 to P1: Your code was 527 | ||
* P3 to P1: Your code was 167 | * P3 to P1: Your code was 167 | ||
| Line 27: | Line 39: | ||
* P2 to P3: Your code was 954 | * P2 to P3: Your code was 954 | ||
| − | When the | + | 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 [http://en.wikipedia.org/wiki/Public-key_cryptography 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. | ||
Latest revision as of 20:16, 8 December 2008
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.
