AES-256 vs ChaCha20 en 2026: ¿qué cifrado es más rápido y seguro para VPN en PC y smartphone?

Introducción: ¿por qué comparar AES-256 y ChaCha20 para VPN?

Contexto 2026: velocidad, privacidad y realidad de nuestras redes

Vivimos en una época en la que la VPN dejó de ser “algo solo para informáticos” y se ha convertido en una herramienta diaria. Portátiles de trabajo, routers domésticos, smartphones, tablets e incluso consolas — todos enfrentan el mismo reto: cómo exprimir al máximo velocidad y estabilidad sin sacrificar seguridad. En 2026, cuando las tarifas domésticas de 1-2 Gbps ya no sorprenden a nadie y las redes móviles 5G y Wi-Fi 6/7 alcanzan velocidades estratosféricas, los cuellos de botella suelen estar no en el proveedor ni en el router, sino dentro del cifrado. Por eso la pregunta “AES-256 vs ChaCha20 — ¿qué es mejor para VPN?” no es académica, sino absolutamente práctica. Compararemos estos dos algoritmos líderes basándonos en tendencias actuales, rendimiento real en PC y móviles, consumo energético, aceleradores de hardware y, por supuesto, las particularidades de protocolos VPN — WireGuard, OpenVPN, IKEv2/IPsec. Al final obtendrás recomendaciones claras y sin relleno.

¿Dónde se integran exactamente los cifrados en el stack VPN?

Vale la pena recordar dónde se ubican estos algoritmos. AES-256 suele usarse en modos AES-GCM o AES-CBC (en configuraciones nuevas, específicamente AES-GCM como modo AEAD moderno con autenticación). ChaCha20 casi siempre se combina con Poly1305 formándose ChaCha20-Poly1305, también AEAD. En TLS 1.3 para HTTPS y QUIC (HTTP/3) ambos conjuntos de cifrados son estándar — AES-GCM y ChaCha20-Poly1305; en OpenVPN están disponibles ambos; en IKEv2/IPsec domina AES-GCM, aunque el soporte a ChaCha20-Poly1305 existe y se debate más. WireGuard, en cambio, usa incondicionalmente ChaCha20-Poly1305: ahí no hay opción — y es parte de su velocidad y sencillez. De ahí el punto práctico: si usas WireGuard, en realidad usas ChaCha20; si usas OpenVPN o IKEv2/IPsec, la elección es posible y afecta al resultado.

Block cipher vs stream cipher: diferencia de “filosofía”

AES es un cifrado por bloques. Opera con bloques de 128 bits y el modo de cifrado (GCM, CBC, etc.) define cómo se enlazan esos bloques y cómo se asegura la autenticación. ChaCha20 es un cifrado por flujo del tipo ARX (sumar-rotar-xor), genera una corriente pseudoaleatoria que se suma a los datos originales. ¿Qué nos da esto en la práctica? A veces una ganancia notable en velocidad en procesadores sin aceleración AES por hardware, además de resistencia a ciertos ataques por canales laterales. AES-256 tiene una ventaja: instrucciones hardware (AES-NI en x86, extensiones Crypto en ARMv8) que convierten matemáticas complejas en microinstrucciones ultrarrápidas. Por eso en desktops y servidores modernos AES-256-GCM suele ser más rápido que ChaCha20, pero en móviles y routers económicos sucede lo contrario. Nada de magia, solo ingeniería sólida.

Origen y estándares: en quién confiar y qué seguir

AES-256: orgullo de la estandarización y elección corporativa

AES fue elegido por NIST como estándar (FIPS-197) a principios de los 2000 y luego recibió amplio apoyo en industria y sector público. AES-256 tiene una larga historia de auditorías, certificaciones y uso práctico. Hoy, en 2026, la mayoría de reguladores y estándares apoyan AES, especialmente bajo FIPS 140-3: módulos criptográficos certificados en AES-GCM están muy extendidos y bien soportados. No son solo papeles: estas certificaciones abren puertas a grandes licitaciones, infraestructura bancaria, sector público. Sí, teóricamente AES-256 es más pesado que AES-128, pero en CPUs modernas con AES-NI la diferencia de velocidad es mínima y el riesgo organizativo menor. Para VPN corporativas eso pesa mucho y no vamos a disfrazar la realidad.

