como RC4 es no es seguro y AES-CBC es lo mismo, la única solución es usar el modo EAX para AES. ¿Pero por qué mozilla NSS no soporta el mod EAX? ¿Hay alguna implementación segura de EAX? y por qué wikipedia dice "usar el modo CTR significa que el cifrado debe implementarse solo para el cifrado "?
No nos confundamos.
RC4 no está totalmente roto pero el margen de seguridad se ha convertido en incómodamente pequeño . Sabemos desde hace años que RC4 debería ser reemplazado, pero también que no se ha roto "en la naturaleza" ninguna conexión SSL real con RC4, debido a las deficiencias conocidas de RC4 (los ataques se demostraron en condiciones de laboratorio que están en el borde de ser realista, pero no del todo todavía).
AES-CBC no está realmente roto . Lo que se ha atacado (con BEAST) es la forma en que se utiliza el modo CBC en SSL / TLS . El ataque real hace ya no funciona . Esto todavía justifica cambiar a mejores modos, pero no hay un requisito absoluto para hacerlo cumplir dentro de la próxima hora; más bien, deberíamos promover un camino de transición en los próximos años.
Los modos buenos que deben usarse son los modos de cifrado autenticados que combinan el cifrado y MAC de forma segura. Se han definido varios de estos modos, algunos de los cuales están (desafortunadamente) cubiertos por patentes y otros problemas de propiedad intelectual que tienden a hacer que su uso sea delicado. Las recomendaciones habituales son EAX y GCM , que están libres de patentes y razonablemente eficientes (cuando se me da la opción, generalmente prefiero EAX porque se desempeña mejor en arquitecturas muy pequeñas, pero GCM también está bien, y está" aprobado por NIST " ). Tanto EAX como GCM internamente usan el modo CTR, pero eso es solo una parte de la historia. Hay un estándar para las suites de cifrado GCM en TLS, así que ese es el Camino del Futuro: si es posible, intente usar el Conjuntos de cifrado GCM en sus clientes y servidores SSL / TLS. Pero si, por razones de facilidad de uso (p. Ej., Disponibilidad de implementaciones), tiene que confiar en AES-CBC o incluso en RC4, no se estrese demasiado: eso es razonablemente bueno para los estándares actuales (es improbable que incluso RC4 lo haga). ser el punto más débil de su servidor).
La cita de Wikipedia trata sobre una característica técnica de las implementaciones en modo CTR: en el modo CTR, el cifrado de bloque (el elemento que procesa un bloque con una clave dada) se usa siempre en el llamado Modo de "cifrado", independientemente de si utiliza CTR para cifrar o descifrar un mensaje. Esto es así porque el modo CTR consiste en generar un flujo largo de bytes dependiente de la clave; el cifrado de datos real es un XOR de esta secuencia con los datos para cifrar, y el descifrado es la operación exactamente igual . Por lo tanto, siempre se genera la secuencia, que ejerce el cifrado de bloque siempre de la misma manera. Eso no es una cosa de seguridad; es una característica que los implementadores generalmente encuentran agradable y conveniente, especialmente en arquitecturas con severas restricciones en el tamaño del código o en el área de silicio.