380

Diffie-Hellman is a way of generating a shared secret between two people in such a way that the secret can't be seen by observing the communication. That's an important distinction: You're not sharing information during the key exchange, you're creating a key together. This is particularly useful because you can use this technique to create an encryption ...


159

Diffie-Hellman is a key exchange protocol but does nothing about authentication. There is a high-level, conceptual way to see that. In the world of computer networks and cryptography, all you can see, really, are zeros and ones sent over some wires. Entities can be distinguished from each other only by the zeros and ones that they can or cannot send. Thus, ...


154

The other answers do an excellent job explaining the maths behind the key exchange. If you'd like a more pictorial representation, nothing beats the excellent paint analogy shown on the Diffie–Hellman key exchange Wikipedia entry: Image is in the public domain


142

The situation can be confused, so let's set things right. RSA is two algorithms, one for asymmetric encryption, and one for digital signatures. These are two distinct beast; although they share the same core mathematical operation and format for keys, they do different things in different ways. Diffie-Hellman is a key exchange algorithm, which is yet ...


112

If openssl uses a lot of CPU then it is not blocked waiting for "entropy". OpenSSL is actually sane in that respect, and uses a cryptographically secure PRNG to extend an initial seed into as many bits as it needs. When you use dhparam, OpenSSL not only generates DH parameters; it also wants to assert his social status by taking care to use for the modulus ...


106

TL;DR SSL/TLS client and server agree to use some weak crypto. Well, turns out that weak crypto is weak. In Detail When an SSL/TLS protocol is performed, the client sends a list of supported cipher suites, and the server chooses one. At the end of the initial handshake, some Finished messages are exchanged, and encrypted/protected with the newly ...


74

What exactly is the purpose of these DH Parameters? These parameters define how OpenSSL performs the Diffie-Hellman (DH) key-exchange. As you stated correctly they include a field prime p and a generator g. The purpose of the availability to customize these parameter is to allow everyone to use his / her own parameters for this. This can be used to prevent ...


59

Some background: Wireshark supports decryption of SSL sessions when the master secret can be calculated (which can be derived from a pre-master secret). For cipher suites using the RSA key exchange, the private RSA key can be used to decrypt the encrypted pre-master secret. For ephemeral Diffie-Hellman (DHE) cipher suites, the RSA private key is only used ...


58

Tom has provided a good explanation as to why Diffie-Hellman cannot be safe against man-in-the-middling. Now this answers the OP's original question but probably leaves some readers with the (reasonable) follow-up question: Why don't we just use public-key (asymmetric) cryptography to ensure the confidentiality of our messages, and drop D-H altogether? There ...


56

If the attacker is able to passively capture data and later gets access to the private key of the certificates (i.e. stealing, heartbleed attack or law enforcement), then the attacker could decode all previously captured data if the encryption key is only derived from the certificate itself. DH key exchange makes it possible to create a key independent from ...


51

Diffie-Hellman is used in SSL/TLS, as "ephemeral Diffie-Hellman" (the cipher suites with "DHE" in their name; see the standard). What is very rarely encountered is "static Diffie-Hellman" (cipher suites with "DH" in their name, but neither "DHE" or "DH_anon"): these cipher suites require that the server owns a certificate with a DH public key in it, which is ...


43

I too have tried to come up with a good solution for this. But I found https://onetimesecret.com/ which works great. Basically you create a link containing a password and you send this link to the intended recipient. As soon as the receiver clicks on the link, the link expires and the password is deleted. So the receiver only has one time to copy the ...


39

The weakdh.org Web site is about the Logjam attack. Contrary to what the Web site name may suggest to the unwary, this is not about DH being weak; it is more about doing things weakly when using DH. Diffie-Hellman works in a multiplicative subgroup of integers modulo a given prime p. To do some DH, you use some DH parameters which are: p : a big prime, ...


37

The traditional RSA-based exchange in SSL is nice in that a random session key is generated and transmitted using asymmetric encryption, so only the owner of the private key can read it. This means that the conversation cannot be decrypted by anyone unless they have the certificate's private key. But if a third party saves the encrypted traffic and ...


34

RSA is two algorithms, one for asymmetric encryption, the other one for digital signatures. They use the same kind of keys, they share the same core operation, and they are both called "RSA". Diffie-Hellman is a key exchange algorithm; you can view it as a kind of asymmetric encryption algorithm where you do not get to choose what you encrypt. This is fine ...


33

