OpenVPN EC frente a ED: por qué estos nombres no son una escala de fuerza

Ponga ec, ed, ecdh, ecdsa, auth y una lista de cifrados TLS uno al lado del otro en un mismo perfil y el archivo empieza a parecer un dial de fuerza con seis posiciones. Pero no lo es. Cada nombre responde a una pregunta distinta, y dos perfiles que difieren en uno de ellos no son necesariamente más fuertes o más débiles el uno que el otro. Ordenar los nombres según el trabajo que hacen lleva unos cinco minutos y evita la mayoría de las malas ediciones que la gente hace en una configuración que funciona.

El orden que sigue parte de la propia confusión y luego avanza hacia afuera, hacia las partes de un perfil que de verdad deciden qué protege su tráfico. Cada sección toma por turno una mala lectura y muestra a qué está realmente ligado el nombre.

Dos letras, dos preguntas distintas

El par que más discusión genera es EC y ED, y la discusión suele suponer que son respuestas rivales a una sola pregunta. Ni siquiera están en el mismo eje. EC describe una familia de matemáticas: la criptografía de curva elíptica, donde la seguridad viene de la dificultad de un logaritmo discreto sobre una curva y no en un cuerpo finito grande.

ED describe una forma de curva dentro de esa familia. Las curvas Twisted Edwards son una representación elegida por su velocidad y por su resistencia a varios errores de implementación, y Ed25519 es el nombre que la gente suele querer decir. La curva no es un competidor de la criptografía de curva elíptica; es una forma de escribir una curva elíptica. Leer ED como "el EC más nuevo y más fuerte" es el primer giro equivocado, y todo lo que viene después suele estar mal en la misma dirección.

Firmar e intercambiar son tareas separadas

Una vez resuelta la cuestión de la familia, los nombres restantes se reparten en dos columnas que nunca se sustituyen entre sí. Una columna firma, la otra acuerda un secreto compartido.

EdDSA y ECDSA firman ambos, pero son esquemas distintos con formatos de clave distintos, así que un certificado emitido para uno no sirve como el otro. EdDSA está definido para un conjunto pequeño de curvas; P-256 no es una de ellas, y por eso un certificado P-256 se verifica con ECDSA y nunca con Ed25519.

La columna de intercambio no tiene ningún equivalente llamado EdDH. El acuerdo efímero sobre una clave Curve25519 es X25519, y eso es ECDH con una curva concreta, exactamente igual que con P-256. Ed25519 significa estrictamente el esquema de firma, aunque el nombre se usa de forma laxa para el intercambio porque las dos curvas están relacionadas: la forma Edwards usada para firmar y la forma Montgomery usada para X25519 describen el mismo grupo subyacente.

Por qué un perfil EC no tiene archivo dh

Un archivo dh contiene parámetros generados de antemano para Diffie-Hellman de cuerpo finito, y esos parámetros existen porque un número primo grande y un generador tienen que venir de algún sitio. Un intercambio de curva elíptica no los necesita: la curva nombrada es el conjunto de parámetros, y ambos lados ya lo conocen. Esa es toda la razón por la que un perfil EC puede omitir la directiva.

Dos situaciones siguen produciendo una línea dh en un perfil que por lo demás parece moderno. La primera es un segundo escucha o un par más antiguo que negocia de verdad grupos de cuerpo finito. La segunda es texto sobrante copiado de una plantilla de la época RSA y nunca eliminado. Un perfil que nombra una curva para el intercambio y aun así carga un archivo dh de 2048 bits no es más seguro por haberlo hecho; lleva un artefacto sin usar.

TLS 1.3 quitó el intercambio de claves del nombre

Compare TLS_AES_256_GCM_SHA384 con TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384 y el nombre más corto parece una degradación. Es un cambio de nombre, y la razón es estructural: TLS 1.3 eliminó el RSA estático y el intercambio de claves Diffie-Hellman de cuerpo finito, así que un intercambio efímero de curva elíptica es la única opción sin PSK que queda. Nombrarlo en cada suite repetiría el mismo hecho una docena de veces.

El tipo de certificado desapareció del nombre por una razón relacionada. En 1.3 el certificado autentica la firma del saludo inicial, no el acuerdo de claves, así que ya no selecciona la suite. Es también por eso por lo que existe una lista de cifrados aparte para 1.3 en la configuración: las suites se renombraron y reorganizaron, no se debilitaron.

Una consecuencia merece decirse sin rodeos. ECDHE es un algoritmo de intercambio de claves y nunca un cifrado. Una suite descrita como "elíptica" dice algo sobre cómo llegaron los dos pares a una clave compartida, y nada sobre qué cifra después la carga útil.

auth autentica paquetes, no cargas útiles

La directiva auth selecciona el resumen HMAC que autentica los paquetes, y su valor predeterminado histórico es SHA1. Con un cifrado de datos que no es AEAD, OpenVPN calcula el resumen sobre el texto cifrado y lo añade, un arreglo cifrar-y-luego-MAC que es lo que hace impracticable manipular el relleno.

El mito aquí es que subir auth a SHA512 endurece el túnel. No aumenta la fuerza del cifrado, y si el cifrado de datos negociado es un modo AEAD como AES-256-GCM, el resumen no se aplica en absoluto a los paquetes de datos. La etiqueta GCM ya los autentica, y el valor auth queda para el HMAC del canal de control y para cualquier cifrado que no sea AEAD y siga en uso.

Así que la directiva importa, pero importa en un lugar más estrecho de lo que sugiere su posición en el archivo. Comprobar qué cifrado se negoció realmente le dice si se aplica o no.

Lea el perfil por columna, no por rango

Tres preguntas separan las capas con claridad, y cada una la responde una parte distinta de la sesión negociada. ¿Qué cifrado protege la carga útil? ¿Qué etiqueta o resumen responde por cada paquete, y el cifrado en uso necesita siquiera una? ¿Qué certificado cerró el saludo inicial, y el canal de control está protegido además por tls-auth o tls-crypt?

Nada en la etiqueta EC o ED resuelve ninguna de esas tres, y un nombre de suite por sí solo tampoco resuelve ninguna. El resultado negociado es la única prueba, así que léalo en lugar de inferir la fuerza del vocabulario:

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

El primer comando le dice qué esquema de firma usa realmente su certificado, que es la única forma fiable de saber si está ejecutando ECDSA o Ed25519. El segundo muestra la línea del canal de control que el cliente registró para la sesión, incluida la versión de TLS y la suite con la que se quedó. Si una edición del perfil no se puede justificar con una de esas dos salidas, probablemente sea un cambio de nombre y no de propiedad.