ChaCha20-Poly1305: clásico moderno hecho para la velocidad

ChaCha20 es un descendiente de Salsa20, mejorado por Daniel Bernstein y adoptado por IETF para TLS e IPsec (p. ej. RFC 7539 para TLS). Su idea principal es velocidad impresionante y facilidad de implementación en dispositivos sin AES hardware. Por eso Google promocionó masivamente ChaCha20-Poly1305 en Chrome móvil, y WireGuard lo usa como núcleo. Hoy vemos soporte para ChaCha20-Poly1305 en todas partes — desde SoCs móviles hasta computadoras de placa única y routers con OpenWrt; ambientes de nube y contenedores lo prefieren por su rendimiento predecible en CPUs virtualizados sin AES-NI. Honestamente: en 2026 ChaCha20 ya no es una “alternativa”, sino un estándar de facto en stacks VPN modernos donde la simplicidad y velocidad importan.

Compliance y regulación: dónde hay vía directa y dónde es un reto

Si trabajas bajo normativas estrictas — sector bancario, instituciones públicas, infra crítica — AES-GCM suele ser la única opción “segura y aprobada”. Sí, existen implementaciones ChaCha20-Poly1305 auditadas internamente y en algunas jurisdicciones se acepta ChaCha20 sin problemas. Pero un módulo FIPS con AES es un camino más corto a producción. ¿Qué hacer? Recomendación terrenal: si el cumplimiento es prioridad, usa AES-256-GCM (o AES-128-GCM si quieres más velocidad y suficiente seguridad); si eres startup, SaaS, servicio multimedia o desarrollador sin regulación rígida, ChaCha20-Poly1305 te brindará velocidad y simplicidad, especialmente en móviles y contenedores. Idealmente, soporta ambos y elige dinámicamente.

Rendimiento: quién es más rápido y en qué escenarios

Desktops y servidores x86/x64: poder de AES-NI y altas frecuencias

En procesadores Intel y AMD modernos con AES-NI, AES-256-GCM muestra velocidades muy altas. En OpenVPN, bien configurado y multihilo, se llegan a gigabits por núcleo. En IKEv2/IPsec con módulos de kernel activados y offload en tarjetas de red cuando está disponible, logranse líneas de 1-10 Gbps sin sobrecargar CPU. ChaCha20-Poly1305 en WireGuard también impresiona, alcanzando 1–5 Gbps en sistemas multihilo, pero en x86 con AES-NI fuerte AES-GCM suele ser ganador, si nada más cambia. ¿Excepciones? Sí, en entornos muy virtualizados donde el sistema huésped no tiene acceso completo a instrucciones AES o con frecuencias limitadas, ChaCha20 destaca por su implementación óptima y predecible. Pero en hardware bare-metal AES-NI es bestial.

ARM y SoCs móviles: ChaCha20 a menudo adelante, pero no siempre

En smartphones y tablets sin potente aceleración AES o con controladores deficientes, ChaCha20-Poly1305 supera consistentemente a AES-GCM. Menor latencia, menor calentamiento, velocidad estable con señal 5G débil. Sin embargo, desde ARMv8 con extensiones Crypto la cosa cambia: muchos chips 2021–2026 tienen buena aceleración AES hardware. Ahí AES-GCM alcanza a ChaCha20, y a veces lo supera en sesiones breves. Practicamos velocidades de 400–900 Mbps en WireGuard en flagships y 200–500 Mbps en OpenVPN con AES-GCM bien configurado. Conclusión: en Android de gama media ChaCha20 sigue ganando, en flagships la diferencia se nivela, en dispositivos básicos ChaCha20 casi siempre lidera.

