# Can I use asymmetric encryption for more powerful write-protection?

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?

-
Sounds like you want a signature rather than encryption –  figlesquidge Mar 4 '14 at 0:36
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? –  Stephen Touset Mar 4 '14 at 1:04
@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. –  Mike Carpenter Mar 4 '14 at 1:09
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. –  izaera Mar 4 '14 at 7:31
@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. –  Mike Carpenter Mar 4 '14 at 19:22

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.