I have an iOS and Android app where our "secret sauce" is a bunch of numbers (weights, actually) stored in a database. Our app uses these numbers to compare what the user of the app has given it, and then provides a result.

To put that another way, a user launches the app and gives the app a set of numbers based on some questions. We compare the numbers from the user input to our database of "secret sauce" numbers and give the user a comparison result.

Is there a way to encrypt the database of "secret sauce" numbers that can only be accessed by the app? We don't need the user to authenticate, just the app to authenticate.

A tiny wrinkle here is that we'd like to be able to update that "secret sauce" database over time as we get better data.

  • "Is there a way to encrypt the database of "secret sauce" numbers that can only be accessed by the app?" No. You will have to lower your expectations. Commented Jun 13, 2016 at 16:03
  • Without knowing all the details of the comparison of the input to the "secret sauce", is it possible to determine these "secret sauce" numbers from the results of multiple inputs? I'd bet it'd be possible since the "secret sauce" numbers are static (at least temporarily, until updated over time). Commented Jun 13, 2016 at 16:12
  • Can you clarify where these "secret sauce" numbers come from? Some seem to think they are generated entirely client-side based on user input, and suggesting solutions based on that assumption. My understanding is this is semi-static data you want to keep secret. Which is it? Commented Jun 13, 2016 at 17:02
  • My understanding is that even if the "secret sauce" numbers come from a server, you can send them over TLS, so the important part is how they are stored on the device - so the important question is how to encrypt them which leads to how to store the key. Despite your lovely criticism Alexander, I think storage of the key is the important factor here. Commented Jun 13, 2016 at 17:43
  • Hi all. Awesome responses here, thank you. So, I have now lowered my expectations. The weights we have and the user inputs are sufficiently complex that you'd have to be crazy dedicated to crack them. The "secret sauce" numbers are numbers we have come up with over a couple of years and would not come from the user of the app - the app just compares what the user gives to what we have. We want to avoid having the app be connected in any way to a server during use. You may have missed the "Montana" part of my user name, but there are MANY places in Montana where there is no signal. Commented Jun 13, 2016 at 23:28

2 Answers 2


If the app can access the data locally (on the user's device), then a determined individual can as well. If you really want to keep the values secret you could consider having the app send the user's input to a server (which you would control) which both stores the secret values and computes the value for the user. The server would then send the value back to the app to display.

This would improve your update problem as you could simply update the servers values whenever a change is required.

Note that someone could easily submit numerous inputs and map them to outputs which, depending on what type of computations are being done, could allow them to deduce the secret values.


Great question, and welcome to the landmine of mobile encryption! Unfortunately the answer really depends on which iPhone model / Android manufacturer your app will be running on. Here's a little dump of what I know. Hopefully it'll get you on the right track!

Both iOS and Android provide crypto (encryption) libraries in the OS. You should be able to google for docs pretty easily.

The hitch with any software-based encryption is going to be "where do we store the decryption key?". Obviously, storing the encrypted database in the app's storage space, then storing the decryption key in a file right next to it is kinda useless.

More and more, mobile devices are starting to have secure hardware keystore chips (often in the form of a TPM, or what Apple calls the "Secure Enclave") that will release the decryption key to the app in secure ways. They usually have lots of flexibility in terms of how / when the keys are released ("only accessible for 10 mins after device unlock", "only after password-based login", etc).

The problem is that these technologies are still very new and rapidly evolving, so not all devices support it yet, and the ones that do don't yet have a consistent API / feature set. It's worse on Android, but there's some inconsistency even between versions of Apple's Secure Enclave.

Android Marshmellow did a major overhaul of their crypto so that private keys never need to be handed to the app, all encrypt / decrypt operations can be done within the secure keystore. But Android devices < 6.0 are hit-and-miss.

If you decide to go down this route, the reality is that you will need to detect the OS version (and maybe manufacturer) at runtime and use different code based on what you find. It will probably be a large dev effort, and a pain in the butt for QA.


You must log in to answer this question.

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