Routers, placas únicas, IoT: cuellos de botella y optimizaciones sorprendentes

Routers con OpenWrt y placas ARM suelen ser campo de batalla entre AES y ChaCha. Si tu chip tiene acelerador hardware para AES (p. ej. Qualcomm, Broadcom, Marvell), AES-GCM puede volar a cientos de Mbps, liberando CPU para routing y firewall. Sin aceleración, ChaCha20 suele ganar: el algoritmo ARX encaja en NEON y cachea bien. En escenarios IoT, donde cada miliwatt importa, ChaCha20 es un aliado fiel. Pero ojo con drivers: a veces un acelerador potencial no está disponible en Linux por limitaciones, y el campeón práctico es ChaCha20-Poly1305, aunque inicialmente se prefiriera AES.

Seguridad: la teoría es fuerte, pero la práctica manda

Fuerza criptográfica: ambos cifrados son confiables

Tanto AES-256-GCM como ChaCha20-Poly1305 son construcciones AEAD modernas y fiables. Romperlos por fuerza bruta es irreal. La diferencia de riesgos está en implementaciones y detalles circundantes. GCM es muy sensible a reutilización de nonce: una repetición y adiós confidencialidad e integridad. ChaCha20-Poly1305 también requiere nonce único, pero suele tener menos fallos por simplicidad del código y ausencia de tablas preestablecidas. A pesar de eso, en 2026 ambos siguen siendo estándar de oro. No elijas cifrado basado en mitos, sino en el entorno: hardware, protocolo, drivers, proceso DevOps. El error humano es más probable que súpercomputadoras maliciosas.

Canales laterales: timing y caché

Históricamente los ataques por timing y caché afectaron más a malas implementaciones software de AES con tablas S-Box, sobre todo en dispositivos sin AES-NI. AES-NI resuelve gran parte con operaciones a tiempo constante. ChaCha20 es por naturaleza más cercano a tiempo constante por usar solo add-rotate-xor, sin tablas ni ramas. De ahí su fama de “más seguro en dispositivos baratos y antiguos”. Pero seamos honestos: librerías modernas 2026 (BoringSSL, OpenSSL 3.x, libsodium) cuidan mucho esto y con build correcto ambas funcionan confiablemente. Los verdaderos riesgos son fugas de claves en RAM, errores en RNG, registros de secretos, gestión energética inestable. Aquí el cifrado no falla, falla el despliegue y mantenimiento.

Modos AEAD y errores típicos de configuración

Elige AEAD: AES-GCM o ChaCha20-Poly1305. Descarta esquemas obsoletos como AES-CBC+HMAC para despliegues nuevos, salvo razones especiales. Cuida unicidad de nonce, genera claves correctamente, no escatimes en entropía. En OpenVPN e IKEv2 usa suites modernas; en WireGuard estás limitado a ChaCha20-Poly1305 — y es bueno, menos tentaciones de errar la configuración. Detalle clave: longitud de clave — AES-128-GCM es suficiente para la mayoría y suele ser más rápido que AES-256-GCM, pero si la política exige “256 o nada”, toma 256. ChaCha20 es 256 bits por defecto, elección más simple. El mayor error es intentar “mejorar” valores seguros con excentricidades.

Consumo energético y calor: especialmente importante en móviles

La batería prefiere eficiencia, no marca de cifrado

En smartphone o portátil bajo carga, cifrar no es cosa menor. Una diferencia del 10–20% en uso de CPU puede dar horas extra de autonomía. ChaCha20 suele ganar en equipos sin buena aceleración AES: menos calentamiento, frecuencia más estable, velocidad constante. Pero en ARMv8 modernos con aceleración AES hardware la diferencia desaparece: AES-GCM puede ser igual o incluso más eficiente ejecutándose en bloques dedicados del SoC. Moraleja sencilla: no discutas de dogmas, prueba tu teléfono en concreto. Diez minutos de iperf3 con tu servidor VPN y verás quién consume menos batería. La práctica vence a mitos mejor que cualquier artículo, incluso este.

