We Keep Coding

Android – Sending/Receiving data to/from server securely

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.

Android call with encryption and decryption

How to do an encryption and decryption features in my application for a call. Is their any algorithm available for it?
Thanks in advance :)
I was sending one message that should be encrypted and reciever should reply same .when i recieve that same message it should match and gives automatic call to reciever.

Take a look at the javax.crypto documentation for Android

ActionScript3 & Java encryption / decryption

I've got a flash client that communicates with a server. The server-side code is in java. I'd like to be able to encrypt the communication, so it has to be an algorithm that has libraries for both as3 & java.
Speed if more important than the security of the encryption, and ideally it would use asymmetric key encryption.
AES and Blowfish seem like they would work from what I've seen. But both use symmetric keys.
Any ideas?

It seems like opening an HTTPS connection would be the simplest way to do this.

AS3Crypto is a port of the popular Java/C# library BouncyCastle. That works just great.

I'm going to be working with encrypting data shortly here. I've chosen to do it using asynchronous RSA encryption.
I'll be using AS3Crypto's RSA encryption client-side with the public key.
Server-side I'll be using JAVA's built-in RSA cryptography to decrypt data with the private key.

network communication encryption in java

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

How to Send Encrypted Emails Programmatically (from an automated process)

I have a process that runs on a UNIX (Solaris) server that runs nightly and needs to be able to send out encrypted emails.
I only need the "encryption" portion, NOT the digital signature / self-repudiation part of PKI.
I use MS Outlook in a corporate setting and I am assuming that when a user clicks "Publish to GAL..." under Tools -> Options -> Security, this will publish their PUBLIC KEY to the Global Address List (GAL).
So I am thinking that I need a way to connect to the Exchange Server that the GAL is on from my UNIX server.
Then I would need to retrieve the recepients PUBLIC KEY.
Then I could encrypt the email using the recepients PUBLIC KEY.
This would encrypt the email and only allow someone with the recepients PRIVATE KEY to read the email right?
Then I would send out the email.
But, what I am not sure about, is how to encrypt the email using only the recepients PUBLIC KEY (no KEYS on the UNIX side) in a way that MS Outlook will be able to read the email when the recepient receives it?
Would this work?
Anybody out there run into a similiar problem and come up with a solution?
Java code is preferred, but any langauge would do to start with.
Any additional details required in order to get a reasonable answer?
Thanks

You're logic is right.
Typical PKI encryption is:
cryptoAlgorithm(plaintext, public key) = ciphertext
cryptoAlgorithm(ciphertext, private key) = plaintext
For some algorithms, the cryptoAlgorithm is the same procedure, sending and receiving.
So... for each recipient you need their digital certificate, which will contain their public key.
GAL Certificate Storage
I would think it would be possible to configure the GAL to allow users to publish certificates. My general impression is that how the GAL is configured and used varies from company to company.
S/MIME & PGP
I agree with the post that S/MIME is what you want for Outlook.
Also note - if your users are using Outlook Web, rather than the Outlook client, they won't be able to receive encrypted emails. At least as of 2000, but I suspect 2003 as well. It's a huge usability problem and I've got no good workaround.
General Microsoftyness
Microsoft has their own special way of doing things (no kidding...). They are
no different in the world of PKI. User certificates must be clearly marked with an encryption capability. I know it must have the KeyUsage field KeyEncipherment. And there may be one other extension required by Microsoft. Having an incorrectly formatted user certificate could mean that the recipient will be unable to read the mail when it arrives, because Outlook won't agree on the fact that the mail was encrypted. Spare some serious integration testing time here and plan to hit lots of user groups on how to do this. Every time my team has had to integrate with a Microsoft product, there have been nasty surprises, particularly regarding how the certificate is configured.
Libraries & Tools
I second the recommendation for BouncyCastle - I haven't used it, but people I trust swear by it. I personally loved the Phaos toolkit when I had to write this stuff, but I'm out of date. I know it cost serious money, and may be too much bang for your buck.
OpenSSL is another fabulous tool, and useful for much more than SSL. It's great for generating test certificates, but I can't remember if it does S/MIME email encryption as well.
For most libraries, you should be able to take plaintext, and the certificate, and put both into a function that generates the S/MIME message. They may require the encryption algorithm as well.

In the general case : to send an encrypted message to someone, you only need their public key. You dont need to have a key yourself. The rule with asymetric crypto is whatever is encrypted with a public key can be decrypted with the corresponding private key, and whatever is encrypted with a private key can be decrypted with the corresponding public key.
You will need a key for your server only if you want to sign the message.
If you want to do the implementation in Java, I dont think that JavaMail supports encryption out of the box, but you can have a look at JavaMail-Crypto (havent used it myself). There is supposedly a JNI interface to GnuPG somewhere ... And you can always exec PGP or GnuPG from any language ...
I dont know about the support for PGP in Outlook, nor anything else about Outlook.

You have to send encrypted mail to Outlook in s/mime format. Outlook doesn't support PGP.
Start by trying to send a plaintext message from Java and see if you can get it into Outlook. Worry about the encryption later. Use the JavaMail library to create and send emails.
I don't know how to extract keys from the GAL. It is probably easiest to start off by exporting a key manually and see if you can work with it.
To create encrypted mails in s/mime format I recommend Bouncy Castle. Bouncy Castle is a crypto-provider that also has support for s/mime. (Look for the CMS/Smime package). There should be some examples in the downloaded sources. I've used it in the past to send emails to a wide array of email clients, including Outlook and it works pretty well. But brace yourself for the crypto stuff -- it can be a steep learning curve!

The caveat not noted previous is that the GAL isn't necessarily on the Exchange Server, and is more frequently found on the Domain server, when not run in a standalone mode. The certificate will be found in the LDAP attribute userCertificate or userSMIMECertificate.