You should also keep in mind that it's exceedingly dangerous to "re-invent the wheel" when it comes to cryptography. Heavily peer-reviewed algorithms (which are not always the most secure) are always your best bet.
Even though SSL isn't the best overall option for 100% total security, if you go about putting another home-brewed layer over SSL, you'll only marginally increase your security, while increasing your workload by quite a lot (and give yourself a false sense of security) Another option nobody has mentioned: Perhaps install PGP/GPG on the server and email out encrypted passwords... this way, speed won't be such an issue, and you can use 3072-bit keys, which are quite secure. Of course, this would mean the client MUST have PGP/GPG installed on his computer.... :-) -- Scott Hurring Systems Programmer EAC Corporation scott (*) eac.com "Ross Fleming" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > Anders, what's wrong with SSL? It uses both the cipher suites you mention > (DES is no longer deemed "secure" by the way, 3DES is the way to go, and you > can't use DES on its own, since you need to exchange your private keys > somehow, hence they must encrypted with a public key). 3DES is faster than > RSA. > > Authentications supported by SSL: > v2 - RSA or X.509 certs > v3 - anonymous Diffie-Hellman > > Encryption supported by SSL: > v2 - 40 bit RC2, RC4 > v3 - 56 bit DES-CBC, 128 bit RC2, RC4, 3DES CBC 168-bit > > MAC supported by SSL > v2 - MD5 > v3 - SHA > > If you insist on doing it yourself, then Public Key cryptography is a good > method for a one time only (ie send the password once and your done). If > however you will be repeatedly sending encrypted data then you may find that > a combination of public key and private key may be a better bet. All public > key encryption is computationally intensive, with a combination, you can > take the SSH approach and use public key to negotiate a private key between > client & server and use this for the remainder of the session. However SSL > does all this for you. I'd therefore suggest SSL. > > Both methods allow you to not worry about the fact that it is calculated > client-side, since a good crypto suite should not be compromised simply by > having the algorithm available. In fact, for a secure connection, at least > some of the work must be done at the client end. > > Hope that helps! :) > > Cheers > > Ross > > > > -----Original Message----- > > From: Svensson, B.A.T. (HKG) [mailto:[EMAIL PROTECTED]] > > Sent: 10 June 2002 14:49 > > To: Php Win32 list > > Subject: [PHP-WIN] How to pass passwd Server <-> Client in a "secure" > > way > > > > > > Dear Mr/Miss/Mrs/Madam/Sir All, > > > > I am currently thinking of how to transport the passwd between > > the database and the client. One suggestion would be to use a > > one pad chipper, but this is pointless if I want to update > > the passwd: the key has to be distributed. So I was thinking > > of using a public key system , for example RSA (would DES take > > to long time?). > > > > But before I start all this implementation, I wonder what other > > kinds of solution other might have been using - I would prefer > > not to have scripts running on the client side, but a public > > key system force me to do this. (And I can use php, so it > > pointless to refer to any php specific methods.) > > > > //Anders > > > > -- > > PHP Windows Mailing List (http://www.php.net/) > > To unsubscribe, visit: http://www.php.net/unsub.php > > > -- PHP Windows Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