Throttling y velocidad estable a largo plazo

Una sesión corta es una cosa, un streaming de dos horas, otra. Si el cifrado calienta el chip, el sistema baja frecuencias (throttling) y en 20–30 minutos la velocidad cae de 800 a 300 Mbps. ChaCha20 suele generar menos calor en terminales medios y mantiene velocidad más estable. En flagships con buena disipación y aceleración AES potente la situación es pareja. Consejo: reduce carga al CPU a nivel protocolo — elige WireGuard en vez de OpenVPN, usa autoajuste MTU, controla roaming celular, aplica keepalive con sentido. Así evitas picos y ayudas a la batería.

5G, Wi-Fi 6/7 y cifrado: ¿quién sigue el ritmo del radio?

Las redes se aceleran. El ancho de banda radio sube y el cifrado se vuelve cuello de botella. Con señal estable 5G alcanzarás el techo del algoritmo sin problemas. Aquí AES-GCM en x86 con AES-NI mantiene fácilmente gigabit y más sin sudar, y ChaCha20 en WireGuard en smartphone potente logra cientos de Mbps, suficiente para streaming cómodo. En Wi-Fi 6/7 la latencia es menor y hay más paquetes — importa la paralelización (fortaleza de GCM) y ausencia de bloqueos en kernel (fortaleza de WireGuard). Receta final: no mires solo el cifrado, piensa en conjunto "protocolo + hardware + driver + red".

Aceleración por hardware y detalles bajo el capó

AES-NI, extensiones Crypto ARMv8, NEON: cuando AES se vuelve “turbo”

En x86 AES-NI es magia: cada paso del AES es instrucción, la velocidad es astronómica y ataques laterales al mínimo. En ARMv8 hay extensiones Crypto: aceleración hardware AES y SHA usada en Android, iOS y ARM para servidores. El resultado: AES-GCM recibe un gran empujón y es “rápido por defecto”. NEON ayuda tanto a AES como a ChaCha, pero AES gana más con extensiones Crypto. Para nosotros esto significa una táctica simple: si tu CPU soporta instrucciones AES y el software las usa, AES-256-GCM suele ser líder. Verificarlo es fácil: openssl speed, iperf3 sobre VPN y notarás la diferencia.

ChaCha20 y SIMD: velocidad sin AES hardware

ChaCha20 no tiene una instrucción hardware universal como AES-NI, pero se vectoriza muy bien en NEON, AVX2, AVX-512. Implementaciones en BoringSSL, OpenSSL, libsodium 2024–2026 le sacan máximo partido: en ARM medio ChaCha20 fácilmente supera AES-GCM; igual en x86 sin AES-NI. Bonus: carga CPU uniforme sin picos, bueno para virtualización y contenedores. Sumamos que ChaCha20-Poly1305 es más sencillo de mantener en "tiempo constante", facilitando auditorías. Por eso gusta en apps que necesitan predictibilidad.

Tarjetas de red, offload, motores IPsec y TLS

En entornos corporativos dominan offload y kernel. Algunos NICs pueden descargar AES-GCM para IPsec y TLS, alcanzando 10–100 Gbps. Offload para ChaCha20 es raro, por eso en enlaces ultrarrápidos la elección por AES es clara. En Linux el stack XFRM para IPsec está maduro y OpenSSL 3.x maneja bien crypto-engines. En esos escenarios AES gana no porque ChaCha sea débil, sino porque el hardware está optimizado para AES. Si montas túnel oficina-centro de datos a 10 Gbps o más, la probabilidad de que elijas AES-GCM se acerca al 100%.

Pruebas prácticas y casos 2026: de PC a routers

PC y portátil con AES-NI: rendimiento en números

