4

I have an Android application that communicates with my own server. Since we don't have https, I want to implement my own data encryption. The server is implemented in PHP.

I wanted to use AES, but my main problem is sharing the server key with the local application, since it could be intercepted and then anyone could decrypt my messages.

Should I use RSA instead? or there is a secure way of sharing the key?

Thanks!

Improve this question
5
  • 2
    I don't think you're doing yourselves a favour here; why is https not an option? Commented Jan 31, 2013 at 8:54
  • Actually I'm not sure, it's a restriction applied by my boss. I think it has something to do with the domain provider. I'll try to discover why we can't use it. Commented Jan 31, 2013 at 9:01
  • If you really can't use https (in a business scenario... umm...) then of course an asymmetric encryption method is definitely to be preferred. Plus, if you can't find a strem cipher, you'll have to first encrypt the whole message body, which is a slowdown as compared to https, where chunks can be transferred over the encrypted channel. Commented Jan 31, 2013 at 9:13
  • It depends on what kind of data will you transfer. If you want to encrypt fixed size data blocks, that is less than RSA key length, it is relatively easy. If you want to encrypt variable lengths bigger than RSA keys, it would be slow and you have to implement somehow streaming. In that case, I recommend using SSL library instead. If your application is Android only, try to use Java interface to HTTP, it has https support enabled. Commented Jan 31, 2013 at 9:20
  • SSL uses RSA to exchange symmetric keys and then encrypts data with symmetric keys, that is much faster. But I suggest to ask your boss what limitations prevents HTTPS. Commented Jan 31, 2013 at 9:24

2 Answers 2

Reset to default
3

You should use RSA and AES encrypting protocols.

  • RSA encrypts/decrypts short strings (it is heavy for CPU).
  • AES encrypts/decrypts large strings (it is faster than RSA).

So:

  1. the client creates a random AES key for each request (24 bytes is fine);
  2. the client encrypts the string request (any length) with the AES key;
  3. the client encrypts the AES key using RSA PUBLIC key;
  4. the client sends both encrypted (AES and string) to the server (POST is nice);
  5. the server decrypts the AES key with RSA PRIVATE key;
  6. the server decrypts the string with the AES key;
  7. the server processes the string request;
  8. the server encrypts the response string with the same AES key;
  9. the server response returns to the client;
  10. the client decrypts the response with the AES key.

Have a look at the following Open Source project at GitHub: github.com/rcbarioni/followzup

The server is implemented with PHP and there are APIs for PHP and Java. The communication between client and server uses AES and RSA.

PHP and Java encryption libraries are full compatible. Java for Android is compatible too.

Improve this answer
Sign up to request clarification or add additional context in comments.

1 Comment

What's your affiliation with Followzup? You must disclose your connection with the product you are recommending. See cs.stackexchange.com/help/promotion.
0

Well, i would do one of the following - with decreasing priority:

  • Tell your boss that HTTPS is the way to go.
  • Use an SSL library like openSSL
  • Use AES for the message and RSA for the exchange of the session's AES key

The last one is the least preferrable since there are a lot of things, you could do wrong, and thus accidentally break security. Just one example: If you happen to use both encryption and compression, you're vulnerable to the CRIME attack...

Improve this answer

Comments

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.