I'm implementing a mobile app which uses AES encryption algorithm to encrypt some critical values being sent to a remote server (basically, the user password), and then decrypted on the server side using the same private key. This works perfectly now, but I'm a bit concerned about how to store/get the private key.

Currently, I've splitted the private key (which is hardcoded) into 3 string objects, and when needed, I concatenate them. I'm afraid this is not a valid solution, though, as any malicious user could simply decode the binary and with a bit of patience get the three parts.

The questions are:

  • What would be a good approach which at least would make it difficult to the attacker to know the private key?

  • Would help using a private key based on an event (for example, the current date) instead of storing it?

  • If I understand keyed encryption correctly, don't you want to encrypt the data with the server's public key, and then you can decrypt it on the server with the server's private key?
    – apnorton
    Mar 10, 2014 at 22:00
  • Being this a symmetric algorithm, I believe there's just one key on both sides. When I encrypt it on the client side, I don't have a public key, just the private, which has to be the same on both sites. I wonder if this is the correct way of doing it, but for what I've found over the net all implementations are very similar to this
    – nKn
    Mar 10, 2014 at 22:07
  • Ah! Ok--you're probably right. I was assuming that AES worked similarly to RSA, which, evidently, is a very bad assumption. :)
    – apnorton
    Mar 10, 2014 at 22:13

1 Answer 1


Instead of building your own AES solution, look at TLS/SSL to encrypt the password being sent to the server. If you build your own solution as you propose, anyone who cracks your app will be able to read all your users' passwords (and if it secures actual money, people will try to crack it.) TLS securely exchanges keys with the server as a part of the protocol, resulting in a communication channel that is very resistant to eavesdropping.

If you have some actual reason to encrypt data locally with AES (not involving communication to the server), then if you're building your app for iOS you should be using Apple's keychain API. I'm not sure what the Android equivalent is, but I believe there is one. This uses OS level support to hide your secret data. It's still vulnerable to hacking, but as you can make it random per user, at least a break on one mobile device won't compromise the security of all your users.

If you don't have OS support for storing a key, then you're ultimately stuck with an obscuration solution. Personally, I'd XOR several values to build the key instead of concatenating fragments of a string, but if someone's going to debug the app and discover it, they're going to discover it regardless. That means you shouldn't use this to protect any secret regarding the customer's money, accounts, finance, health, credit, retirement, or other records that should be properly secured. In other words, this might be fine for a game that doesn't involve the customers' wallet (or your wallet, for that matter.)

  • Currently this app is made just for Android, I'm not sure if there's some API to this but I'll for sure take a look at it. Thanks for the complete answer!
    – nKn
    Mar 10, 2014 at 22:25

You must log in to answer this question.

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