Caso: Ryzen 5 con AES-NI, Linux 6.x, OpenVPN y WireGuard. En OpenVPN con AES-256-GCM se logran 1,2–1,6 Gbps por núcleo, más con multihilo; con ChaCha20-Poly1305 0,9–1,4 Gbps. En IKEv2/IPsec con módulos kernel activados 3–5 Gbps. WireGuard (ChaCha20) 1,5–3 Gbps, a veces más en kernels nuevos con MTU optimizado. CPU carga menor en AES, ventiladores más silenciosos. Conclusión: en desktop con AES-NI usa AES-GCM en OpenVPN/IPsec; si prefieres WireGuard, ChaCha20 ofrece buena velocidad y configuración simple. La comodidad de WireGuard a menudo pesa más que la diferencia en cientos de Mbps.

Smartphone de gama media: vida real, no benchmarks

Caso: smartphone Android 2023–2025 sin extensiones Crypto potentes. WireGuard (ChaCha20) rinde estable 300–600 Mbps, el teléfono se calienta poco y la batería dura razonablemente. OpenVPN con AES-256-GCM llega a 150–350 Mbps, a veces alcanza a WireGuard, especialmente si el fabricante activó AES hardware. En un flagship 2025–2026 con ARMv8 Crypto, OpenVPN AES-GCM se iguala o pierde por 10–20% según radio y frecuencias. Para streaming y juegos en la nube no solo importa velocidad pico sino estabilidad bajo roaming. WireGuard con ChaCha20 suele ser más amigable: levanta túnel rápido, maneja IP cambiante y pacifica saltos.

Router con OpenWrt: aceleradores definen el destino

Caso: router doméstico con SoC ARM sin AES hardware. OpenVPN AES-GCM 60–120 Mbps, hasta 150. ChaCha20-Poly1305 120–250 Mbps con buena compilación y flow offload activo. Si el chip tiene AES hardware y soporte driver, la historia cambia: AES-GCM 300–600 Mbps, ChaCha20 200–400. En IKEv2/IPsec la cifra sube con kernel. Consejo simple: verifica qué soporta tu SoC (modelo + “crypto engine”) y si hay driver en tu OpenWrt. La implementación importa más que logos en caja. Buen driver hace rey a AES; su ausencia corona a ChaCha20.

Protocolos VPN: WireGuard, OpenVPN, IKEv2/IPsec y matices de elección

WireGuard: ChaCha20 por defecto y velocidad lista para usar

WireGuard es minimalismo, kernel, criptografía estática y ChaCha20-Poly1305 como único cifrado para datos. No eliges entre AES y ChaCha, obtienes stack optimizado con enfoque en seguridad y sencillez. En 2026 WireGuard está maduro, logging y gestión de claves familiar, y proveedores VPN lo ponen por defecto. Lo clave: ajustar bien MTU, activar roaming y sincronizar relojes dispositivos. Si tienes clientes móviles y valoras simplicidad, WireGuard es casi siempre gran opción. Funciona con ChaCha20 donde debe: redes móviles inestables y CPUs débiles.

OpenVPN: flexibilidad, pero mayor consumo CPU

OpenVPN soporta AES-GCM, ChaCha20-Poly1305 y muchas opciones. Ventaja y desventaja. Ventaja: adecuas config a hardware y compliance. Desventaja: fácil confundir y usar mal opciones. En 2026 el defecto correcto es: AES-256-GCM en x86 con AES-NI; ChaCha20-Poly1305 en ARM débil sin AES; libc y crypto libs probadas, multihilo, ventanas sensatas. Usa UDP o QUIC para mejor latencia, cuidado con TCP. Sí, OpenVPN es históricamente más hambriento que WireGuard: en móviles suele perder, pero en servidores potentes con AES-NI puede brillar.

IKEv2/IPsec: punto medio corporativo

