Al preparar la Metodología para calcular el Índice de confiabilidad HTTPS, revisamos mucha literatura temática y más de una vez encontramos una recomendación para admitir conjuntos de cifrado basados en el algoritmo de cifrado CHACHA20 en un servidor web para reducir la carga en los clientes móviles. que no puede utilizar hardware AES. En este contexto, generalmente se mencionaban los procesadores Mediatek y los "procesadores móviles de presupuesto antiguo".
¿CHACHA20 con su fiel compañero POLY1305 realmente mantiene frescos a los clientes móviles, y vale la pena admitirlo en un servidor web? ¡Vamos a discutirlo!
CHACHA20 fue creado por el renombrado criptógrafo Daniel Bernstein, a quien amamos por su Curve25519 en particular, y por sus esfuerzos de defensa de que solo los viejos recuerdan lo que significa _EXPORT_ en una suite de cifrado. El algoritmo está bien investigado, opera en modo AEAD, no tiene debilidades o vulnerabilidades conocidas y es uno de los dos algoritmos de cifrado aprobados por el IETF para su uso en TLS 1.3 (el otro es AES inmortal).
Su fuerza criptográfica teórica cuando se usa en TLS se estima de manera diferente, en el intervalo entre AES-128 y AES-256 en modo GCM, que se considera suficiente para los estándares actuales y para el futuro previsible. Al mismo tiempo, se observaque CHACHA20 es "más rápido" que AES, es decir "Consume menos recursos de procesador para proporcionar el mismo nivel de fuerza criptográfica". Esta redacción no solo huele a telemarketing (con el debido respeto a su autor), sino que también pierde un detalle importante: en procesadores sin soporte de hardware AES.
Y aquí finalmente volvemos a los "procesadores móviles económicos" que se sobrecalientan bajo AES, comienzan a acelerarse y demandan nitrógeno líquido (sarcasmo). Los fabricantes de procesadores son conscientes del problema y lo han resuelto agregando un conjunto de instrucciones apropiado. En procesadores compatibles con x86, esto es AES-NI, en otros, sus nombres (y su propio conjunto). Y aquí llegamos a la parte más interesante: el soporte AES por parte de los procesadores.
Intel introdujo el soporte para AES-NI en 2010 en los procesadores Westmere, y no en todos: Atom, Celeron, Pentium y Core i3, no se ha confiado en él durante mucho tiempo. Puede estar seguro de la compatibilidad con AES-NI sin profundizar en las especificaciones solo comenzando con la arquitectura Goldmont (Apollo Lake y Denverton), y esto ya es 2016.
Para AMD, estas son las arquitecturas Bulldozer (2011) y Jaguar (2013), con ARM todo es más complicado: el soporte para instrucciones AES se proporciona en la arquitectura ARMv8-A (2011, el primer dispositivo es 2013), pero su implementación real en silicio depende del procesador del fabricante y yo personalmente no silbaría con tanta confianza sobre "procesadores móviles de presupuesto antiguo", sino que vale la pena hablar de "procesadores móviles no insignia" en general, incl. producido hasta el día de hoy.
En pocas palabras, no es tan difícil encontrar un procesador sin soporte de hardware AES. Entonces, ¿CHACHA20 es realmente una gran alternativa a AES? Echemos un vistazo a los resultados de este estudio , por ejemplo . En procesadores sin soporte AES, CHACHA20 lo supera notablemente en rendimiento, a menudo varias veces. Desafortunadamente, no se nos mostraron las medidas de temperatura, pero si estamos hablando de un procesador de servidor, es obvio que la diferencia en los recursos del procesador consumidos es significativa.
La situación se invierte cuando se trata de procesadores con capacidad AES. No vale la pena culpar a CHACHA20 por esto, a quien nadie le ofreció un conjunto personal de instrucciones en el procesador, y lo que sucede cuando ambos jugadores juegan con las mismas reglas, lo vimos en procesadores antiguos (les recuerdo: AES se fusiona).
Entonces, ¿vamos a buscar soporte para CHACHA20 en servidores web? Por qué no, aunque solo sea por el motivo de que no se ponen todos los huevos en una canasta, y si de repente mañana se encuentra un agujero en el propio AES o en su implementación en una biblioteca de criptografía en particular, podemos apagarlo "hasta aclaración" con un ligero movimiento de nuestra mano, permanecer en CHACHA20, y no buscar frenéticamente algo que reemplace a AES, sino cómo se enciende.
La pregunta sobre el lugar de CHACHA20 en
Recordemos cómo se negocia generalmente el conjunto de cifrado al establecer una conexión HTTPS: el cliente envía al servidor la lista de conjuntos de cifrado que admite, en orden "desde el bulldozer" y este orden se puede cambiar solo a través de las políticas de grupo de Windows y solo para
La prioridad de los conjuntos de cifrado en el servidor generalmente se establece sobre la base del principio de máxima seguridad disponible: los conjuntos de cifrado más fuertes se enumeran primero, menos, el último. Un cliente moderno se topa con una suite de cifrado fuerte y está de acuerdo con ella, un cliente "desactualizado" salta más abajo en la lista a una suite de cifrado menos fuerte y está de acuerdo con ella. Todos están contentos, todo funciona, desde cada uno según su capacidad, hasta cada uno usando HTTPS.
Y aquí encaja una suite de cifrado basada en CHACHA20 en esta imagen armoniosa del mundo, que añadimos por motivos de reducir la carga sobre los clientes "débiles" desde el punto de vista del hardware, sin saber nada sobre si están simultáneamente "desactualizados" o no (es decir, el buque insignia de este año de una empresa china de tercer nivel, o un niño de cinco años de rango medio de una marca de primer nivel). El cliente informa que es compatible con TLS 1.3 y un conjunto completo de conjuntos de cifrado asociados, tanto AES como CHACHA20. Su solución, administrador, ¿qué paquete de cifrado estamos acordando con el cliente? Aquí estoy más o menos igual ...
resumo lo anterior sobre el algoritmo de cifrado CHACHA20.
- El algoritmo es bastante bueno por sí mismo y es adecuado para su uso en TLS.
- Las suites de cifrado basadas en él solo son compatibles con navegadores bastante modernos , por lo que no hay necesidad de AES en absoluto.
- La ganancia de rendimiento de su uso se puede obtener no solo en "procesadores móviles de presupuesto antiguo", sino también en computadoras de escritorio y servidores. En los procesadores con soporte de hardware para AES, la situación se invierte.
- Al establecer una conexión HTTPS, no hay forma de saber si el procesador del cliente es compatible con AES en el hardware. En consecuencia, no hay forma de saber qué conjunto de cifrado será "más rápido" en cada caso.