Saturday, July 27, 2002 03:40 AM
I would rather say that there is really no need to have the channel encrypted if all you want to have is only the password. It can be done in a much simpler way. What you can do is throw a challenge (a large random number) to the client. When the user enters the password, use any message digest algorithm to encrypt (only) the password. MD5 with hashing could be a good choice, it is easily implemented and is really fast for small texts like passwords. Now send this encrypted password through the (insecure) channel. So even if someone gets hold of this encrypted password he wont be able to get back the actual cleartext password - coz it is hashed and encrypted using message digest, which means going from P->C is really easy but the other way round is very difficult (almost improbable). Now at the server end how do you validate wether the password is correct or not - you cannot decrypt the password the client has submitted (coz going from C->P is very difficult for you too). So all you need to do is pick up his actual password from the database (file? whatever) and do the same encryption algorithm using the same challenge number, and compare both the ciphertexts, if they are same you can safely assume that the password is correct.
If your aim is just to have the password securely, and not the data afterwards then the above could be a good solution. For example if the data you send after the initial login authentication is relatively not-so-imp and you dont care even if someone else gets hold of it, then you might consider only encrypting the password and then carry out the rest of the communication in cleartext. However, if you would like to have a secure communication in and out, then you might considering establishing a session key first and then using that for encryption.
Hope that gives you some ideas.