Fuerza de IKEv2/IPsec es madurez, offload hardware y soporte en routers, firewalls y VPC cloud. AES-GCM es nativo aquí, por eso a 1–10 Gbps suele ser mejor opción. ChaCha20-Poly1305 en IPsec existe pero con soporte hardware reducido, menos práctica. Para túneles L2L de oficina, data centers o enlaces interregionales, AES-GCM en IKEv2/IPsec da menos sorpresas. IKEv2 con EAP es popular en móviles, pero roaming menos ágil que WireGuard. Por eso híbridos comunes: IKEv2 para backbone y sucursales, WireGuard para empleados y dispositivos.

Recomendaciones claras: cómo elegir cifrado según tu caso

Si tienes desktop o servidor con AES-NI

Elige AES-256-GCM en OpenVPN o IKEv2/IPsec — es la vía más rápida y eficiente, sobre todo en gigabit. Si usas WireGuard no hay problema, ChaCha20 da velocidad fantástica y fácil administración; la ventaja de AES-NI no suele ser crítica en la práctica. Para compliance AES es casi irremplazable.

Si usas smartphones y tablets

En flagships 2025–2026 con ARMv8 Crypto Extensions la diferencia entre AES-GCM y ChaCha20-Poly1305 es mínima. En modelos medios y viejos ChaCha20 suele ser más eficiente y rápido. La mejor opción es WireGuard con ChaCha20 en móviles: maneja roaming, radio inestable y suspensión. Si usas OpenVPN, prueba ambos cifrados y elige menor carga CPU con iperf3.

Si tienes router o placa única

Mira el hardware. Si hay aceleración AES con driver, usa AES-GCM. Si no, ChaCha20-Poly1305. Para L2L y enlaces DC: IKEv2/IPsec con AES-GCM y, si hay, offload en NIC. En dispositivos domésticos con CPU limitado, WireGuard con ChaCha20 suele dar mejor latencia y velocidad estable.

Errores comunes y mitos para evitar tropiezos

Principales errores de configuración

El error más común es ignorar MTU y MSS: la fragmentación mata velocidad y crea problemas “fantasma”. Segundo: conservar suites antiguas como AES-CBC sin necesidad. Tercero: no verificar capacidades hardware CPU; te sorprenderías lo que acelera AES-NI. Cuarto: olvidar nonce únicos y RNG de calidad. Quinto: probar en red “vacía” y asustarse con pérdida de velocidad bajo carga real. Nuestra receta: prueba escenarios variados, usa iperf3 y bpftrace, vigila desempeño CPU. Y sí, actualiza kernel y drivers, que crecen por commits no días.

Mitos que es mejor dejar atrás

“AES-256 siempre más lento que AES-128” — no siempre, con AES-NI la diferencia es mínima y a veces oculta por tareas de fondo. “ChaCha20 es inseguro porque es nuevo” — lleva años en auditorías y uso real. “WireGuard es menos seguro por menos opciones” — todo lo contrario, menos opciones significa menos errores. “ChaCha20 siempre mejor en móviles” — generalmente sí, pero en ARMv8 buen AES a veces iguala o gana. “Hay que correr detrás de 2 Gbps” — no, 300–600 Mbps estables en móviles valen más que gigabit efímero que cae en 20 minutos por throttling.

Optimizaciones y checklist para implementar

Chequeo rápido antes de arrancar

• Define prioridades: velocidad, batería, compliance, facilidad de administración.
• Revisa flags CPU: AES-NI en x86, Crypto Extensions en ARMv8.
• En móviles, prueba WireGuard con ChaCha20; para backbone, IKEv2/IPsec con AES-GCM.
• Configura MTU/MSS, activa roaming según necesidad y vigila timers NAT.
• Testea iperf3 con distintos tamaños de ventana, compara carga CPU y calentamiento.
• Actualiza kernel, OpenSSL/BoringSSL, OpenVPN/strongSwan, herramientas WireGuard.

Este listado parece sencillo, pero resuelve el 80% de problemas. De verdad, a veces una flag CPU cambia toda la elección del algoritmo.

Trucos prácticos para máxima velocidad

