This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
I have to write a Login module which will accept encrypted password, but the service which will invoke this is in .Net. How do I generate they key and share with the consumer/ .Net developer. So the encryption and decryption will be seamless.
1) Does the .NET side already exist or are you going to write it?
2) It is relatively easy to create a shared secret between two parties using Diffe-Hellman key exchange (http://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange ). The difficulty is in proving that each end of the connection is who they say they are. What are the requirements for this authentication?
3) Encrypting passwords is usually not a good idea but much depends on why you are doing it. Why are you encrypting the password? What is the purpose of the password?
The industry standard for secure communication between two parties is SSL/TLS ( http://en.wikipedia.org/wiki/Transport_Layer_Security ) which provides for both secure communication and authentication. SSL/TLS is available for both Java and .NET . Data transfer through an SSL/TLS channel is encrypted so there is normally no need for explicit encryption of the password.
Debopam Poddar wrote:My requirement is .Net program will encrypt the String and Java program will decrypt the encrypted String. How to achieve this?
Your original post indicated that this String is actually a password and I am uncomfortable with the implications. The code to perform simple encryption is straight forwards in both .NET and Java but as you are obviously aware the problem is in sharing the keys. It is not sufficient to just share keys though this can easily be achieved using DH. Since you feel the need to encrypt the password the implication is that the channel along which the information is being sent can be observed by a third party. This in turn implies that it could be possible for a malicious third party to intercept the channel and perform a man-in-the-middle attack.The leads to the more difficult problem of each side authenticating the other and DH alone does not address this.
On the surface it seems likely that SSL/TLS will solve your problem since it has mechanisms for both authentication and key exchange built in. BUT - the devil is in the detail and you have given no detail.
Of course one side could just simply write the key to a floppy, CD or memory stick and deliver it by hand to the other side.