I'm writing an application which recovers statistical data about a user. I'm still pondering about what would be the best way to encrypt the data. I haven't got any experience with mobile applications. But I was thinking of hardcoding an RSA public key and encrypting it in that way before sending it over the net.

Another guy working on the project suggested AES and hardcoding the pass phrase, but that seems to be a bad approach to me as a hardcoded password might be found through decompilation of the program. (I doubt someone would do it but just in case).

Are there any other approaches which would be better suited (setting up a ssl connection is not an option unfortunately) ?

I'm also still thinking about how I could provide integrity, I was thinking of hashing the file and then zip the whole package of message + hash into one file before encrypting it. If you have a better solution please feel free to share.

  • 3
    Why is setting up an ssl connection not an option? If you are writing the app, I assume that you are in control of both the app and the server. That would be the easiest option in order to decrypt the transmitted data. You wouldn't even have to store the public key of the server in your code as it is part of the handshake. In Android, SSL is really easy to implement as pure java code can be used. By the way, using SSL the integrity issue is also solved.
    – pfust75
    Commented Feb 28, 2012 at 7:57
  • 3
    amazing how people would spend hours/days/months building their own solution, jumping through hoops to code, test and try to make it secure (and most likely do it wrong), whilst just discounting SSL as 'not an option' so quickly.
    – Yoav Aner
    Commented Feb 28, 2012 at 11:20
  • I was just wondering if there was another option than SSL, I'm quite aware of the risks of implementing your own security. That's why I basically came here to see if there are other solutions. Commented Feb 28, 2012 at 11:48

5 Answers 5


I'd just use SSL with a hardcoded public key of the server. Nobody on the way can manipulate or read what you sent. No need to invent your own protocol.

But of course the user himself can manipulate and read the data this way, but solving that is a DRM problem and not a security problem.

I believe BouncyCastle can be used for that Android. I prefer TLS 1.2 with a DHE AES128 based ciphersuite, but depending on what your server supports, you might need to downgrade to a lesser suite.

  • @BadDesign There is no secure way to protect an application from its user. You can just throw obfuscation at it. I said "nobody on the way can...", but the user of an application is not on the way, he is identical with the client in my threat model. My recommendations are only applicable to security, not to DRM. Commented Feb 28, 2013 at 8:11

Implementing your own ad-hoc-ish crypto solution is not a good idea. You'll probably get something wrong. (For instance, AES with a hardcoded passphrase is terrible. Anyone can get the passphrase by just downloading the app and extracting the passphrase. I don't know why you doubt anyone would do it.)

I recommend that you use standard, well-vetted solutions. If you have a communication channel you need to secure, use SSL/TLS. If you want to protect stored data, use GPG/PGP/OpenPGP. There are libraries and code available for both of these that should make them easy to integrate into your software.


I'd probably opt for the solution the OP mentioned, and make use of RSA and only have the public key in the application. You generally want to avoid the application being able to do both encryption and decryption (particularly with a hard coded key) because the key will eventually get out. If user input is possible, then symmetric crypto is possible as well.

Reverse engineering tools to look for well known encryption and hash functions via the sboxes in use exist, and from there it's usually pretty straightforward to extract the keys if you store them in the binary.

Just keep in mind that rsa is quite slow, which is one of the reasons most uses of it involve using it to encrypt a symmetric key which is used to do the actual cryptography.


I'm still pondering about what would be the best way to encrypt the data.

If you want to store the data on the device itself you can ask for a user password and derive a symmetric key using a key derivation function. Bcrypt and PBKDF2 are well known examples.


The best way to encrypt data is not on the client-side. By HTTP POST'ing the data via a properly-configured TLS 1.2 tunnel, one can be sure of network confidentiality. By implementing strong secure development practices (e.g. OWASP ASVS L4) along with periodic, but stringent testing (e.g. advanced application penetration-testing using Burp Suite Professional, wXf/Buby, and fuzzdb) -- one can help prevent server-side compromise, although certainly this is not limited to just development, but also secure deployment, secure operations, etc. ISO 27k programs are normally suggested for these kinds of environments.

It is not usually wise to store any data on the client-side that would represent a compromise of personal or application-critical specific information -- encrypted or not. For example, storing (or even keeping in memory for too long) active credentials to a banking application -- especially along with usernames, passwords, real names, account numbers, etc... is an absolute no-no.

You must log in to answer this question.

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