I am implementing RSA encryption on a Android App so that I can send SMS message securely, each phone will have its own public and private key generated by the App.

But am stuck deciding the best way to store the keys, my options are:

  1. Create a keystore and hold the public and private key in the keystore.
  2. Save the public and private key to separate files.
  3. Use sharedpreferences to store keys.

I was also thinking of encrypting the private key with blowfish if just stored in a file.

Can anyone help explain to me which is the most secure option?

  • I am a bit late to the party, but I will add this for reference. "I am implementing RSA encryption on a Android App": are you using a library or implementing RSA yourself? Because the latter is a guaranteed failure in 90% of the cases. Leave the cryptography work to crypto experts, and even if you are one, think twice before reimplementing. RSA is super easy to get wrong. Jan 26, 2015 at 11:16

1 Answer 1


So here's the thing, all of the three approaches you mentioned are inherently insecure for one main reason: If/when your app gets reverse-engineered, the private key will be compromised. This is the nature of storing keys/sensitive information in apps and there's nothing you can do about that. This of course also means that if you hash the private key to a file, well now that your app is compromised reverse-hashing it will be trivial.

Now that we got that out the way, here's what you can do (in the Android context). Store the private key in SharePreferences (private mode) and use it as needed. SharedPreferences in private mode sort of translates to a separate memory space where the data cannot be accessed by the user or other apps.

Again, I need to point out that this isn't a secure way of getting this done because devices could be rooted, app reverse engineered, etc. This scheme works when you have a way to recover from a breach.

For example, if each user of your app (somehow) had a separate private key, and you find out that user X's key was compromised, well it would be a simple matter of updating X's private key from the server and you're on your way.

  • Would reverse engineering the app compromise the key (on another device)? I can't see how. Of course it's a different situation when the current owner of the device attacks the key on that very device, but that's a problem most computing devices have to live with.
    – user281377
    Feb 29, 2012 at 23:15
  • @ammoQ Of course compromising the key on one's device wouldn't really be that big of a deal if the key was unique to the device/account, sort of like a password. I guess it also depends on what else the key would be good for. I brought up the reverse-engineering bit because I've come across other people who wish to ship common private keys with their apps, which of course is asking for trouble. Feb 29, 2012 at 23:22
  • Thanks this helps, I know its never going to be 100% secure but I like the idea of using a hash (when I have 15 rep) +1 Mar 1, 2012 at 1:01
  • Marvin: in the question, it says "each phone will have its own public and private key generated by the App", that's why I'm asking
    – user281377
    Mar 1, 2012 at 7:11
  • "Reverse Hashing" ?? I thought hashes were one-way functions which couldn't* be reversed. The way to attack a hash is to find a collision and so on.. And blow-fish isn't a hashing algorithm, it's an encryption algorithm. Hashing and encryption are distinctly different in terms of cryptography!
    – Priyabrata
    Jun 25, 2015 at 2:28

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.