• En x86 con AES-NI usa AES-256-GCM y acelera kernel si puedes.
• En ARM sin aceleración AES activa ChaCha20-Poly1305, desactiva servicios extras en router.
• En OpenVPN usa UDP, multihilo y stack crypto moderno.
• En WireGuard, MTU correcto, PersistentKeepalive para NAT, logging solo de metadatos sin secretos.
• En cloud verifica flags virtuales CPU y política hypervisor sobre AES.

Estos pasos parecen aburridos, pero aportan porcentajes reales e incluso duplican velocidad a veces.

Veredictos cortos para escenarios comunes

• PC/servidor con AES-NI: AES-256-GCM suele ser mejor elección.
• Smartphone de gama media: ChaCha20-Poly1305 en WireGuard.
• Flagship 2026: empate; elige según comodidad del protocolo.
• Router sin aceleración AES: ChaCha20.
• Router con aceleración AES: AES-GCM.
• Backbone corporativo >1 Gbps: IKEv2/IPsec + AES-GCM con offload si es posible.

Sencillo y al grano. Pero siempre verifica tu hardware — hay sorpresas.

Futuro y tendencias 2026: hacia dónde va la industria

Unificación en AEAD y minimalismo en configuraciones

Vemos tendencia a endurecer defaults: AES-GCM y ChaCha20-Poly1305 son básicos, lo demás opcional o casos especiales. WireGuard consolidó cultura de “menos opciones, menos errores”. OpenVPN e IPsec configs se acortan, viejos esquemas desaparecen. En 2026 es tendencia #1: defaults seguros sin brujería.

Crece AES hardware y se intenta acelerar ChaCha

Fabricantes seguirán llenando SoCs de bloques AES y SHA, sobre todo móviles. ChaCha20 seguirá preferido donde no hay AES o no se puede usar. Experimentan aceleración vectorial ChaCha con AVX-512 y mejor NEON, ya se notan mejoras. Pero no esperes “ChaCha-NI” pronto, por eso en multilink gigabit AES mantendrá ventaja sólida.

Contenedores, nube y QUIC

Apps cada vez más detrás de proxies inversos y túneles con QUIC. Ahí TLS 1.3 puede elegir entre AES-GCM y ChaCha20-Poly1305 según CPU. En contenedores, predictibilidad de ChaCha20 a veces vale más que gigabits teóricos de AES si hypervisor limita instrucciones. Tendencia clara: selección automática de cifrado según hardware, menos config manual, más telemetría.

Conclusiones: respuesta breve a gran pregunta

Punto clave en un párrafo

En x86 con AES-NI, apuesta por AES-256-GCM para máxima velocidad y compliance; en móviles y ARM débiles, ChaCha20-Poly1305 suele dar estabilidad, menor calor y mejor batería; en WireGuard el tema está cerrado con ChaCha20 por defecto; en IKEv2/IPsec para altas velocidades AES-GCM lidera objetivamente, especialmente con offload. Y sí, siempre prueba en tu hardware — no es cliché, es ahorro de tiempo y nervios.

Quién debe usar qué ahora mismo

• PC/portátil doméstico: OpenVPN/IKEv2 con AES-256-GCM o WireGuard (ChaCha20) por simplicidad.
• Smartphone: WireGuard (ChaCha20); si necesitas OpenVPN, compara AES-GCM y ChaCha20 en práctica.
• Router: si hay aceleración AES, AES-GCM, si no, ChaCha20; para L2L, IKEv2/IPsec.
• Nube/VPS: si AES está limitado, ChaCha20 en WireGuard; si no, AES-GCM con IKEv2/IPsec.

No es dogma, pero sí punto de partida ideal.

Qué no hacer jamás

• No actives esquemas obsoletos por “compatibilidad” sin necesidad.
• No ignores MTU y MSS — optimización gratis.
• No olvides actualizar kernel, drivers y librerías crypto.
• No decidas “a oído” — haz unas pruebas y mira uso CPU y batería.

Dejemos mitos en el pasado, que es su lugar.

FAQ: respuestas rápidas a las preguntas más frecuentes

