I have an application running the client/server model and offering an online and an offline mode. Each user can read, create or modify text files (even in offline mode) that will be present on his disk. I want to prevent any hand-cration or hand-modification of these files done manually, I mean without client application, so that when a client tries to send a file to the server, the server checks if the digital signature matches, if it doesn't, the file will simply be rejected. Two different clients generating an identical file from a content point of view will provide an identical signature, because I am not interested in the user's identity aspect, only in the tamperation aspect of the data.

To be more specific, I'm coding a game, so the server represents the shop. I do all this to check that the file (which can represent money for example) was created via my app and not by hand by a malicious player who gave himself a large amount of money).

Could the digital signature principle work for me? Because the same smart guy who would try to falsify files could also look into the byte code to see how the function that calculates the digital signature of any file works, in order to reproduce it to create files considered valid by the server as well?

I wonder if I have understood the principle of the digital signature: is the signature really happening client-side? If so, how is the mechanism "hidden" from potential hackers?

Here's a graph I made to explain how the file should behave according to the actions we apply on it.


EDIT: Replacing everything with a more recent, complete and readable version of my initial question.

  • @Matthew No fore example content could be 0 \n 1 \n 2. May 13, 2019 at 10:27

2 Answers 2


Given the requirements in the question, you're stuck:

  1. The client is out of your control - it runs on someone else's computer, they have full access to it, so any mitigation which relies on it having some secret in it can be bypassed. That rules out digital signatures used in this way.
  2. The files are out of your control - they don't contain any authentication method to prove that they were generated by your client and then unmodified. Given an entirely offline client, furthermore, they can't contain anything which would prove that. Depending on your game, that could be a dealbreaker.
  3. The server is under your control, but relies on data which it shouldn't trust, because there is no way to prove it hasn't been tampered with.

So, something will have to give. Some examples could be:

  1. Have the server generate initial files for server-compatible games, which are signed by a key held on the server, and verified by the client using a corresponding public key. Advantage: means you can control the valid initial states, and detect modifications. You can have unsigned initial files for offline play. Disadvantage: you can only generate official states while the server is up and the client is online.
  2. Enforce maximum limits on the server, so even if the client supplies a tampered file, it actually gives a valid amount of whatever has been adjusted. If you want to punish the users for tampering the file, make any value above a pre-set maximum result in a starting value of 0. Advantage: you control the game, doesn't require signature infrastructure. Disadvantage: you risk annoying users if the limits are wrong (e.g. playtesting reveals a change is required following a particular update).
  3. Relax the worry about the client, and implement some form of player rating scheme, so players who cheat are detected and removed over a period of time. Advantage: allows for current method to stand. Disadvantage: costs of running rating system in an appropriate way.
  • Anyways I was planning onto use internet even for single player adventure (meteo, time... etc) and nowadays internet is almost everywhere, plus this will cost nearly 0 KB. May 13, 2019 at 21:02
  • @AxelCarré a looooko
    – Matthew
    Jun 3, 2019 at 19:44

There is no stricly secure way. If a modification can be applied offline through the official app, then that app needs to have client side everything that is required to build the new version of the file. So a hacker should be able (at least through disassembly tools) to find what the app does and mimic it. But you can make that hard enough to prevent many users to do it. That is essentially called obfuscation. That means an information that is present (the app need it) but hard to find.

If a lot of actual money is involved of if the consequences could be really serious, I would not use obfuscation. If the amount is not mission critical, you will have to balance between the risk of somebody hacking into your app, and the gain of offering many users an interesting feature. I am sorry not to give you a precise answer but it is the best I can do.

  • Thanks for your answer it helped me a lot since you validated what I thought but was not sure of, I'm accepting @Matthew's answer because he gave me workarounds. May 13, 2019 at 20:05

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .