I was thinking of implementing Diffie-Hellman on android mobile systems. In this application two sides say A and B generate keys which are later exchanged to get the common secret key.Android provides support for generating the keys but i want to know what would be the most secure to conduct the exchange. If the method used for exchange is not secure it completely defeats the purpose of using this method.
Why not use your web server as a interface, which creates the corresponding public and private key, and uses it for encryption and decryption? Make sure you even encrypt the way the keys which are sent b/w server to application are encrypted.
Related
I am developing an Android app. The app communicates with a server through a PHP API. Each user must create an account. So, the app has a login functionality. I am doing further research on how to be able to securely transfer data between client (Android app) and server. For example, a user sends, through a POST, request his username/password in order to login.
Based on what I have read, I can safely assume that in case someone “listens” the transaction between client and server he could steal the username/password combination and use it on order to login to the legitimate user’s account. Is that correct?
The solution to this problem is to encrypt the data (eg username and password) before sending them either from client or server. The data will be then decrypted by the recipient (client or server). I do that by using crypt/decrypt functions both on client (written in Java) and server (written in PHP). Each function has the same IV (initialization vector) and Secret Key (to be honest, I do not know much about the IV’s usage so forgive me if I say something wrong. I google around for information but any useful links would be really appreciated).
From what I read, the problem with this implementation is that the APK file could be decompiled from client side and get the IV and Secret Key. As a result, a listener could decrypt the data sent. Is that correct?
Trying to find a solution to this problem I have a suggestion and I would like your opinion. What if during user’s registration a unique IV and secret key are given to the each user. These values are stored both to a MySQL database (server side) and a SQLite database (client side). Whenever data needs to be sent trough a post request, the user’s id (could be something simple as an integer) and the data to be sent are encrypted using the unique IV/Secret Key for the individual user. These are stored locally so the “listener” has no access to them. Even if he decompile the APK he will just have access to his own IV/Secret Key that he already knows. Then on server side the data are decrypted using the same IV/Secret Key stored on the server. The same procedure is applied when data are sent from server to client.
Is this a correct approach?
Reusing the same symmetric key and same IV is extremely incorrect approach and must not be used ever.
Reusing the same key and IV will enable attacks where the attacker will be able to recover your secret key just be eavesdropping on the encrypted traffic for long enough. And when the attacker has your key he will be able to decrypt all and every past and future communications.
To secure the data transfer you should use HTTPS (or SSL/TLS directly if your data transfer protocol is not HTTP-based).
If your only concern is to securely communicate with the server i suggest you to install a ssl certificate to your server. Doing this way the communication will be secured by the underlying protocol. To facilitate your communication with the server for implementing ssl communication i suggest you to use aquery library, here's a link!.
Also dont forget to see the ca compatibility list for android.
Hope it helps.
This is a rather old question so i'm surprised it didn't have a more complete response. It seems you understand the concepts of symmetric encryption but you are missing knowledge of public/private key encryption. Look up RSA for a method of achieving public/private key encryption. With this, you can generate (via the assistance of a cryptographically secure RNG) new random keys as well as IVs at the start of each session to feed to your symmetric encryption system. This means that anyone listening from start to finish will not be able to make sense of your system short of brute forcing the RSA key or the symetric(AES?) key.
I am building my website in which I am facing problems with implementing encryption. I am developing it using RESTful web services in java.
I found GibberishAES API for encryption from javascript. The encrypted message now goes to web service, but I have no clue how to decrypt it in the (java) web service. I know GibberishAES is not available in java, but is there any roundabout way?
Or, are there any encryption APIs which are supported for both Java and Javascript?
I also have the issue with (symmetric) key distribution for the website. It will have 100's of client (machines, in public network) and I don't know how to communicate the unique key for a particular machine to it.
Please help me with pointers in this regard.
GibberishAES implements AES encryption. AES is a symmetric cipher, that means that both parties must know a shared key. The problem of distributing the key is not trivial, and there exist well-known algorithms for doing so.
As it was mentioned in some comments, SSL already solves that problem, because it negotiates the generation of a distributed secret key, that is later used for encryption. If for any reason you cannot use SSL, you should adopt some mechanism for secure generation or transport of the secret key. For instance, you could generate a ephimeral RSA key pair in the client, send the public key to the server, and have the server return the secret (AES) key in wrapped form.
I have a chat program that uses sockets for sending and receiving data. Now, I want to encrypt the data transfers via sockets with Diffie-Hellman key exchange system.
What is the easiest way to do that?
What is the easiest way to do that?
Use JSSE and configure to use Diffie Hellman.
JSSE is Java's socket extension for SSL. Using the SecureSocket classes which provide the same interface as regular sockets (so your current code does not need to change) but operate over SSL you can achieve encryption in your network connectivity.
You should study the link provided to see how to configure to do what you need.
I need to make two java proceses on the same host to communicate securely. I do not need to authenticate the processes so I don't want to use certificates.
I want to generate a random key in the server and client, exchange the keys between the processes using Elgamal; establish common symmetric key across the processes; and then communicate securely.
As far as I can think of, this can be done by implementing RMIServerSocketFactory and RMIClientSocketFactory interfaces to establish symmetric key as discussed above.
Is there already an implementation to do that?
Or is there a way to configure SslRMIServerSocketFactory and SslRMIClientSocketFactory to start using ElGamal as the key exchange protocol
ElGamal is preferred choice over RSA as ElGamal will generate random symmetric keys for each handshake while RSA will generate static keys every time.
I need to make two java proceses on the same host to communicate
securely. I do not need to authenticate the processes so I don't want
to use certificates.
Your reasoning is flawed from the start unfortunately. However "hardened" a communication channel is, you'll always want to make sure you're communicating with the intended party if you want to exchange data secretly. Authentication in one form or another is necessary to do so.
In theory, you can do away with certificates and use PSK cipher suites (which would effectively include the authentication step). This isn't supported by default with the Oracle/OpenJDK JRE. In addition, if you're working on the assumption that your certificate's private key would be compromised (as suggested by your other question), the same problem could happen with the pre-shared keys anyway.
A friend and me are working on a Java Game with a client/server - architecture.
It is working well, but i ran into a problem.
We use TCP Sockets for networking between server and client.
Our network protocol isnt encrypted and can just be read by anone who bothers to watch the stream.
We thought about how we could apply some kind of cryptography to it to hide login information and prevent people to write their own clients. But basic things like adding/substracting bytes seems pretty easy to figure out.
What are the usual methods used to encrypt network communication for games( or at least game login information )? And having written the server and client in java, are there any useful java libraries?
Use public-key encryption (RSA for example) and implement something like the SSL Handshake, or of course use SSL - here you can see an example.
Here's a simplified sequence:
the server sends his public RSA key to the client
the client generates a symmetric key (using AES for example)
the client encrypts the symmetric key with the server's public key and sends it to the server
the server decrypts the received symmetric key
Now both the client and the server have a key which no one eavesdropping can know. Then use that key to encrypt all data.
SSL(Secure Sockets Layer) is popular to handle this kind of problem.
Look at the javax.crypto library or bouncyCastle.
Both provide cryptographic primitives, also for encryption. Depending on how secure you want to have it, you can use symmetric or assymetric crypto. However, also think about key management in advance. Where do you store your private/shared key.
If it is a client-server, the best way would be to use assymetric crypto (i.e. RSA, Elliptic Curve) and give every user a certificate signed with the key of the server (note, this is TLS (formerly called SSL)). This way you can check if the user logging on is authentic. However, you dont prevent custom clients since the user has to have everyone can just copy the certificate.
In practice, it is quite hard to prevent custom clients.
You can use Ciphers. Some more examples here and here