If you want a simpler plain English explanation of DH that can be readily understood by even non-technical people, there is the double locked box analogy. Alice puts a secret in a box and locks it with a padlock that she has the only key to open. She then ships the box to Bob. Bob receives the box, puts a second padlock that only he has the key to on it, ...


32

If you talk to 1000 persons and use pre-shared symmetric keys, then you have to remember 1000 secret keys. Secret key storage can be hard. With asymmetric encryption you just have to remember only public keys, and that is easy because public keys are public, so they can be "remembered" by being published somewhere, where everybody can see them. Moreover, ...


29

The host key is used to sign the Diffie-Hellman parameters. It is used during the key exchange; RSA is a signature algorithm as well as an encryption algorithm. From what I can tell, the client key (in authorized_keys) is not used in key exchange at all; it's only used after key exchange to sign a particular message and prove the client has the private key (...


29

Logjam shouldn't really be called a "new" vulnerability - it's a rehash of FREAK which targets export-grade DH rather than export-grade RSA. Practical exploitation relies on the following flaws: The TLS protocol is vulnerable to having its key exchange protocol downgraded by an attacker. Servers are still supporting export-grade Diffie-Hellman (e.g. 512-...


28

Asymmetric Cryptography There are two different parts to creating a TLS session. There is the asymmetric cryptography, portion which is an exchange of public keys between two points. Which is what you saw in your Alice and Bob example. This only allows the exchange of asymmetric keys for asymmetric encryption/decryption. This is the ECDHE portion. The ...


26

The key exchange problem A secure connection requires the exchange of keys. But the keys themselves would need to be transfered on a secure connection. There are two possible solution: exchange the key by physically meeting and sharing the keys. Somehow established a shared secret on a public unsecure channel. This is easier said than done, and the first ...


25

For SSL, there is SSL 3.0, TLS 1.0, TLS 1.1 and TLS 1.2. In SSL 3.0, an internal Pseudorandom Function (PRF) is used to extend the shared secret (obtained from the key exchange mechanism) into symmetric keys for the subsequent symmetric encryption. This PRF always uses both MD5 and SHA-1. In TLS 1.0 and TLS 1.1, the PRF is replaced by a new construction, ...


25

I think you're underestimating the value of contacting someone you've never talked to before, and you're overestimating the complexity of a public-key system. Any time you want to contact someone new using symmetric encryption, you have to "tell them [the shared key] in person, read it over the phone, use One Time Secret," etc. You have to contact the ...


23

First let's be sure that we talk about the same thing. In SSL, there are "ephemeral DH cipher suites" (DHE) and "non-ephemeral DH cipher suites" (DH). With DHE, the server private key (the permanent one, the one which is stored in a file, and whose public key is in the server certificate) is of type RSA (DHE_RSA cipher suites) or DSS (DHE_DSS cipher suites),...


21

Diffie-Hellman works in a subgroup of integers modulo a prime p. Namely, you have a generator g, which is a conventional integer modulo p. That generator has an order r which is the smallest positive integer such that gr = 1 mod p. The two systems who engage in DH choose private keys a and b respectively as integers in a given range, and the corresponding DH ...


20

DH ephemeral key exchange provides perfect forward secrecy, which RSA alone does not. This means that even if the long-term key is leaked at a later date, the session keys for individual connections are not compromised, even if the full data stream is captured.


20

Note: as of OpenSSL 1.1.1 (unreleased), it will be possible to set a callback function that receives the key log lines. See the SSL_CTX_set_keylog_callback(3) manual for details. This can be injected as usual using a debugger or a LD_PRELOAD hook. Read on if you are stuck with an older OpenSSL version. For a walkthrough of the LD_PRELOAD approach for Apache ...


20

Do the smoke test: (stolen from OpenSSL blog. (Archived here.)) openssl s_client -connect www.example.com:443 -cipher "EDH" | grep "Server Temp Key" The key should be at least 2048 bits to offer a comfortable security margin comparable to RSA-2048. Connections with keys shorter than 1024 bits may already be in trouble today. (Note: you need OpenSSL 1.0.2....


20

DH is a key exchange algorithm, it is used to derive the session key that's later used in the symmetric encryption. DH by itself is not authenticated, so while you can derive the session key without a MITM being intercepted, there's no guarantee that the guy on the other end that you're deriving keys together with is whoever they say they are. Not being able ...


Only top voted, non community-wiki answers of a minimum length are eligible