DH ( Diffie-Hellman )

dhparam file # The parameters are just primes, not keys.

DH security relies on the hardness of Discrete Logarithm. For a randomly chosen prime p, that hardness increases with the size of p, using the best known algorithms. By some semi-freakish chance, it so happens that the best known algorithm for discrete logarithm has a lot in common with the best known algorithm for integer factorization (GNFS) and the same asymptotic running cost. Thus, a 1024-bit prime modulus for DH provides a security level that is very roughly equivalent to that of a 1024-bit RSA key.

If we look at the details, a 1024-bit modulus is a bit stronger than a 1024-bit RSA key, because through GNFS-for-discrete-logarithm and GNFS-for-factorization are very similar, their final step (linear algebra in a huge matrix) is harder for DL (the bottleneck is the matrix size; for factorization, matrix elements are single bits, while for DL they are integers modulo p, i.e. a thousand times bigger). To this date, RSA-1024 is still unbroken, and 1024-bit DH even more so.

Yet breaking 1024-bit DH is not completely unrealistic; it would take a non-negligible amount of dollars (billions) and the building of a dedicated, special purpose machine, and running time would still be counted in months or even years. But that is doable without invoking help from sci-fi concepts (helpful "very advanced" aliens) or theology (helpful deities). In that sense, yes, you should endeavour to use a larger modulus.

You don't want to use an oversized modulus because usage CPU cost rises quite sharply with that size (it should rise quadratically, but for some implementations it is rather cubic, i.e. 4096-bit costing 8 times more than 2048-bit). 2048 bits are fine.

An additional and quite vexing issue is that there are some widespread implementations of SSL that don't support DH modulus larger than 1024 bits. If using OpenVPN then you know that both client and server are OpenVPN, so you should not have interoperability issues.

The prime p and the generator g are not secret; they can also be shared. See this answer for details. You can perfectly generate them on some machine and use them on another. You can also set all appliances to use the same DH parameters; this implies no additional security issue.

Generation of the DH parameters with OpenSSL can take a lot of time because OpenSSL insists, for no good rational reasons, in generating so-called "safe primes", i.e. a prime p such that (p-1)/2 is also a prime. This is overkill and multiplies generation time by a huge factor (several hundreds). What is needed for DH is that p is prime and p = qr+1 for some large enough q; a 256-bit q would already be quite fine. Going to a "safe prime" (i.e. q of size 1023 bits for a 1024-bit p) does not make things safer, despite the name (this is a piece of old lore that transformed into a myth because of poor terminology).

"Safe primes" have a minor performance advantage (upon usage, not upon generation) in that they allow the use of g = 2 as generator; but that advantage is slight (it matters only for one half of the DH key exchange, and it is mostly nullified by window-based optimizations on the modular exponentiation).

If you really wanted to generate DH parameters on each appliance (which is not useful), then you could add the flag "-dsaparam" to the command-line to generate DH parameters without insisting on having "safe primes":

openssl dhparam -dsaparam -out dh2048.pem 2048

This should be vastly faster. But generating the DH parameters on a PC and simply hardcoding them in all your appliances is even simpler, and it is safe.

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 eventually acquires the private key, he can use that to decrypt the session key from SSL exchange, and then use that to decrypt the whole session. So that's not perfect forward secrecy.

The key here to Perfect Forward Secrecy is the Diffie-Hellman key exchange. DH is a very cool algorithm for generating a shared key between two parties such that an observer who sees everything -- the whole exchange between the two parties in the clear -- cannot derive the key just from what is sent over the wire. The derived secret key is used one time, never stored, never transmitted, and can never be drived ever again by anyone. In other words, perfect forward secrecy.

DH alone can't protect you because it's trivial to play man-in-the-middle as there's no identity and no authentication. So you can continue to use RSA for the authentication and just use Diffie-Hellman to generate the session key. That's DHE-RSA-*, so for example: DHE-RSA-AES128-SHA1 is a cipher spec that uses Diffie-Hellman to generate the key, RSA for authentication, AES-128 for encryption, and SHA1 for digests.

But Diffie-Hellman requires some set-up parameters to begin with. These aren't secret and can be reused; plus they take several seconds to generate. But they should be "clean", generated by you so you know they're not provided by an attacker. The dhparam step generates the DH params (mostly just a single large prime number) ahead of time, which you then store for the server to use.

An interesting bit is that Elliptic curve Diffie–Hellman is a modified Diffie-Hellman exchange which uses Elliptic curve cryptography instead of the traditional RSA-style large primes. So while I'm not sure what parameters it may need (if any), I don't think it needs the kind you're generating.

I don't have all the answers here, but I'll keep looking and update this answer when I know more.

# Perfect Forward Secrecy

**Prime-field groups (EDH):**

The server needs to be configured with a suitably-large prime and a corresponding "generator".

The acronym for forward secrecy over prime fields is EDH for Ephemeral Diffie-Hellman (also abbreviated as DHE).

**Elliptic-curve groups (EECDH):**

The server needs to be configured with a "named curve".

These offer better security at lower computational cost than prime field groups, but are not as widely implemented.

The acronym for the elliptic curve version is EECDH which is short for Ephemeral Elliptic Curve Diffie-Hellman (also abbreviated as ECDHE).

Elliptic curves used in cryptography are typically identified by a "name" that stands for a set of well-known parameter values,

and it is these "names" that are used in the TLS protocol.

# Get Ciphers support PFS

All ciphers that support forward secrecy have one of five values for the first component of their OpenSSL name: "AECDH", "ECDHE", "ADH", "EDH" or "DHE".

Ciphers that don't implement forward secrecy have names that don't start with one of these prefixes.

openssl ciphers -v \ 'aNULL:-aNULL:kEECDH:kEDH:+RC4:!eNULL:!EXPORT:!LOW:@STRENGTH' | awk '{printf "%-32s %s\n", $1, $3}'

TLS 1.3 always uses forward-secrecy.