I have an firebase application which consist of group chats.
and I want to implement end-to-end encryption.
So far I've tried to below strategy to
1) Create an secret key (AES) for group to encrypt/decrypt texts
2) Created RSA key for individual users
3) encrypting AES secret key using user's public RSA key and decrypting using private key
I want to keep the AES key on server by encryting and then, allow user to fetch that AES key thru API and use to encrypt/decrypt messages
AESKEY (encrypted) ---> (decrypt to plain text(this is the challenge - how to decrypt this on server side) ----> encrypt using public key of user) ----> send to user
The challenge I am facing is, as I have encrypted the AESKEY on Server using my public key, but when the user requests the AESKEY, my application may be offline so eventually the user will not get the decrypted AESKEY
I was thinking to keep AESKEY on server by encrypting and on user's request I perform encryption/decryption task on server itself.
It is quite unreasonable to do this, as it's a lot simpler and not less safe to only encrypt the message itself with the other parties' public key, and then they can all decrypt it themselves with their private keys.
Related
I'm in need of storing in shared preferences a bunch of sensitive information. I know using EncryptedSharedPreferences would be ideal, but given its minSDKVersion of 23, its a no-go for me.
So, I chose to implement an hybrid cryptography system.
The first time I need to encrypt some data, I randomly generate an AES secret key
Then, I create a new entry in the keystore, so that I can use its public key to encrypt that AES secret key. Then, that final secret key is saved in shared prefs
Whenever I need to access that data, I'll get the encrypted key from shared prefs, decrypt it using the private key stored in the key store and, finally, decrypt the content with the AES key that I just retrieved.
Am I doing it the right way? I'm currently not using any IV or padding in the AES encryption. I figure this system will be just as secure as the RSA algorithm I used, no matter what the AES key is (as long as it is a random one generated at run time). Am I right or missing something? Should I take the extra step of using a padding and IV alongside AES?
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.
Hi what are the various RSA 2048 key generation and secure storage methods in Android.
I have an app where I need to generate pubic-private key pair in Android and sent public key to server.The private key must be securely stored at client side.How can I ensure that the private key is securely stored ? Is there any reliable key storage mechanism available in
android ?
I've thought of using AES to encrypt private is it a good method?Should I be using a static key in source code itself or based on some user's input ?
You need to use a Key Store in your app for secure key storage. Storing keys in you source is the 'anti secure' way. http://developer.android.com/reference/java/security/KeyStore.html
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...