Cifrado simétrico frente a cifrado de clave pública en una VPN: qué hace cada uno

La gente describe una VPN como “la que usa cifrado de clave pública“ y luego imagina cada paquete cerrado con el certificado del servidor. Esa imagen es errónea de una forma que importa cuando se lee un archivo de configuración o una captura de paquetes. La mitad de clave pública de una VPN consiste en demostrar quién es el par y acordar material secreto; la mitad simétrica es la que realmente protege el tráfico, paquete tras paquete, durante toda la vida de la sesión.

Las dos mitades tienen vigencias distintas, modos de fallo distintos y cosas distintas que se pueden publicar sin riesgo. Una vez separadas, preguntas como “es RSA 2048 más débil que AES-128“ dejan de confundir, porque nunca fueron comparables.

Tres operaciones que se confunden

La criptografía de clave pública es un paraguas sobre al menos tres operaciones distintas. Una firma demuestra que el titular de una clave privada aprobó un mensaje concreto. El acuerdo de claves permite a dos pares derivar un secreto compartido a partir de valores que intercambian en público. El cifrado de clave pública oculta datos bajo la clave pública de alguien de modo que solo la clave privada pueda abrirlos.

Los saludos de VPN usan sobre todo las dos primeras. Un certificado no es una clave de cifrado; es una declaración firmada que vincula un nombre a una clave pública y permite a la otra parte decidir si confía en la clave que acaba de recibir. El establecimiento de claves de TLS 1.3, por ejemplo, se basa en el acuerdo de claves (EC)DHE más firmas de certificado, no en cifrar la sesión con la clave pública del servidor.

Qué produce realmente el saludo

En un saludo moderno, cada parte genera un par de claves efímero, intercambia las mitades públicas y calcula un secreto compartido que nunca cruza el cable. Ese secreto pasa después por una función de derivación de claves para producir claves separadas para cada dirección, además de los nonces y el material IV que necesita la capa de registro. WireGuard lo hace con su construcción basada en Noise; TLS 1.3 lo hace con HKDF sobre el transcripto del saludo.

La credencial de larga duración — certificado y clave privada, o una clave WireGuard estática — autentica ese intercambio. Firma o se mezcla en el transcripto para que un extraño no pueda completar el saludo en lugar del par. Después de eso, la credencial no realiza trabajo por paquete. Si lo hiciera, cada paquete necesitaría una operación de clave privada, y un túnel ocupado quedaría limitado por la operación más lenta de la pila.

Se siguen dos efectos secundarios. Primero, las claves de sesión son nuevas cada vez, por lo que un atacante que más tarde robe la clave de larga duración no puede descifrar sesiones grabadas antes, siempre que el acuerdo fuera efímero. Segundo, una clave de sesión filtrada compromete una sesión, no la identidad.

Por qué los datos masivos usan claves simétricas

Los cifrados simétricos manejan bien el volumen: AES-GCM o ChaCha20-Poly1305 procesan cada paquete con una clave que ya está en memoria, autentican la cabecera e incrementan un contador. El lado receptor comprueba el nonce y la etiqueta de autenticación, y descarta todo lo que falle o se repita. Eso es lo bastante barato para funcionar a velocidad de línea en hardware corriente, y la misma construcción aporta confidencialidad e integridad en una sola pasada.

La construcción es también donde viven la mayoría de los errores de implementación. Un nonce repetido en GCM rompe la confidencialidad y la autenticidad a la vez, por eso los protocolos derivan claves por dirección y mantienen un contador o una época explícitos. Si se lee una captura de paquetes y la longitud del texto cifrado coincide con el texto plano más una sobrecarga fija, es la capa simétrica la que trabaja, no una operación de clave pública por paquete.

Vigencia, renovación de claves y secreto hacia adelante

Las claves de sesión están hechas para caducar. TLS 1.3 permite un mensaje KeyUpdate para rotar las claves de tráfico; WireGuard renueva una sesión tras un tiempo o un número de mensajes configurados y mantiene brevemente la antigua para los paquetes en vuelo. OpenVPN renegocia las claves de su canal de datos según un calendario, con reneg-sec controlando el intervalo.

Ninguna de esas rotaciones es lo mismo que renovar un certificado. Un certificado puede ser válido un año mientras las claves de sesión cambian cada pocos minutos, y un certificado puede sustituirse sin tocar las claves del túnel en funcionamiento. Cuando planifique una caducidad, pregunte qué objeto está rotando; la respuesta decide si los clientes se reconectan o simplemente renuevan claves.

Leer configuraciones y diagnósticos sin mezclar objetos

En la práctica se elige un protocolo completo y sus primitivas compatibles, no se arma uno propio. La clave --tls-crypt de OpenVPN protege el canal de control; el canal de datos usa cifrados simétricos negociados. Las entradas PrivateKey y PublicKey de WireGuard son material de identidad, mientras que sus claves de transporte se derivan internamente. Leer esos campos como el mismo tipo de secreto lleva a errores como pegar una clave pública donde corresponde una privada.

Mantenga el material público separado del privado. Un certificado, una clave pública de WireGuard y una huella son seguros de compartir en un ticket. Una clave privada, una clave precompartida y una clave de sesión exportada no lo son. Cuando compare fuerzas, compare dentro de un tipo: un identificador de curva elíptica, un tamaño de módulo RSA y un tamaño de clave AES miden cosas distintas bajo supuestos distintos. La especificación de TLS 1.3 es una referencia útil sobre cómo encajan las dos capas, incluso cuando el túnel no es TLS.