This goes along with another thread, here: How to implement Java 256-bit AES encryption with CBC
Mainly, trying to get AES encryption on a phone using Java.
My question here is how to handle the encryption key. I don't know if I should store the key, hash the key and use that, or do a public-key-encyption scheme. I would rather have a way to not do an initial message from the server to the phone to communicate a key. I want the phone to be ready to encrypt and the server waiting for an encrypted message. To implement something like a key-sharing algorithm, I would have to modify our server application which is not very desireable. It's not impossible, but I'm going for code-reuse here =).
Are you trying to find a way to store the same key on every phone, yet prevent any attackers from getting the key and doing bad things with it? That's just not possible.
Estimate how much it could potentially cost if the key is disclosed. Then estimate the cost of understanding and implementing something like the following key agreement scheme. Choose the alternative that best serves your objectives.
Use ephemeral–static Diffie-Hellman key agreement. To intercept traffic, an attacker would have to hack a particular phone, and replace the server's public key, which is embedded in the application, with her own. That's pretty challenging, and each user has to be targeted individually, so the attack doesn't scale well.
RSA encryption would also work. It is secure and widely supported. But ephemeral Diffie-Hellman has one advantage. RSA would rely on a fixed key pair, so if an attacker eventually recovered the private key, she could decrypt any previously recorded messages.
Since the speed of the two algorithms should be comparable, I recommend Diffie-Hellman unless phones don't support it. Here's an example. (I'm sorry for the excessive length.)