Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question
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. – Stefano Sanfilippo Jan 26 '15 at 11:16
up vote 1 down vote accepted

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.

share|improve this answer
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 '12 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. – Marvin Pinto Feb 29 '12 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 – RichardCypher Mar 1 '12 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 '12 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 '15 at 2:28

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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