Can a Diffie-Hellman key exchange algorithm be used to encrypt client-server communication on a web-page in place of SSL? If it can, what are the disadvantages (i.e. why does the standard use SSL which requires a certificate authority)? My understanding is that Diffie-Hellman can be used to secretly establish a shared key which then can be use to encrypt any further communication.
A:
A good rule of thumb to follow is to follow the open industry standard that has the most geek cred. it's for a reason.
That said, you can set up your SSL to use DH. it's an option. you can also use other key exchange algorithms.
Oren Mazor
2009-10-27 19:16:59
+5
A:
Actually Diffie-Hellman is a part of SSL. But one part does not replace others.
From here SSL Diffie-Helman is used for:
This a Diffie-Hellman key exchange in which the server's certificate contains the Diffie-Hellman public parameters signed by the certificate authority (CA). That is, the public-key certificate contains the Diffie-Hellman public-key parameters. The client provides its Diffie-Hellman public key parameters either in a certificate, if client authentication is required, or in a key exchange message. This method results in a fixed secret key between two peers, based on the Diffie-Hellman calculation using the fixed public keys.
AlexKR
2009-10-27 19:18:15
So I guess there is no way to avoid using PKI. I was just wondering out of curiosity if there was a way for 2 parties (regardless of the algorithm overhead) to reliably establish an encrypted link without use of a 3rd party.
kmnan
2009-10-27 19:23:07
In theory no. Because without ANY use of third party you cannot be sure that you are establishing encrypted link with your desired target.
AlexKR
2009-10-27 19:31:06
Sure, there is. For example if the two parties exchange their public keys during a key signing party, then they don't need any 3rd party to establish a secure connection.
Accipitridae
2009-10-27 20:44:33
More generally, a secure channel can't be established entirely in-band. Whether it's an out-of-band exchange of key material between the parties, or an out-of-band receipt of third-party keys, you need extra help to establish a secure link.
erickson
2009-11-04 00:51:07
+5
A:
The two aren't really comparable. DH is a key-exchange algorithm, nothing more and nothing less. SSL attempts to establish that the server you're connecting to is really who it says it is. To do that, it uses a certificate that can be traced back to somebody you (are supposed to be able to) trust.
DH, by itself, only keeps others from reading the transmitted data. SSL is intended to establish considerably more than that (but can use DH to keep others from reading the stream).
Just for an obvious example, using DH (by itself) a Man in the middle attack is fairly simple. If I can get you to connect to my server instead of the one you intended to, I can use DH to establish a "secure" session with you. I then connect to the server you originally intended to. Every packet I get from you, I decrypt, re-encrypt with a key I used to connect to that server, and send on to that server. I do the same with all its response packets. To you, everything looks like it came directly from the original server, and the purchase you made (for example) works just like normal. The only thing that changes is that I also store your credit card number, and when you try to fill your car with fuel the next day, the charge is declined, because in the meantime I've spent all your credit.
The authentication in SSL is at least intended to prevent that from happening. If your browser tried to connect to (for example) www.amazon.com, it should give you a warning if my SSL certificate doesn't specify that it was issued to www.amazon.com -- and a CA shouldn't issue such a certificate to anybody but Amazon.
Jerry Coffin
2009-10-27 19:28:04
+3
A:
You can use anonymous Diffie-Hellman key agreement with SSL. This provides privacy on the channel, but no authentication.
Of course, without authentication, you really can't have privacy, because your private channel could be connected to a "man-in-the-middle". That's why the anonymous DH cipher suites are discouraged.
If the lack of a certificate is stopping you from using SSL where it's really needed, get a free one from startcom.org.
erickson
2009-10-27 19:28:14
+1 - Neat link, I have been creating my own certs for my personal home server... I didn't realize there were free certs that use a CA that's built-in to the browser so visitors don't have to add an exception
John Rasch
2009-10-29 05:30:05
I don't think IE supports them, unfortunately. I haven't reviewed it lately so I'm not sure if that's still the case.
erickson
2009-10-29 13:19:42
Actually a quick check on startcom.org reveals that they do support Internet explorer.
cmaduro
2010-04-24 23:28:45
+1
A:
Diffie-Hellman key exchange is only for keyexchange. It does not give you authenticity (who you're talking to), you need certificates and a PKI for that.
So yes you can do encryption, but you dont know with who you're talking to
Henri
2009-10-27 19:29:51
+1
A:
The DH key exchange cannot, of itself, do encryption. It is used to establish a session key, but not to do the encryption. So, at this level, the question is mis-stated or reveals either lack of precision or lack of understanding (I suspect precision is the problem this time).
The question is:
- Do you want to encrypt data with anybody at all?
- Do you want to be sure who you are talking to?
As already pointed out, SSL uses a DH key exchange to establish a session password. However, it also ensures that the program on the other end is someone you trust (directly or indirectly). If you don't need to worry about whether the other person is trustworthy, you could just use a simple DH key exchange and then send encrypted data without needing certificates. But you won't be sure who you are talking to unless you validate that - and the certificates used by SSL etc helps with that validation.
Jonathan Leffler
2009-10-27 19:30:44