Por qué AES-256 no describe una suite de cifrado VPN

Pregunte qué cifrado usa una VPN y la respuesta suele llegar en una palabra: AES-256, o ChaCha20, o quizá WireGuard. Esa respuesta nombra un componente de una capa, mientras que lo que realmente protege la conexión es un conjunto de algoritmos que cubren cuatro papeles distintos. Confundir el componente con la disposición es el error más común en estas conversaciones y produce comparaciones que no se pueden resolver.

Cuatro trabajos dentro de una conexión

El cifrado masivo convierte el texto claro en texto cifrado para el canal de datos, y su clave se deriva en lugar de transmitirse. La protección de integridad detecta modificaciones, que es un trabajo aparte aunque una sola construcción haga ambas cosas. El establecimiento de claves produce el material compartido de tráfico, y la autenticación del par decide quién está al otro lado. Si falta cualquiera de ellos, la conexión no es segura, por fuerte que sea la pieza restante.

Algunos diseños funden dos papeles en uno. AES-GCM y ChaCha20-Poly1305 son construcciones de cifrado autenticado, así que la confidencialidad y la integridad llegan juntas; AES-CBC no lo es y necesita un código de autenticación de mensaje aparte con su propia clave. Por eso leer una propuesta como un saco de números independientes lee mal los que se diseñaron como parejas.

Los papeles también se sitúan en capas distintas, y por eso la misma palabra puede significar cosas diferentes en dos productos. Un cifrado de bloque dentro de ESP y un cifrado de bloque dentro de TLS son la misma primitiva en negociaciones distintas con requisitos distintos. Por eso citar una primitiva sin su modo y su capa puede ser peor que no citar nada.

Por qué el nombre de un cifrado casi no dice nada

Tome la frase AES-256 en serio un momento: identifica un cifrado de bloque y un tamaño de clave. No dice nada sobre el modo de operación, sobre si se aporta integridad, ni sobre cómo se establecieron las claves o cómo se autenticó al par. Dos productos pueden anunciar ambos AES-256 y diferir en todo lo demás, incluido uno que lo empareja con un modo no autenticado y otro que usa un modo AEAD con intercambio de claves moderno.

TLS 1.3 llevó esta separación al estándar, lo que es una corrección útil para quien aprendió el vocabulario anterior. Sus suites de cifrado solo nombran el AEAD y el hash, mientras que los grupos de intercambio de claves y los algoritmos de firma se negocian como parámetros aparte. Por eso un nombre de suite TLS 1.3 no es comparable con un nombre de suite TLS 1.2 en igualdad de condiciones, aunque ambos aparezcan en el mismo campo de un archivo de configuración. Un auditor que compara las dos cadenas directamente saca una conclusión que el protocolo no respalda. Lea también el grupo negociado y los parámetros de firma, o la comparación queda incompleta.

WireGuard elige el camino opuesto y elimina la negociación casi por completo: el protocolo fija un conjunto de algoritmos, así que dos implementaciones interoperan o no. Es una elección de diseño legítima, y también significa que la pregunta de qué suite negocia WireGuard no tiene una respuesta que merezca comparación. Si lo audita, lea la especificación una vez y después audite la gestión de claves a su alrededor en lugar de la negociación.

La capa decide el vocabulario

Un despliegue de IPsec negocia dos veces: una propuesta IKE para el canal de control y una transformación ESP para los datos, y las dos pueden diferir legítimamente. Leer la primera y suponer que describe la segunda es una fuente habitual de confusión durante una auditoría, porque el archivo de configuración menciona ambas y la interesante es la segunda.

Un nombre disponible en una biblioteca no se implementa automáticamente para otra ruta de datos. Por eso la afirmación de que nuestro producto admite AES-256 es más débil de lo que suena, y por eso un problema de interoperabilidad suele resolverse encontrando la intersección mantenida en lugar de habilitar todos los algoritmos antiguos en ambos lados.

La especificación de TLS 1.3 es el ejemplo publicado más claro de la separación, porque define la suite como una pareja y traslada el resto a su propia negociación. Una vez que esa forma resulta familiar, la propuesta de IPsec y el único conjunto fijo de WireGuard se leen como variantes de la misma idea.

Lea el resultado negociado y luego deténgase

Una propuesta configurada no es prueba de lo que eligieron dos pares. La sesión viva lleva la respuesta, y cualquier implementación habitual puede informarla sin capturar paquetes.

openssl s_client -connect vpn.example.net:443 -brief
ipsec statusall
wg show

En la salida lea los algoritmos seleccionados en lugar de la lista ofrecida. Si la respuesta es más débil de lo que pretendía la política, la corrección corresponde a la configuración de la propuesta en uno u otro lado, y una discrepancia suele aparecer en implementaciones modernas como una negociación fallida y no como una rebaja silenciosa.

Después recuerde qué no cubre la suite. Rutas, permisos de aplicaciones, registro y retención son decisiones aparte con su propia revisión, y una disposición criptográfica compatible no dice nada sobre ellas. La discusión sobre el cifrado merece la pena, pero responde a una pregunta más estrecha que la que la mayoría plantea en realidad.

Mantenga el vocabulario preciso y el argumento se acorta. Una suite es un conjunto de papeles en una capa, un cifrado es un componente, y el resultado negociado es lo único que describe la conexión que realmente tiene. Todo lo demás en la comparación es decoración.