AES-GCM o ChaCha20-Poly1305: elegir el cifrado de datos de una VPN

Ambos nombres son construcciones AEAD, ambos están normalizados, y en un servidor x86 actual cualquiera de los dos saturará un enlace de gigabit sin esfuerzo visible. La elección deja de ser arbitraria cuando sales de ese servidor: los routers baratos, los teléfonos antiguos y los dispositivos virtuales a menudo carecen de aceleración AES, y allí la diferencia es grande. Así que la comparación no es qué cifrado es más rápido, sino qué cifrado funciona bien en este conjunto de extremos y si el protocolo siquiera ofrece una elección.

El mismo trabajo, núcleos distintos

Ambas construcciones dan confidencialidad e integridad en una sola pasada y autentican los datos asociados, y por eso los protocolos VPN las usan para el canal de datos. La diferencia está dentro: AES-GCM es el cifrado de bloques AES en modo contador con un autenticador polinómico sobre GF(2^128), mientras que ChaCha20-Poly1305 es un cifrado de flujo con clave de 256 bits y un autenticador de un solo uso separado.

Lo que importa en operación es común: ambos fallan de forma catastrófica al reutilizar el nonce, ambos necesitan gestionar el espacio de nonce por clave, y ninguno arregla a un par que autentica lo incorrecto. Un perfil que dice AES-256-GCM no es más seguro que uno que dice CHACHA20-POLY1305; ambos son fuertes cuando la implementación es correcta.

Dónde gana AES-GCM

AES tiene instrucciones dedicadas en la mayoría de las CPU modernas: AES-NI en x86, las extensiones criptográficas en ARMv8 y equivalentes en los diseños recientes de POWER y RISC-V. Cuando están presentes, GCM ejecuta varios bloques en paralelo por clase de ciclo y la implementación de software resulta irrelevante. Es el caso habitual en servidores, equipos de escritorio y teléfonos actuales, y por eso el consejo de usar AES es un valor por defecto razonable en un centro de datos.

El problema es el caso de segundo orden. Sin instrucciones dedicadas, AES en software es lento, y las implementaciones de software basadas en tablas son las que tienen un largo historial de problemas de tiempo de caché. Un concentrador VPN en una máquina virtual cuyo anfitrión no expone las banderas AES al invitado es exactamente este caso, y es fácil pasarlo por alto porque la CPU del anfitrión sí tiene la función.

Comprueba lo que el proceso ve realmente, no lo que la CPU admite: grep -o aes /proc/cpuinfo | head -1 en Linux, o la bandera de función equivalente en el modelo de CPU del hipervisor.

Dónde gana ChaCha20-Poly1305

ChaCha20 es rápido en software portátil porque solo usa suma, rotación y XOR, y sus implementaciones evitan por diseño las búsquedas en tablas dependientes del secreto. En un dispositivo sin aceleración AES eso es una ventaja material, y es la razón por la que WireGuard lo eligió: la descripción del protocolo WireGuard enumera ChaCha20-Poly1305 como su cifrado de datos sin alternativa.

Esa única decisión dice algo útil: en hardware donde AES está acelerado, WireGuard cede algo de rendimiento frente a AES-GCM, y sus autores lo aceptaron a cambio de un comportamiento predecible en teléfonos, routers domésticos y anfitriones de contenedores. Si tu flota es sobre todo cajas ARM pequeñas, ese intercambio te favorece.

El caso contrario es un concentrador x86 ocupado, donde AES-GCM con AES-NI es la ruta más rápida y mejor soportada, y donde ChaCha20 cuesta CPU medible por gigabit. Ninguna de las dos construcciones es una debilidad; la cuestión es cuál ejecuta barata tu hardware.

Qué te deja elegir realmente tu protocolo

Fíjate en la separación en OpenVPN: el canal de control y el canal de datos se negocian por separado, así que el conjunto que ves para TLS no dice nada sobre el cifrado que protege tu carga. El resumen de la sesión informa de ambos, y leer solo uno de los dos es una fuente habitual de confusión.

En OpenVPN el cifrado del canal de datos viene de la lista data-ciphers en ambos extremos. Si la lista del servidor y la del cliente no se cruzan, la conexión o recurre a lo que permite data-ciphers-fallback o falla del todo, y ese fallo suele atribuirse a la capa equivocada. Pon la misma lista en ambos lados y luego confirma el resultado negociado en el registro en lugar de suponer que se respetó el orden de la lista.

Decide a partir de tres hechos sobre el despliegue

Primero, ¿tienen los extremos aceleración AES? Si la tiene cada par, AES-GCM es la opción más barata y el valor por defecto en la mayoría de las configuraciones mantenidas. Si una parte significativa son routers pequeños o teléfonos antiguos, ChaCha20-Poly1305 evita que la cola de la flota se convierta en el límite de capacidad.

Segundo, ¿ofrece el protocolo alguna elección? Con WireGuard la decisión ya está tomada por ti, y el trabajo útil es verificar que las herramientas que lo rodean no sustituyan algo más en silencio. Con OpenVPN e IPsec, la respuesta es una línea de configuración y un resultado negociado que registrar.

Tercero, ¿pueden ponerse de acuerdo ambos extremos? Un cifrado que un par no implementa no es una decisión de rendimiento, es una caída. Por eso la lista de pares importa más que cualquier referencia: una flota mixta necesita la intersección de capacidades, no la preferencia de la máquina más rápida.

Si mides, mantén idénticos el dispositivo, el extremo y la carga y cambia una sola cosa. Una prueba que compara dos servidores en regiones distintas mide la ruta, no el cifrado, y una referencia en un portátil no dice nada sobre un anfitrión de contenedores cuyas banderas de CPU están enmascaradas. Compara, y luego anota qué cifrado se negoció realmente: ese registro vale más que la referencia.