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.
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.
Related
I have an android application that has encrypted database. Now I want to change the Cipher key after certain time. So how would I convert the data with previous key to new one?
The amount of data is huge. So I would like to know if there is any efficient way to do this.
The exact answer depends on your encryption scheme, but most likely there isn't any better way than to decrypt the data using the old key, and then re-encrypt it using the new key.
Since you want to do this on a regular basis, you may want to consider breaking your data into convenient-sized chunks (record, table, etc.), and encrypt each one of those using a random key (different random key for each chunk), then encrypt those chunk keys using a single master key. To access the data you will have to first fetch and decrypt the chunk key, then use the chunk key to decrypt the actual data. You may also want to store any IVs that you use together with the chunk keys. When you want to change the master key, then you decrypt/re-encrypt the chunk keys using the new master key, but you don't have to touch the data (since the chunk key doesn't change). If you want to change a chunk key, you will have to decrypt/re-encrypt that part of the data, which may not be a problem if you are modifying that data anyway.
And don't forget that when it comes to security, be paranoid - they ARE out to get you!
Create a key indirection. That is create a top level key that encrypts the data encryption key. Then the top level key can be changed and the data encryption key does not need to be changed thus the data does not need to be decrypted and re-encrypted.
I am trying to create an Android app that encrypts data on-the-fly and write it to storage. Already implemented the app with no encryption, checked 100+ examples/posts of encryption on stackoverflow but couldn't decide which method to use.
At first thought of of using AES and did some googling to find how secure it is. Entering 16 or 32 character (better security, i hope) passwords every time doesn't seems convenient. As an alternative Asymmetric encryption came to mind. Encrypt with one key and decrypt with the other, so that i can leave the key used for encryption in the memory and use the other key only when data needs to be decrypted (like offline on a PC, or on another app).
Files that will be encrypted will be mostly images,video, audio recordings, office documents.
Does second method leaves any vulnerabilities? Between AES and RSA which one is better if i need to balance for speed and security. Data isn't anything top-secret, just need to prevent falling to wrong hands. The device is not encrypted, running KitKat. How well does both method stands against some kind of attack ?
EDIT: Describing two methods.
Method 1: Use password based AES encryption, manually enter 16/32 character password upon application start, clear the password after sometime/certain triggers from the memory. Enter password again when required.
Method 2: Use private/public key based RSA encryption. Leave one key, the one used for encryption on the device. Use the other key during decryption, which is scarcely performed.
This question is somewhat difficult to answer since you haven't actually described any methods, you've just named two encryption algorithms. If implemented properly, both algorithms are more than secure for your needs.
It is important to remember that RSA can encrypt data no longer than its key length (minus some for padding), so in most cases RSA alone is not enough.
If you are simply encrypting information on a single device and want the user in control of when it is encrypted and decrypted, e.g. with a password, you can use PBKDF2 to derive a key of x length (e.g. for AES256, 32 bytes) with a password string as input.
Don't bother using RSA if you aren't going to take advantage of its asymmetric properties. In most cases (but not all) RSA is redundant if no server or additional party is involved.
You don't describe your problem much, but if it was me, I'd use AES.
When using AES, please keep the following in mind:
Never use ECB mode.
Never use plain ASCII bytes as a key. You should use PBKDF2 or similar to derive a key, normally 100,000 rounds is good.
Always use a secure RNG to create your IV (if your cipher mode uses one, some, like CTR, use a nonce instead, but the concept is pretty much the same).
Always remember that AES does not ensure integrity. Use a MAC to detect changes in the ciphertext before decrypting.
I need some string values in my app that I don't want to hard code (one of those in the public key for network communication). So I made a encrypted version using AES algorithm. Now whenever I need the original stringm I need to use my key for decryption, so where should I store this key? It doesn't seem logical to store it as an hard coded string, and I don't want to store my key on the server. What should I do?
You can use JCA. Use its Password-Based Encryption.
This way you do not have to store your key any where.
Whenever you need to decrypt the data, type your password and you are good to go.
http://docs.oracle.com/javase/7/docs/technotes/guides/security/crypto/CryptoSpec.html#PBEEx
Note: The same salt and iteration count that are used for encryption must be used for decryption.
A good way to encrypt and decrypt stuff in your app without hardcoding pwds in the code is using PIN protection screen on the app. Doing this you can derive a final key to encrypt sensitive data and with the same key decrypt everything. Hope this idea will help you to figure out what do you have to do.
I'm creating an Android application, that at first needed to be able to transmit data to the server securely. So I thought of RSA.
I would send the public key to the user, let him do what he must, then receive back and decrypt via private. That is all fine.
But now it seems, that there should also be some sort of encryption to the other side. Meaning, there should be means of encrypting a message and sending it to the user, and allow only the specific user be able to read it.
This smells like having 2 pairs of keys, and sending public key from one pair and private key from the other to the user, and keeping the rest to the server.
I have looked at symmetric keys, but they somehow seem less secure to me.
Am I missing something, or is this common? I'm somewhat new to the whole cryptography scene.
The usual advice applies: use HTTPS, don't try to invent a secure messaging protocol. You will most likely fail. If you absolutely need to this, the usual way is to use RSA keys to encrypt symmetric session keys and encrypt your data with those. Also note that the size of data you can encrypt with an RSA key is limited by the key size (1024, 2048, etc. bits).For two way communication, each party needs to have the other party's public key. So it goes something like this:
Alice hands her public key (RSA) securely to Bob (see below)
Bob hand his public key (RSA) securely to Alice
When Bob wants to communicate with Alice, he generates a session key (say, a 256-bit AES key), then uses her public key to encrypt it.
Bob sends the encrypted session key to Alice.
Bob uses the session key (AES) to encrypt the message, and sends it to Alice.
Alice uses her private key (RSA) to decrypt the session key (AES).
Alice decrypts the message from Bob using the session key (AES).
Reverse the roles of Alice in Bob in steps 3 to 7 for communicating the other way.
But of course, if you send a public key to someone, how can they be sure that it is actually your key, not mine? If you don't hand it in person and show your photo ID, this is far from trivial.
Then, you need some way to verify that the (encrypted) message from Bob has not been modified (you can cut in half, and it will still be valid and decryptable; there are other, more sophisticated attacks, of course).
So just convince whoever you need to convince to use HTTPS or some other established protocol, and don't try to re-invent the wheel.
This smells like having 2 pairs of keys, and sending public key from one pair and private key from the other to the user, and keeping the rest to the server.
This is not how public key infrastructure works. Each of you generate your own keypairs, and exchange public keys.
Server's public key is used by client to encrypt data to server and verify signatures on messages received from server.
Server's private key is used by the server to decrypt messages from the client and to sign messages going to the client.
The reverse actions for the client's keypair are the same.
I'm creating an application that encrypts data with a key that is created each time the user logs into the app. However, there are times when data will be received via a BroadcastReceiver that needs encrypting, but the user is not logged in and so the encryption key is not available.
Security is pretty important and so using a key stored in code to encrypt the data until the user next logs in is out of the question as is storing one in the applications DB despite it being within the apps sandbox.
I've been searching through the Android docs and get hints of APIs to address this situation but have not yet come up with a definitive solution.
Anyone know of the usual solution to this problem? I expect it crops up quite a lot in software development.
Let's see...
Setup: Create an RSA keypair. Encrypt the private key. Store the public key unencrypted.
Broadcast received: Generate a random AES-128 key/IV. Encrypt the key with the RSA public key. Encrypt the payoad with the key/iv. Store the encrypted key, iv, and encrypted payload.
Login: Decrypt the private key. Use the private key to decrypt the AES key. Use the AES key to decrypt the payload.
And since this was the first idea that came to mind, I can't vouch for its security properties.
I'm also not sure what security properties you're looking for — what attacks are you attempting to defend against? Why couldn't an attacker just intercept the broadcast directly? Aren't you worried about it lingering around in other processes' memory?
Two ideas:
The BroadcastReceiver get the encrypted data, do the login by stored credentials and get the key to decrypt the data.
You BR just store the encrypted data and inform the user, so the user logs in to get the decrypted data.
I don't know what your app does, so its just a guess what could be possible...