OpenVPN EC vs ED: Why the Names Are Not a Strength Ladder

Put ec, ed, ecdh, ecdsa, auth and a TLS cipher list side by side in one profile and the file starts to look like a strength dial with six positions. It is not. Each name answers a different question, and two profiles that differ in one of them are not necessarily stronger or weaker than each other. Sorting the names by the job they do takes about five minutes and prevents most of the bad edits people make to a working configuration.

The sorting below starts from the confusion itself, then works outward to the parts of a profile that actually decide what protects your traffic. Each section takes one misreading in turn and shows what the name is really attached to.

Two letters, two different questions

The pair that causes the most argument is EC and ED, and the argument usually assumes they are rival answers to one question. They are not even on the same axis. EC describes a family of mathematics: elliptic-curve cryptography, where the security comes from the difficulty of a discrete logarithm on a curve rather than in a large finite field.

ED describes a curve shape inside that family. Twisted Edwards curves are a representation chosen for speed and for resistance to several implementation mistakes, and Ed25519 is the name people usually mean. The curve is not a competitor to elliptic-curve cryptography; it is one way of writing an elliptic curve. Reading ED as "the newer, stronger EC" is the first wrong turn, and everything after it tends to be wrong in the same direction.

Signing and exchanging are separate jobs

Once the family question is settled, the remaining names split into two columns that never substitute for each other. One column signs, the other agrees on a shared secret.

EdDSA and ECDSA both sign, but they are different schemes with different key formats, so a certificate issued for one is not usable as the other. EdDSA is defined for a small set of curves; P-256 is not one of them, which is why a P-256 certificate verifies with ECDSA and never with Ed25519.

The exchange column has no equivalent called EdDH. Ephemeral agreement on a Curve25519 key is X25519, and that is ECDH with a particular curve, exactly as it is with P-256. Ed25519 strictly means the signature scheme, though the name gets used loosely for the exchange because the two curves are related: the Edwards form used for signing and the Montgomery form used for X25519 describe the same underlying group.

Why an EC profile has no dh file

A dh file contains pre-generated parameters for finite-field Diffie-Hellman, and those parameters exist because a large prime and a generator have to come from somewhere. An elliptic-curve exchange does not need them: the named curve is the parameter set, and both sides already know it. That is the whole reason an EC profile can omit the directive.

Two situations still produce a dh line in a profile that otherwise looks modern. The first is a second listener or an older peer that genuinely negotiates finite-field groups. The second is leftover text copied from an RSA-era template and never removed. A profile that names a curve for the exchange and still loads a 2048-bit dh file is not more secure for having done so; it is carrying an unused artifact.

TLS 1.3 dropped the key exchange from the name

Compare TLS_AES_256_GCM_SHA384 with TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384 and the shorter name looks like a downgrade. It is a rename, and the reason is structural: TLS 1.3 removed static RSA and finite-field Diffie-Hellman key exchange, so an ephemeral elliptic-curve exchange is the only non-PSK option left. Naming it in every suite would repeat the same fact a dozen times.

The certificate type disappeared from the name for a related reason. In 1.3 the certificate authenticates the handshake signature, not the key agreement, so it no longer selects the suite. That is also why a separate cipher list exists for 1.3 in the configuration: the suites were renamed and reorganised, not weakened.

One consequence is worth stating plainly. ECDHE is a key-exchange algorithm and never a cipher. A suite described as "elliptic" says something about how the two peers arrived at a shared key, and nothing at all about what then encrypts the payload.

auth authenticates packets, not payloads

The auth directive selects the HMAC digest that authenticates packets, and its historical default is SHA1. With a non-AEAD data cipher, OpenVPN computes the digest over the ciphertext and appends it, an encrypt-then-MAC arrangement that is what makes padding manipulation impractical.

The myth here is that raising auth to SHA512 hardens the tunnel. It does not raise the strength of the encryption, and if the negotiated data cipher is an AEAD mode such as AES-256-GCM, the digest is not applied to data packets at all. The GCM tag already authenticates them, and the auth value is left for the control-channel HMAC and for any non-AEAD cipher still in use.

So the directive matters, but it matters in a narrower place than its position in the file suggests. Checking which cipher was actually negotiated tells you whether it applies at all.

Read the profile by column, not by rank

Three questions separate the layers cleanly, and each is answered by a different part of the negotiated session. Which cipher protects the payload? Which tag or digest vouches for each packet, and does the cipher in use even require one? Whose certificate closed the handshake, and is the control channel additionally guarded by tls-auth or tls-crypt?

Nothing in the EC or ED label settles any of those three, and a suite name on its own settles none of them either. The negotiated result is the only evidence, so read that rather than inferring strength from vocabulary:

openssl x509 -in client.crt -noout -text | grep -E 'Signature Algorithm|Public Key Algorithm'
grep -i 'control channel' /var/log/openvpn.log

The first command tells you which signature scheme your certificate actually uses, which is the only reliable way to know whether you are running ECDSA or Ed25519. The second shows the control-channel line the client logged for the session, including the TLS version and the suite it settled on. If a profile edit cannot be justified by one of those two outputs, it is probably a change to a name rather than to a property.