Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Diffie-Hellman in place of SSL?

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.

like image 242
kmnan Avatar asked Oct 27 '09 19:10

kmnan


People also ask

What is DH in SSL?

Diffie-Hellman (DH) is a key agreement algorithm, ElGamal an asymmetric encryption algorithm. Diffie-Hellman enables two parties to agree a common shared secret that can be used subsequently in a symmetric algorithm like AES.

Can we use Diffie-Hellman for encryption?

It enables the two parties who want to communicate with each other to agree on a symmetric key, a key that can be used for encrypting and decryption; note that Diffie Hellman key exchange algorithm can be used for only key exchange, not for encryption and decryption process.

Is Diffie-Hellman the same as RSA?

The RSA Algorithm can do all three: Encryption, Key Exchange, and Signatures. The Diffie-Hellman (DH) Algorithm can only be used as a Key Exchange. The Digital Signature Algorithm (DSA) can only be used for Signatures.


1 Answers

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.

DH, by itself, doesn't really even guarantee most of what I've said above. By itself, DH is just a way to exchange a key (or, perhaps it could be phrased as "exchange information necessary for both parties to create identical keys, without ever exchanging the key itself in the clear"). After both parties have the key, they can (and presumably will) use it to encrypt/decrypt data -- but that encryption is actually separate from DH itself.

like image 135
Jerry Coffin Avatar answered Sep 17 '22 10:09

Jerry Coffin