¿Los IV deben ser impredecibles?

Question

¿Los IV deben ser impredecibles?

#1 de cpast (2 votos)

5

Estoy cifrando una secuencia de mensajes con AES/CTR . Para cada secuencia, genero una inicial IV aleatoria, por ejemplo, IV(0) . Defina IV(i) = MD5(IV(i - 1)) para i = 1, ..., n . Luego para cada mensaje m(i) , Transmito IV(i) . e(key, IV(i), m(i)) sobre el canal, donde . denota la operación de adición y e(.) es la función de cifrado. En otras palabras, el IV de cada mensaje se deriva del IV anterior mediante la aplicación de una función hash y Transmito los IV a lo largo del texto cifrado. Por lo tanto, Las IV son distintas (con alta probabilidad), pero predecible, si tienes el anterior.

¿Hay algún problema con este esquema de cifrado?

Editar:

Tengo que usar CTR, debido a algunas restricciones de implementación. Quiero almacenar los datos cifrados en un dispositivo de almacenamiento inseguro y descifrarlos una vez que haya recuperado la información. La confidencialidad es mi principal prioridad. La integridad o maleabilidad del mensaje son de menor importancia. De hecho, El contenido de los mensajes es una versión comprimida de algunos archivos altamente estructurados. Es decir, la modificación de algunos bytes del texto cifrado sin saber todo el texto llano arruina la integridad del mensaje. Entonces, asumo que la estructura del archivo impone algún tipo de integridad.

encryption initialisation-vector

pregunta Oxy 23.02.2015 - 23:59

fuente

1 respuesta

Lea otras preguntas en las etiquetas encryption initialisation-vector

Monte Iphone para el análisis forense o tome una imagen forense ¿Puedo aislar una computadora específica en mi red?

score 2 · Answer 1

Con el modo CTR, los IV no tienen que ser impredecibles o aleatorios. Sin embargo, deben ser únicos para una clave determinada: reusar un IV es un defecto fatal para el modo CTR. Es perfectamente correcto que la IV sea solo i (rellenado a la longitud apropiada); incluso está bien que llame a su enemigo mortal y pregúnteles qué IV debe usar para su mensaje, siempre que verifique que no haya usado previamente el IV; Mientras lo verifique, no hay nada que puedan hacer para comprometer su cifrado. Y dado que necesitas más que una "alta probabilidad", necesitas una certeza virtual (para GCM, NIST especifica una probabilidad 2^-32 de que alguna vez reutilice la clave y IV, y permitir incluso eso es porque eso es aceptablemente improbable y le permite salirse con cierta aleatoriedad). Una forma decente sería que los primeros 32 bits sean únicos para la secuencia de mensajes (por ejemplo, un valor de contador para la secuencia), y los siguientes 32 sean un índice del mensaje dentro de la secuencia, que también es un valor de contador. / p>

Nota: Esto supone que su IV es solo una parte de las fuentes que encripta para crear una cadena de claves. Por ejemplo, una forma común de construir un flujo de claves es concatenar un contador de 64 bits a un IV de 64 bits; en ese caso, un simple contador para el IV es suficiente. Si su implementación toma un IV de 128 bits, entonces probablemente calcula el flujo de claves como E(k,IV)||E(k,IV+1)||E(k,IV+2)||... , en cuyo caso no puede simplemente incremente el IV en cada secuencia: eso haría que el flujo de claves del mensaje 2 E(k,IV+1)||E(k,IV+2)... . Si alguna vez cifras lo mismo con la misma clave para crear dos secuencias de claves diferentes, eso es malo. Con GCM, un IV típico es de 96 bits, y solo debe asegurarse de no repetir los IV de 96 bits para dos mensajes. El punto es que si sus mensajes pueden tener hasta b bytes de largo, los primeros 128-16b bits de su IV deben ser únicos entre todos los mensajes. 96 bits es común, como 64 bits.

Dicho esto, hay un problema aparte: no tiene autenticación en su sistema. Eso significa que un atacante que sabe qué parte de un mensaje dice puede cambiarlo para decir lo que quiera, siempre que lo que quieran tenga la misma longitud que la parte del mensaje que conocen. CTR, como todos los cifrados de flujo, es particularmente fácil de hacer con esto. Un modo AEAD como GCM o CCM o EAX es mejor en casi todos los casos: protege sus mensajes de ataques activos. Creo que GCM tiene los mismos requisitos IV que el CTR (es decir, que se usa una vez, pero aparte de eso no hay requisitos), y hay muchas implementaciones buenas disponibles. (Con GCM, los IV son generalmente de 96 bits).