5

I would like to encrypt data in my Android app. I have little experience in what the current state of encryption is, either for Android specifically or in general. I remember years ago that the US had laws that prevented software companies from exporting strong encryption technology. I'm not sure if any of that is applicable today considering that Android is open source code.

What I want to accomplish is to allow a user to encrypt data using only a password. I prefer to avoid using private/public keys because this probably requires having to enter in those two keys by the user. In my app, the user should be able to encrypt/decrypt data using a password. Their data will be sent from one mobile device to another and it should not be possible to decrypt their data on the receiving end without knowing the password. I do use SSL when sending the data but that isn't good enough because the data needs to remain encrypted on the server before it gets relayed to the receiving device. If a hacker had access to my server, they could potentially read the data. For this reason, I want to encrypt it on the sending device and only decrypt it on the receiving device.

A number of issues I need to resolve:

  1. Is there an encryption API that will let me encrypt just using a password but if not, then I'll consider using private/public keys.
  2. What are the current encryption algorithms that I can use and are they available internationally or does the US put some restriction on using them?
  3. Would I be better off creating my own custom encryption algorithm and modify it from time to time to prevent hackers from easily breaking it? Or would you discourage this? If so, why? If I change algorithm regularly, I will need to include an algorithm ID in the data in order for the decryption code to recognize whether it can decrypt that current version of the algorithm.

I'm not looking for any "extremely hard to break" algorithm but something that should be adequate. The kind of data being stored are images, videos, audio and GPS data. It would be nice if the solution worked on Android 2.2 and above. I don't see why any algorithm shouldn't work on these versions since algorithms should be independent of an OS. Nevertheless, maybe Android does use a built-in algorithm for only certain versions?

Edit:

Code I am using now for some basic internal encryption in my app looks like this, but I have my doubts it's sufficient enough:

import java.security.SecureRandom;
import javax.crypto.Cipher;
import javax.crypto.KeyGenerator;
import javax.crypto.SecretKey;
import javax.crypto.spec.SecretKeySpec;

SecretKeySpec skeySpec = new SecretKeySpec(raw, "AES");
Cipher cipher = Cipher.getInstance("AES");
cipher.init(Cipher.ENCRYPT_MODE, skeySpec);
byte[] encrypted = cipher.doFinal(clear);

Originally, the above line was:

SecureRandom.getInstance("SHA1PRNG")

but Google changed this in 4.0 and this caused my code to break. Anything encrypted with my previous code could no longer be decrypted with the default API for 4.0. I personally found that a major issue with Google because they broke compatibility. What's to stop them from repeating this again in the future? My encryption/decryption cannot be dependent upon Google's choice of breaking compatibility.

I am also forced to use 128 bit encryption because apparently support for 192 and 256 bits is not necessarily available on all devices, persumably because of local government laws.

Johann
  • 27,536
  • 39
  • 165
  • 279
  • I don't get this part: "it should not be possible to decrypt their data on the receiving end without knowing the password". Can't an attacker just do the same as the receiving end and recover the message? – Henry Feb 04 '13 at 09:57
  • Sure, a hacker could. Either the hacker first has to hack the data going over the Internet, meaning hack both the SSL and then the encrypted data as well, or they have to hack the data on my server. If they can't get past the Internet data or get access to my server, then they have to have access to the mobile device receiving the data. That is much harder to access. No encryption is 100% secure, but leaving unencrypted data on my server and relying only on SSL would be a bad mistake. Essentially I want double encryption to make it very hard to decrypt the data. – Johann Feb 04 '13 at 10:03
  • 1
    Sorry, I overlooked the "not" in that sentence, makes sense now. – Henry Feb 04 '13 at 10:28

1 Answers1

10

Is there an encryption API that will let me encrypt just using a password but if not, then I'll consider using private/public keys.

I've written an open source Java library that encrypts data with a password, using 256-bit AES. You can this find this on GitHub: JNCryptor. This is compatible with the RNCryptor project for iOS.

This may work for you on Android, or at least you can see how the code works and adapt it as necessary. (If you don't find it works as you'd like, feel free to raise an issue and I will adjust the library).

What are the current encryption algorithms that I can use and are they available internationally or does the US put some restriction on using them?

There are a myriad of algorithms available, but you will be fine if you stick something very standard, such as AES.

As far as I know, the US still forbids exporting software that uses 256-bit AES key sizes. There may be other restrictions in other countries too. But I am not a lawyer.

Would I be better off creating my own custom encryption algorithm and modify it from time to time to prevent hackers from easily breaking it? Or would you discourage this?

Do not do this. Always use a well-known algorithm that has been subjected to extensive peer review. There should be no need to regularly change your choice of algorithm, unless it has been known to be compromised.

Duncan Jones
  • 67,400
  • 29
  • 193
  • 254
  • 4
    If Java is any indicator, the restrictions are only for several jurisdictions (e.g. "terrorist states"). The use of AES 256 is certainly not forbidden, and the restrictions are only for export *from* the United States. AES-192 and AES-256 have these restrictions. Of course the restrictions are thoroughly Kafkaesque. AES1-28 cannot be broken as far as we know, and we can rest assured that those "evil" jurisdictions don't care a bit. Note: I am not a lawyer and this is not legal advice. – Maarten Bodewes Feb 05 '13 at 20:26
  • @owlstead Good comment, I've adjusted my wording regarding US export control. – Duncan Jones Feb 05 '13 at 20:36