Technical solution to eliminate desync in single-player sessions

"

qwave wrote:

By adding some cryptographic salt/hash to the random number generator, it can be made computationally infeasible for a bot to produce desirable outcomes.

Are you really in the software industry? Because this is just...

Look, if the client decrypts the data, then the client decrypts the data. All encryption does is protect against man-in-the-middle attacks. You can't use encryption to protect the client from its own hacks.

"

Look, if the client decrypts the data, then the client decrypts the data. All encryption does is protect against man-in-the-middle attacks.

No, you have it backwards. The client/bot would not be decrypting data, they would be using the seed and a cryptographic hash to generate the next random number. This makes it more computationally expensive for bots to generate snapshots. The client could do it easily because it's not evaluating permutations.

The client is therefore using encryption to generate the snapshot. It has nothing to do with security.

"

qwave wrote:

"

Look, if the client decrypts the data, then the client decrypts the data. All encryption does is protect against man-in-the-middle attacks.

No, you have it backwards. The client would have to generate the random number by using a cryptographic hash with the random seed. This makes it more computationally expensive for bots to generate snapshots. The client could do it easier because it's not evaluating permutations.

The client is therefore using encryption to generate the snapshot. It has nothing to do with man-in-the-middle attacks.

Seriously?

You can't add a time-expending computation task to the client, as part of normal operating procedure — in this case, decryption — and expect a hack to not be able to perform the same action in the same amount of time. Apparently you live in some kind of magical fairyland where illegitimate actions take time to perform, but legitimate actions are instantaneous, therefore the good guys always win the race.

You're right: it does have nothing to do with man-in-the-middle attacks. Which is why using encryption as a problem-solving strategy is completely fucking retarded.

"

You can't add a time-expending computation task to the client, as part of normal operating procedure — in this case, decryption — and expect a hack to not be able to perform the same action in the same amount of time.

The bot would be trying to evaluate all permutations of the data, so it would need to generate millions/billions of these computational tasks. The client only needs to do it once. This is how to prevent hacks from producing desired results ... by making it too expensive to do. =)

"

qwave wrote:

"

You can't add a time-expending computation task to the client, as part of normal operating procedure — in this case, decryption — and expect a hack to not be able to perform the same action in the same amount of time.

The bot would be trying to evaluate all permutations of the data, so it would need to generate millions/billions of these computational tasks. The client only needs to do it once.

The bot has the key (because the client has it), and only sends communication once. Therefore, it only needs to calculate one permutation, at least in terms of encryption. Perhaps multiple permutations unencrypted, but most definitely not multiple encryptions.

"

The bot has the key (because the client has it), and only sends communication once. Therefore, it only needs to calculate one permutation.

If the bot only calculates one permutation, then how does it evaluate the millions of permutations (each needing a new cryptographic calculation) required to generate a favorable 'outcome'? In other words, if it calculates the seed and determines that the 'next hit is a crit', it needs to calculate how to avoid that hit, which involves numerous (potentially millions/billions) of calculations. This is because avoiding the hit could involve death.

"

qwave wrote:

If the bot only calculates one permutation, then how does it evaluate the millions of permutations (each needing a new cryptographic calculation) required to generate a favorable 'outcome'?

This scenario would never occur, because it's never true that each requires a new cryptographic calculation. Network traffic in is decrypted; network traffic out is encrypted; nothing in between requires cryptography.

This has nothing to do with the network. I am talking specifically about a bot which is trying to generate a snapshot with tampered data.

"

Bots would have to compute each outcome and permutation, which im saying is too computationally expensive, especially with a cryptographic salt/hash

Bots have to compute some outcome and choose the one they prefer from the calculated ones. It is a low-level version of the same thing your brain do analogically when you choose wheter attack mobs or flee and restore for a while.

"

qwave wrote:

This has nothing to do with the network. I am talking specifically about a bot which is trying to generate a snapshot with tampered data.

Which it then sends, over the network, to the server. Which means: it only needs to decrypt data once, when the data from the server is received, and it only needs to encrypt it once, after it has determined what snapshot it is going to send. It already has the key, because the client has it, and you can't send an encrypted key with previous sending an unencrypted key to decrypt an encrypted key (which the bot would also have). There is no way to use encryption to add additional computation time to a malicious client without adding the same amount of computation time to a legitimate client.

Now, when it comes to calculating permutations, yes, the bot would likely have to do that multiple times. But encryption is not a factor, because encryption is only useful at preventing man-in-the-middle attacks.