Definición (ficha de glosario): ChaCha20-Poly1305 es una construcción de cifrado autenticado con datos asociados (AEAD) que combina el cifrado de flujo ChaCha20 con el código de autenticación de mensajes Poly1305. Cifra el tráfico con una clave de 256 bits y adjunta una etiqueta de autenticación de 128 bits para que los receptores puedan detectar alteraciones en la misma operación criptográfica.

Cuando una app de VPN muestra «ChaCha20-Poly1305» junto a WireGuard o a un conjunto de cifrado TLS, está nombrando el algoritmo que realmente protege las cargas útiles de los paquetes tras el handshake. Entender ese nombre importa más que memorizar eslóganes de marketing: ChaCha20-Poly1305 no es un protocolo VPN por sí mismo, y no es un sustituto más débil de AES. Es un cifrado AEAD moderno estandarizado para protocolos IETF y ampliamente implementado en WireGuard, TLS, SSH e IPsec.
De dónde viene el nombre
Daniel J. Bernstein diseñó Poly1305 (2005) y ChaCha (2008) como primitivas de software de alta velocidad. El IETF más tarde estandarizó una combinación AEAD específica en RFC 8439 (obsoleting RFC 7539): ChaCha20 produce un flujo de clave que se combina mediante XOR con el texto en claro, y Poly1305 autentica el texto cifrado más cualquier dato asociado. La construcción aumenta el texto cifrado en una etiqueta fija de 16 bytes.
Según el resumen de Wikipedia de ChaCha20-Poly1305, el algoritmo toma una clave de 256 bits y un nonce de 96 bits, refleja la estructura de cifrar-luego-MAC familiar de AES-GCM y se usa en IPsec, SSH, TLS 1.2/1.3, DTLS y WireGuard. Esa amplitud explica por qué el mismo nombre de cifrado aparece en clientes VPN de consumo y en pasarelas empresariales.
Cómo cifra ChaCha20

ChaCha20 es un cifrado de flujo. No divide los datos en los bloques de 128 bits que usa AES. En su lugar, expande una clave, un nonce y un contador de bloques en bloques de flujo de clave de 64 bytes usando solo suma, XOR y rotación de bits a lo largo de 20 rondas. El flujo de clave se combina mediante XOR con el texto en claro para producir el texto cifrado. El descifrado es el mismo XOR con el mismo flujo de clave.
Explicación de ChaCha20 de Proton resume el punto práctico para los usuarios de VPN: ChaCha20 está diseñado para mantenerse rápido en software ordinario, lo que ayuda a teléfonos, CPU antiguas y dispositivos sin aceleración de hardware AES. AES suele ganar cuando están presentes AES-NI o las extensiones criptográficas de ARM; ChaCha20 suele ganar cuando el cifrado debe ejecutarse en software puro con propiedades de temporización consistentes.
Qué aporta Poly1305

