2011-02-09 24 views
7

según lo que sé, el modo CTR no utiliza un vector inicial. Simplemente toma un contador, lo encripta con una clave determinada y luego el resultado de XOR con texto sin formato para obtener el texto cifrado.Uso del modo CTR del vector inicial (IV)

Otros modos de cifrado de bloque como CBC antes de hacer el cifrado XOR el texto plano con un vector inicial.

Así que aquí está mi problema. Tengo el siguiente código en Java (usando la biblioteca BouncyCastle):

Cipher cipher = Cipher.getInstance("AES/CTR/PKCS5Padding", "BC"); 

cipher.init(Cipher.ENCRYPT_MODE, key); 

byte[] result = cipher.doFinal("Some plaintext"); 

Cada llamada diferente del código anterior con la misma clave da salida diferente! Pero al hacer:

byte[] IV = new byte[]{0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0}; 

Cipher cipher = Cipher.getInstance("AES/CTR/PKCS5Padding", "BC"); 

cipher.init(Cipher.ENCRYPT_MODE, key, IV); 

byte[] result = cipher.doFinal("Some plaintext"); 

Tomo el mismo resultado en cada llamada del código anterior. ¿Pero por qué es esto? Quiero decir, CTR no necesita un IV, entonces ¿por qué cuando no administro un IV en cada llamada obtengo un resultado diferente y cuando administro un IV, el resultado es el mismo? Si siempre utilizo el IV anterior (todos ceros) cuando uso el CTR, ¿sería seguro?

Cualquier idea sería muy útil. Gracias

+2

[Si está escribiendo las letras AES en su código, lo está haciendo mal.] (Http://chargen.matasano.com/chargen/2009/7/22/if-youre-typing-the -letters-aes-into-your-code-youre-doing.html) –

+0

Crypto es * realmente fácil * arruinarlo. Y meterse en formas que son totalmente invisibles hasta que alguien los explote. Use una biblioteca establecida con una interfaz difícil de destruir. –

+2

@Anon. Incluso elijo mi IV, por favor ven y mátame ahora. (Sugerencia: algunas personas saben lo que están haciendo, este consejo general de no escribir AES en su código es estúpido.) – Luc

Respuesta

5

El más importante salvedad con el modo CTR es que nunca, nunca volver a utilizar el mismo valor del contador con la misma clave. Si lo hace, efectivamente ha regalado su texto plano.

Para ayudar con esto, en algunas implementaciones del modo CTR en el mundo real, el bloque que se pasará al cifrado de bloques se divide en dos partes, etiquetadas como IV y contador (en lugar de llamar a todo el contador) El IV se genera aleatoriamente, y el contador comienza en 0.

Esto le permite iniciar la parte "contador" en cero para múltiples mensajes, siempre y cuando no vuelva a utilizar la parte "IV".

Tenga en cuenta que esto es solo una convención de etiquetado. Matemáticamente, es lo mismo que llamar a todo el "contador" y comenzar el contador en un múltiplo aleatorio de un entero para cada mensaje.

No estoy seguro de cómo funciona específicamente la implementación de Bouncy Castle; quizás le permita configurar el bloque inicial completo, el contador y todo, con el valor IV. Aparentemente está generando una IV sensible para usted si no la proporciona, razón por la cual obtiene una salida diferente con la misma entrada. La conclusión es que esto es bueno, y exactamente lo que quiere - el suministro de todos los ceros es malo, y no es lo que quiere.

+0

Gracias :) Ahora lo entiendo – Antonys

0

El modo CTR utiliza algo que es esencialmente equivalente a un IV, y ese es el valor inicial del contador.

2

CTR funciona encriptando valores sucesivos de un contador. El primer valor para esa secuencia es y IV (IV significa "valor inicial" ...). Entonces CTR realmente usa un IV.

Si utiliza el modo CTR, con la misma clave, y reutiliza un valor de contador que ya utilizó para otro cifrado (con la misma clave), obtiene el infame pad de dos tiempos y la seguridad se ha ido por el desagüe. En particular, usar una IV fija para todos los mensajes es una receta segura para el desastre.

Una forma "fácil" para evitar la repetición contador es seleccionar siempre el IV con un generador de números criptográficamente seguro aleatorio (pensar "java.security.SecureRandom") entre el conjunto de posibles IV, es decir, todas las secuencias de 16 bytes. Ese espacio es lo suficientemente grande como para que su riesgo de reutilizar un valor de contador en algún momento pueda ser descuidado.

Solo para completar, una IV fija es tolerable si se asegura de que utiliza una tecla determinada solo una vez. Los problemas de seguridad surgen cuando reutiliza el mismo valor de contador con la misma clave. Sin embargo, tener una nueva clave para cada mensaje es al menos tan difícil como tener un nuevo IV para cada mensaje.

Cuestiones relacionadas