¿Es cierto que AES-256 siempre es más seguro que AES-128 y vale la pena pagar en velocidad?

AES-256 es teóricamente más fuerte y cubre ataques futuros, pero en práctica AES-128-GCM ya ofrece un margen enorme y suele ser más rápido. En políticas corporativas “256 o nada” es cuestión de compliance y homogeneidad, no de “facilidad de romper”. Si buscas máxima velocidad y no tienes demanda de solo 256, AES-128-GCM es elección racional. Si quieres margen extra y la velocidad alcanza, AES-256-GCM anda tranquilo en hardware moderno con AES-NI sin grandes pérdidas.

¿Por qué ChaCha20-Poly1305 es mejor para móviles y equipos débiles?

ChaCha20 es un cifrado por flujo ARX: sin tablas, pocas ramas, se adapta bien a SIMD. Esto lleva a velocidad predecible sin AES hardware y reduce riesgo de canales laterales por malas implementaciones. En realidad, implica menos calor, estabilidad en sesiones largas y ahorro en batería. Además, WireGuard lo estandarizó, así que en móviles “sale de caja” con buen roaming y NAT. Resultado: en smartphones medios y viejos ChaCha20 suele ganar, en flagships hay empate con AES-GCM.

¿Puedo poner AES-256 en WireGuard en vez de ChaCha20?

Respuesta corta: no. WireGuard estándar usa ChaCha20-Poly1305 y eso es parte de su diseño. Hay ramas experimentales y parches, pero no entraron en producción ni ecosistema amplio. Y está bien así: minimalismo de WireGuard reduce errores de configuración, acelera auditoría y simplifica soporte móvil. Si AES es imperativo por compliance, mira IKEv2/IPsec o OpenVPN con AES-GCM y hardware acelerado.

¿Qué elijo para oficina 1–10 Gbps: WireGuard o IKEv2/IPsec?

Para túneles L2L entre oficinas y backbone 1–10 Gbps suele ganar IKEv2/IPsec con AES-GCM, especialmente si hay offload en NIC y stack XFRM maduro en Linux. WireGuard puede dar velocidades excelentes en CPUs potentes, pero IPsec tiene más opciones para integración con hardware de red, QoS y monitoreo, y fabricantes llevan años probando estos stacks. Para empleados remotos, WireGuard es más cómodo: menos latencia, mejor roaming y clientes agradables.

Si solo quiero velocidad en PC, ¿qué uso?

En x86 con AES-NI suele ser más rápido AES-256-GCM en OpenVPN o IKEv2/IPsec, con gigabits si configuras bien. Pero no descartes WireGuard: ChaCha20 da casi igual y la facilidad de configuración es gran plus. La mejor manera de no errar es hacer 2–3 pruebas con iperf3 y evaluar no solo pico de velocidad, sino estabilidad con carga y temperatura. A veces la comodidad de WireGuard supera una ventaja teórica de cientos de Mbps de AES.

¿Y si tengo un router viejo o placa económica?

Si no hay AES hardware o drivers no lo usan, opta por ChaCha20-Poly1305. Este cifrado en NEON suele duplicar rendimiento frente a AES sin aceleración. Si tu SoC tiene Crypto Engine para AES y OpenWrt lo soporta, usa AES-GCM. Revisa modelo específico: a veces una actualización de firmware habilita offload AES y la velocidad se dispara.

¿Tiene sentido esperar un ChaCha20 “hardware” tipo AES-NI?

En años próximos, difícil. Fabricantes se concentran en AES y SHA, que son pilares de industria: IPsec, TLS, estándares corporativos y offload en NIC. Optimización de ChaCha20 seguirá en SIMD (AVX2, AVX-512, NEON), y velocidades ya son buenas. Pero no esperes “ChaCha-NI” pronto. ¿Significa derrota? No. En móviles, contenedores y hardware débil suele ser mejor opción, y donde hay AES hardware, AES-GCM es líder lógico.