¿Desventajas de AES-CTR?
Sobre el papel, me suena * muy * bien:
- seguro
- rápido (en mis pruebas es algo más lento que ECB (pero sin la mayoría de las debilidades, más sobre eso a continuación) pero más rápido que todas las otras alternativas que probé, que se
ECB, CTR, CBC, OFB, CFBescribieron en orden de rendimiento ( enlace al código de referencia )) - simple de entender
- no requiere relleno (lo que supongo que reduce significativamente la posibilidad de implementar relleno de una manera insegura)
- admite paralelización (tanto para el cifrado como para el descifrado)
- admite acceso aleatorio
.. la única desventaja en la que puedo pensar es que debido a que no requiere relleno, las implementaciones en la práctica probablemente revelarán la longitud exacta del mensaje , en comparación con revelar las longitudes de los mensajes (por ejemplo, los esquemas rellenados pueden revelar algo como the message is within 15 bytes of this length, mientras que no -los esquemas de relleno pueden revelar the message is *exactly* this long), y si eso es una preocupación, no es que no pueda mitigarse simplemente agregando relleno de todos modos.
Supongo que me falta algo, así que ...
¿Cuales son las desventajas?
Respuestas
Desventajas:
Longitud del mensaje: en criptografía, normalmente, la longitud del mensaje no se considera secreta. Hay enfoques en los que puede agregar valores aleatorios al final o al principio o ambos si esto es realmente una fuga de información para usted. El enfoque aleatorio depende de su caso de datos real. También es posible que se pueda utilizar un tamaño fijo predeterminado ya que el correo electrónico se puede limitar a 512 caracteres. Al final, al menos el límite superior se revela en todos los casos.
La reutilización del par (IV, clave) es un problema real que puede eliminar la confidencialidad con la técnica de arrastre de cunas. Esto no revela la clave de cifrado.
Falta de autenticación Como todos los modos de cifrado no autenticados, el modo CTR simple carece de integridad y autenticación. Un simple giro puede tener resultados catastróficos debido a la maleabilidad del modo CTR.
El modo AES-GCM que usa el modo de operación CTR le proporciona todo en una vez, sin embargo, tiene el mismo problema de reutilización de pares (IV, clave). Hay un modo de Vector de inicialización sintético (SIV) como resistencia al uso indebido ( papel , rfc8452 ) que elimina esto. El modo SIV aún puede filtrar que el mismo mensaje se envía con la misma clave, por lo que un observador puede distinguir esto.
Distintivo de mensajes largos: El modo CTR está diseñado con una función pseudoaleatoria (PRF). Cuando usamos AES en modo CTR, lo usamos con Permutación Pseudo Aleatoria (PRP);$$E_k\colon \{0,1\}^n \to \{0,1\}^n.$$ Con PRP siempre que los bloques de mensajes no se repitan la secuencia $E_k(0), E_k(1), \dots, E_k(\ell - 1)$ con $\ell < 2^n$no se repite. Si el mensaje con longitud$\ell$-block no tiene bloque repetido esto no es problema. Si nos acercamos al mensaje como un bloque aleatorio uniforme, entonces esperamos una colisión$\ell \approx \sqrt{2^n} = 2^{n/2}$ por la paradoja / ataque del cumpleaños.
Cuando se usa con AES-128 para mensajes largos, verifique la repetición. La repetición permite al atacante distinguir esto del azar uniforme con una probabilidad no despreciable .
En resumen, un texto cifrado duplicado en cualquier posición filtra que los mensajes son diferentes.
Tamaño del mensaje por clave: aunque NIST dice 64 nonce y contador de 64 bits, se debe dejar de usar una clave mucho antes$2^{64}$bloquear. Esto se debe al uso de PRP (AES) en lugar de PRF en el modo CTR .
Otras ventajas:
No es necesario el descifrado: el modo CTR no requiere el descifrado del cifrado de bloque, siempre lo usa para el cifrado. Esto es muy útil en entornos de restricciones. También simplifica el código de software y hardware.
No necesita PRP: no necesita un cifrado de bloque (PRP) en absoluto. Se puede utilizar una función hash como en la serie ChaCha.
Procesamiento previo: el flujo de claves generado por el modo CTR se puede preparar antes. Esto puede ayudar a utilizar búferes.
El modo CTR tiene seguridad CPA .
Un poco de historia de CTR
El modo CTR fue introducido por Whitfield Diffie y Martin Hellman en 1979
Privacidad y autenticación: Introducción a la criptografía como artículo invitado sobre Actas del IEEE, 67 (1979), págs. 397–427.
Una seguridad de tratamiento concreta de cifrado simétrico, Bellare et. al, 97 proporciona los límites de seguridad.
Ver también; Comentarios al NIST sobre los modos de operación AES: cifrado en modo CTR , por Lipmaa et al. para otros detalles de ventajas y desventajas.
Schneier y Ferguson recomendaron inicialmente el modo CTR, pero cambiaron a recomendar el modo CBC debido a las posibles dificultades para garantizar que el contador nunca se reutilizara con una tecla.
Si bien su pregunta parece centrarse en el lado CTR de las cosas, vale la pena una respuesta para discutir el lado AES de las cosas también. Hay al menos dos situaciones en las que otros cifrados de bloques pueden ser más apropiados.
Computación segura :
Hay dos "dificultades" principales de AES con respecto a la computación segura (es decir, computación multipartita y NIZK principalmente, pero también probablemente encriptación totalmente homomórfica).
AES se calcula sobre un campo de característica 2. Si un sistema MPC / FHE usa característica $p$ aritmética, tener un cifrado en la característica 2 requiere conversiones entre diferentes representaciones (digamos, de un elemento en $\mathbb{Z}/p\mathbb{Z}$, o la descomposición en base 2 de dicho elemento) que son más costosos que en el cálculo estándar.
Generalmente, las multiplicaciones son mucho más costosas (relativamente) que las adiciones en el contexto del cálculo seguro. Esto significa que uno puede tener un "modelo de costo" diferente para construir cifrados, donde uno está más interesado en reducir el número de multiplicaciones en el cifrado de forma genérica.
Un cifrado a tener en cuenta para este tema es MiMC (aunque recientemente hubo un ataque parcial contra este cifrado en un "$\mathbb{F}_{2^k}$ versión "de la misma. También tiene"$\mathbb{F}_p$"versiones, que no son afectadas por el ataque).
Sistemas integrados :
En las máquinas estándar, la implementación de hardware de AES (a través de la instrucción AES-NI) proporciona algo así como una aceleración de ~ 40x sobre las implementaciones de software optimizadas de AES. Esto dificulta ser competitivo con AES al comparar AES-NI con implementaciones de software de otros cifrados. Pero cuando no tiene AES-NI, otros cifrados pueden ser más competitivos. Esta publicación de Matthew Green analiza el uso de una alternativa a AES (su recomendación al escribir esto hace ~ 8 años no fue hacer esto, para el registro) analiza ciertos cifrados como Salsa20 que ofrece una aceleración de 2x - 3x sobre AES en el software. Tenga en cuenta que Salsa20 es técnicamente un cifrado de flujo en comparación con AES que es un cifrado de bloque, pero esto es solo para motivar a poder "vencer" a AES en velocidad cuando no tiene acceso a AES-NI.
Una mejor fuente de cifrados más rápidos en entornos informáticos restringidos es la estandarización de criptografía ligera NIST en curso . No he estado siguiendo esto de cerca, pero actualmente hay mucho interés de investigación en encontrar un nuevo cifrado para estandarizar para su uso (esencialmente) en sistemas integrados. Actualmente están planeando publicar sus finalistas de la ronda 3 el próximo diciembre, por lo que no me sorprendería si en los próximos años hubiera un "nuevo cifrado" que reemplace el uso de AES en sistemas integrados.
CTR es de hecho un modo de operación de cifrado de bloques muy agradable. Sus principales inconvenientes son que:
- no protege la integridad del mensaje (y de hecho permite a un atacante cambiar fácilmente bits arbitrarios en un mensaje cifrado sin tener que descifrarlo), y
- puede filtrar texto sin formato si alguna vez se reutiliza un bloque contador; en particular, el cifrado en modo CTR requiere una entrada única nonce que no debe reutilizarse en absoluto para dos mensajes diferentes cifrados con la misma clave.
Afortunadamente, estos dos problemas se pueden resolver utilizando el modo CTR como un componente en una construcción de nivel superior:
- El primer problema se puede resolver utilizando un modo de cifrado autenticado , muchos de los cuales (como EAX y GCM ) se basan en una combinación del modo CTR con un código de autenticación de mensajes .
- El segundo problema se puede resolver mediante el uso de un modo de cifrado "resistente al uso indebido de nonce" que deriva el valor del contador inicial basándose en (entre otras cosas) el mensaje de texto sin formato que se cifra. Dichos modos incluyen SIV y GCM-SIV , los cuales también se basan en el modo CTR y también proporcionan autenticación de mensajes como se describe anteriormente.
Por supuesto, la adición de autenticación de mensajes requiere un procesamiento adicional que hace que estos modos sean más lentos que el CTR sin formato (aunque una buena implementación de GCM puede ser muy rápida). En particular, para obtener la seguridad total que garantizan estos modos, el receptor debe autenticar todo el mensaje antes de transmitir cualquier texto sin formato descifrado. Para los modos resistentes al mal uso, lo mismo se aplica también al cifrar, ya que todo el mensaje debe procesarse para derivar el valor del contador inicial antes de poder cifrarlo.
Aún así, generalmente es un pequeño precio a pagar por una mayor seguridad. Si puede utilizar un modo resistente al mal uso de nonce como SIV o GCM-SIV, le recomiendo que lo haga. Si no es así, al menos use un modo AE basado en nonce como GCM.