I have a game that I am developing which uses a locally-stored internal database. It does not matter to me whether a user can read the file (which, to me, means I don't need a symmetric cipher), but I don't want it to be possible for a user to alter it without completely breaking the game (essentially, to make cheating more difficult). Obviously file permissions alone wouldn't protect against someone on an administrator account or with a rooted device.

My thought was to use an asymmetric cipher where, opposite how it usually goes, the decryption key is public and the encryption key is private. I would then distribute the already-encrypted database and the game could decrypt it. I believe that this would prevent alterations, because the user would have to be able to properly re-encrypt the altered file for the game to be able to read it (unless they also altered the game binaries), which they wouldn't be able to do.

However, I've done a bit of searching and I can't seem to find this method mentioned anywhere, so I don't know if it is a good idea or if I've overlooked something. Is this a good approach?

Also, I want to use SQLite. I know of SQLCipher, but that uses AES so obviously that wouldn't work for me (because it's symmetric and therefore the user could intercept the encryption key by obtaining the key which is used to decrypt). Are there any public-key SQLite encryption libraries?

  • 2
    $\begingroup$ Sounds like you want a signature rather than encryption $\endgroup$ Commented Mar 4, 2014 at 0:36
  • $\begingroup$ Say you sign the data, or encrypt it, or otherwise have some other protection mechanism. What's to stop the user from modifying the data in-memory once loaded and verified? $\endgroup$ Commented Mar 4, 2014 at 1:04
  • $\begingroup$ @StephenTouset I don't need to make it literally impossible. If it has to be modified in-memory, that for me is reasonably prohibitively difficult. It's a single-player game, I just don't want to make it so trivial to cheat that editing a database file is sufficient, which far more people are capable of or willing to do than edit in-memory. $\endgroup$ Commented Mar 4, 2014 at 1:09
  • $\begingroup$ Apart from editing in memory, I suppose someone could debug your application and find the key you use to sign the data. You will have to obfuscate that if you want to raise the bar a little more. $\endgroup$
    – xxxxxxxxx
    Commented Mar 4, 2014 at 7:31
  • $\begingroup$ @izaera The database is static and would only ever change in bugfixes or updates, so that key wouldn't be anywhere in the distribution at all. No signing of any file would ever happen on any machine but my own. $\endgroup$ Commented Mar 4, 2014 at 19:22

1 Answer 1


What you describe is a digital , which works using methods very similar to the one you suggest. Examples include and RSA signature schemes (the second of which I would recommend you read).

Digital signatures allow you to provide a public signature that 'proves' you provided the message. As the author, you would produce database $m$ and a signature $s=s(m)$ confirming it is what you wanted. You then provide your program with an algorithm $V$, called a verifier. The verifier tests whether $s$ is a valid signature for $m$. If the signing algorithm was deterministic, an example verifier could just recompute the signature.

As with all crypto code, be wary of implementing a signing algorithm yourself, since there are lots of subtle pitfalls you may hit, such as the RSA homomorphic property.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.