2

I want to send sensitive data from one app to another.

I use Intent and send data via Bundle. Now, I am supposed to use an encryption algorithm to encrypt the data to send and parallelly the receiver app will decrypt the data.

Which algorithm is best suited for the mobile platform?

I have gone through RSA documents suggests that it is not suggested for long text encryption.

I have seen the algorithm uses a random key generation method which will cause an issue in my case as both the app need to share the same key to encrypt and decrypt.

Vir Rajpurohit
  • 1,869
  • 1
  • 10
  • 23
  • if both apps are yours, read about. sharedUserId where two apps share the same process id and they can share the same storage space and they can access each others sandbox. – Fahad Alotaibi Mar 11 '20 at 11:21
  • @FahadAlotaibi I kept this as an option. Using the Encryption algorithm is on the priority. – Vir Rajpurohit Mar 11 '20 at 11:22
  • you can use the RSA to encrypt the private key of the AES algorithm, then send the private key of the AES to the other app and then use the AES to encrypt the data and send it to the other app. Only use the RSA fo encrypting the AES private key. – Fahad Alotaibi Mar 11 '20 at 11:26
  • I have been advised not to use AES as it is not strong. – Vir Rajpurohit Mar 11 '20 at 12:16
  • 2
    @Vir The sharedUserId is the better option. Developing a secure encryption scheme between two apps is a hell. You can't use static RSA keys embedded into your app(s). Because they can be easily extracted and then the encryption is useless. Each app has to dynamically generate a key pair and then exchange the public key with the other app. This part is vulnerable to man-in-the-middle attacks. – Robert Mar 11 '20 at 12:16
  • @Robert `Each app has to dynamically generate a key pair and then exchange the public key with the other app` If I go this way then which algorithm to use? – Vir Rajpurohit Mar 11 '20 at 12:17
  • Every crypto algorithm is "not strong" when someone uses it who has no clue about how cryptography and security works (and therefore uses the algo in a wrong way). – Robert Mar 11 '20 at 12:17
  • @Robert Can you suggest any algorithm mechanism despite of sharedUserId mechanism? – Vir Rajpurohit Mar 11 '20 at 12:18
  • 2
    Diffie-Hellman would be an option. But any other key-agreement-protocol would also work. – Robert Mar 11 '20 at 12:19
  • @Robert It will be great help if can suggest any example of the same. – Vir Rajpurohit Mar 11 '20 at 13:16
  • 5
    This question, like many about crypto, desperately needs a description of what threats you are trying to protect against. – President James K. Polk Mar 12 '20 at 13:06
  • @PresidentJamesMoveonPolk The point is how to send data from one app to another using encryption (Decryption on receiver app) except AES. – Vir Rajpurohit Mar 12 '20 at 13:11
  • @PresidentJamesMoveonPolk In RSA it uses random key generation technique which will be different in the different app hence will create an issue. – Vir Rajpurohit Mar 12 '20 at 13:12
  • SharedUserId requires both app to be signed by same certificate. Is this true? – Vir Rajpurohit Mar 13 '20 at 02:58
  • 1
    @Robert `sharedUserID` is deprecated in API 29: https://developer.android.com/guide/topics/manifest/manifest-element.html @Vir you should state what attack is blocked by encryption assuming non-rooted device. – Morrison Chang Mar 13 '20 at 05:35
  • 1
    What threat, exactly, are you trying to stop? You should focus on verifying that the target app is what you think it is, not on trying to encrypt the data. – Ryan M Mar 13 '20 at 06:11
  • @RyanM How your suggetion would be implemented than? – Vir Rajpurohit Mar 22 '20 at 11:11
  • @MorrisonChang As stated I want to send encrupted data from one app to another but how I would share the keys? – Vir Rajpurohit Mar 22 '20 at 11:12
  • https://stackoverflow.com/a/24151683/208273 talks about that sort of thing – Ryan M Mar 22 '20 at 11:13

1 Answers1

2

I have gone through RSA documents suggests that it is not suggested for long text encryption.

true

Depending in the key length, e. g. 2048 key with pkcs#1.5 padding is intended to encrypt maximum if 245 bytes. Some implementation frameworks enforce even less (144 bytes,..)

I have seen the algorithm uses a random key generation method which will cause an issue in my case as both the app need to share the same key to encrypt and decrypt.

Actually - it's a combination of the both ways what is commonly used. see hybrid cryptosystem

Basically - each app has its own keypair and the apps share the public keys of the destination parties. You can use a random key for data encryption and rsa to encrypt the data key. Then feel safe to use Intend and Bundle to move the encrypted data and encrypted key.

It may be a good baseline to start with.

Edit:

I need to send data from my one app(A) to another(B). So, A will encrypt the data and will send the data to B with encryption (key is generated in app A).

If you send an encryption key (let's call it data key) along data in plain, anyone intercepting the traffic (intent or bundle) would be able to decrypt the data. So that's where the RSA comes into the game. You can encrypt the data key the way only B can decrypt it

Now B has to decrypt the data. If the new code of key generation will be written in app B then it will create different key and hence will not be able to decrypt....

Try to search and learn how an asymmetric cipher (RSA) works. The full description is outside scope of the question, you may ask another one what is not clear in it.

Basically - app B needs to create a keypair (public and private key). The public key is used for encryption, the private key is for decryption. A needs to get the public key of B to encrypt the data key. How you get the public key from B to A is up to you (shared storage, configure in an app, ..)

You want to pass encrypted data without sharing a common secret between apps, then RSA is a way to go.

gusto2
  • 11,210
  • 2
  • 17
  • 36
  • Suppose I have encrypted key with rsa, then destination app should have the same key to decrypt. How can that be get? – Vir Rajpurohit Mar 16 '20 at 10:20
  • @VirRajpurohit RSA is an asymmetric encryption. It means the source app has a public key of the destination app to encrypt and the destination app can uses its private key to decrypt the data key. So it's not the same key – gusto2 Mar 16 '20 at 11:24
  • I have been searching all around this. Can you refer some android/java code of the same? – Vir Rajpurohit Mar 16 '20 at 12:13
  • `It means the source app has a public key of the destination app to encrypt` How this is possible? – Vir Rajpurohit Mar 22 '20 at 11:24
  • @VirRajpurohit could you elaborate the question? Using RSA the sender needs to have a public key of the recipient upfront to encrypt. That's how it works. – gusto2 Mar 22 '20 at 18:34
  • Can I have some example showing the same to avoid this misunderstanding in communication. Please? – Vir Rajpurohit Mar 23 '20 at 03:49
  • @VirRajpurohit I have some very simple [examples](https://gusto77.wordpress.com/2017/10/30/encryption-reference-project/) for encryption code. However if you are missing some basics, you may want to open new more specific question. So far it is not clear what are you missing or what is not clear to you – gusto2 Mar 24 '20 at 14:04
  • Let me try to make it clear. I need to send data from my one app(A) to another(B). So, A will encrypt the data and will send the data to B with encryption (key is generated in app A). Now B has to decrypt the data. If the new code of key generation will be written in app B then it will create different key and hence will not be able to decrypt.... Hope I have made more clear now. – Vir Rajpurohit Mar 25 '20 at 04:07
  • @VirRajpurohit updated the answer, for details you miss you may want to open separate questions – gusto2 Mar 25 '20 at 17:47
  • Really appreciate your help. I will have to adhere to the different approach. Also link of your samples is not working. – Vir Rajpurohit Mar 30 '20 at 07:12