El cifrado por sí solo no impide que un atacante invierta bits en tránsito. Poly1305 es un código de autenticación de mensajes de un solo uso que produce una etiqueta de 16 bytes sobre el texto cifrado (y los datos asociados). En la construcción AEAD de RFC 8439, el primer bloque de ChaCha20 genera una clave Poly1305 de un solo uso; los bloques posteriores cifran la carga útil. Si la etiqueta no se verifica, el paquete debe descartarse sin revelar el texto en claro.
Ese modelo de «cifrar y luego autenticar en una sola API» es lo que significa AEAD. AES-GCM hace el mismo trabajo con internos diferentes. Los analistas de seguridad tratan ChaCha20-Poly1305 y AES-256-GCM implementados correctamente como equivalentes en confidencialidad e integridad bajo supuestos estándar, siempre que los nonces nunca se repitan para una clave dada.
Por qué les importa a WireGuard y a los stacks móviles
La criptografía publicada de WireGuard fija el cifrado de transporte en ChaCha20-Poly1305. No hay un conmutador de usuario para AES dentro de WireGuard clásico. Esa decisión mantiene el protocolo pequeño y auditable: un AEAD, una familia de intercambio de claves, una superficie de configuración mínima. OpenVPN e IKEv2/IPsec pueden negociar varios cifrados, incluido ChaCha20-Poly1305 cuando las bibliotecas y los pares lo admiten, por eso el nombre del algoritmo también aparece fuera de WireGuard.
En las redes móviles y en los dispositivos con restricciones de batería, importan los cifrados favorables al software. Mediciones históricas de TLS citadas en el apéndice de rendimiento del RFC 8439 mostraron que ChaCha20-Poly1305 superaba a AES-GCM en teléfonos sin aceleración AES, mientras que AES-GCM lideraba en servidores con AES-NI. En 2026, muchos teléfonos tienen extensiones criptográficas, pero el diseño favorable al software sigue reduciendo el riesgo de implementación y mantiene un rendimiento predecible en flotas mixtas.
ChaCha20 vs AES: los compromisos que importan
- Tipo de cifrado: ChaCha20 es un cifrado de flujo; AES es un cifrado de bloque que suele ejecutarse en modo GCM para AEAD.
- Hardware: AES suele ganar en CPU con AES-NI / extensiones criptográficas; ChaCha20 suele ganar en software puro.
- Canales laterales de temporización: El diseño add-rotate-XOR de ChaCha20 se considera ampliamente más fácil de implementar sin escollos de temporización de caché que algunas rutas de software de AES basadas en tablas.
- Disciplina de nonce: Tanto GCM como ChaCha20-Poly1305 fallan de forma catastrófica si se reutiliza un par (clave, nonce). Los protocolos deben garantizar la unicidad: WireGuard usa contadores de paquetes; TLS deriva claves y nonces nuevos por registro.
- Familiaridad con el cumplimiento: Las listas de verificación empresariales siguen nombrando AES-256 con más frecuencia; eso es un hábito institucional, no una prueba de que ChaCha20-Poly1305 sea más débil cuando está estandarizado y se usa correctamente.
Lo que ChaCha20-Poly1305 no es
No es un protocolo VPN. No sustituye a WireGuard, OpenVPN ni IKEv2. No oculta que estás usando una VPN, no elige países de salida ni impone una política de no-logs. Esos son problemas de transporte, enrutamiento y confianza en el operador. ChaCha20-Poly1305 solo responde: una vez que los pares comparten una clave de sesión, ¿cómo se sellan los paquetes para que los escuchas no puedan leerlos ni alterarlos en silencio?
Tampoco es «a prueba de computación cuántica». Como AES-256-GCM, es un cifrado simétrico; la preocupación habitual de harvest-now-decrypt-later en las VPN se centra en el intercambio de claves del handshake (ECDH hoy, con despliegues híbridos de ML-KEM emergentes), no en retirar de golpe el propio ChaCha20. Trata las afirmaciones de VPN poscuánticas como declaraciones sobre handshakes y autenticación, no sobre sustituir ChaCha20 por otro cifrado de volumen.
Lista de verificación práctica para lectores
- Si tu cliente muestra WireGuard, espera ChaCha20-Poly1305 en el canal de datos por diseño.
- Si tu cliente muestra OpenVPN o IKEv2, confirma el cifrado negociado en los registros o en la configuración avanzada; ChaCha20-Poly1305 puede estar disponible junto a AES-GCM.
- No persigas adjetivos de «grado militar». Prefiere conjuntos AEAD documentados de RFC vigentes y clientes mantenidos.
- Recuerda que un AEAD sólido no puede corregir una contraseña reutilizada, una página de phishing o una filtración de DNS fuera del túnel.
En resumen: ChaCha20-Poly1305 es el caballo de batalla AEAD detrás de gran parte del tráfico VPN y HTTPS actual. Aprende la definición, conoce la regla del nonce y trata la elección de protocolo y la política del operador como preguntas distintas del nombre del cifrado de volumen en la pantalla de ajustes.