¿Hay un modo de cifrado de contador en el que se cambie la clave para cada bloque de datos?

Hay algunos sistemas de cifrado que hacen esto, especialmente E0 , un cifrado de flujo de 128 bits basado en cuatro LFSRs que se usan en versiones anteriores del protocolo Bluetooth. Como se han encontrado vulnerabilidades en E0, se diseñó un esquema para reducir el impacto de seguridad llamado E0 de dos niveles. Normalmente, el cifrado encripta 2745 bits (un cuadro Bluetooth) a la vez. Con E0 de dos niveles, cada 128 bits del flujo de claves se utiliza para generar otra instancia de E0 que genere solo 2745 bits de flujo de claves desde esa clave.

Tengaencuentaqueestenoesunmodoespecialdecifrado,sinoelusodecifradosdeflujoverdaderos.Estadiferenciaesmenor,yaqueelmododecontadoressimplementeunaformadeconvertiruncifradodebloqueenuncifradodeflujo.Lamayoríadeloscifradosdebloque(ymuchoscifradosdeflujo)tienenun programa clave , que es una fase de configuración costosa siempre que se utiliza una nueva tecla , por lo que es poco práctico cambiar las teclas con frecuencia. El cifrado de flujo E0 no tiene una programación de claves complicada. La clave de 128 bits se usa directamente como el estado interno del cifrado (específicamente, se divide en 25, 31, 33 y 39 bits, cada uno de los cuales se usa como estado inicial para cada uno de los cuatro LFSR del cifrado). Esto le permite cambiar las claves con frecuencia sin un impacto significativo en el rendimiento.

Tenga en cuenta que E0, incluso E0 de dos niveles, es no un cifrado particularmente seguro. La clave debe cambiarse con mucha frecuencia o los ataques de texto sin formato conocidos pueden permitir la recuperación de la clave. Estas debilidades se derivan de los dos problemas en el diseño de E0 de dos niveles, así como del hecho de que E0 se construye a partir de LFSR, que son algoritmos no criptográficos. El uso de AES en modo CTR será mucho más seguro que cualquier tipo de E0.

Probablemente no sea un modo estandarizado. Los cifrados de bloques normalmente se modelan como una familia de funciones biyectivas (permutaciones). Se supone que una función aleatoria elegida de esta familia es indistinguible de una permutación aleatoria real. ( Incluso si se conoce el conjunto completo de funciones .) Se llama un conjunto de funciones (matemáticas) con esta propiedad una permutación pseudoaleatoria (PRP).

Al seleccionar qué función en un PRP usar, necesitamos usar una distribución uniforme para elegir esa función específica. Y, en general, los algoritmos de cifrado en bloque requieren que su clave se elija al azar de una gran distribución uniforme.

Si una clave de cifrado de bloque no se elige de esta manera, puede haber un comportamiento no aleatorio detectable. Y si tiene dos claves relacionadas (como K ₂ = K ₁ + 1), entonces podría ser vulnerable a un "ataque de clave relacionado". Los cifrados de bloque normalmente no están diseñados para ser utilizados de esa manera. ^*

Puedes probar una relación de clave más complicada, pero si las claves no se derivan usando Una función criptográfica (que aparece al azar para todos los propósitos prácticos) entonces puede haber un problema. O uno podría generar una nueva clave de 128 bits por cada bloque de 128 bits, pero no gana mucho. ^**

_{^{* Ver: "modelo estándar" vs. "modelo ideal" de cifrados de bloque. También hay cifrados de bloque modificables, pero fuera de Skein y el cifrado de disco probablemente no se utilicen muy a menudo.
** Si tiene un generador seguro de números aleatorios reproducibles, entonces tiene algo que se puede convertir de forma trivial en un cifrado de flujo. Las implementaciones de algoritmos Plus que utilizan la expansión de claves como una optimización tendrían una sobrecarga adicional si las claves se reemplazan por cada bloque.}}

Su modo propuesto es:

$$ C_i = E_ {E_k (\ mathrm {IV} || i)} (P_i) $$

... donde $ E_k (m) $ es la aplicación de cifrado de bloque con la clave $ k $ para ingresar el bloque $ m $ , $ i $ es el contador de bloques, y $ C_i $ y $ P_i $ son los $ i $ th Bloques de texto cifrado y texto simple respectivamente.

Para mí esto se parece a los modos para tweakable cifrados de bloque (TBC) , un tipo extendido de cifrado de bloque que además de la clave convencional y las entradas de mensajes también tienen un argumento de ajuste por cifrado. (Consulte las preguntas y respuestas vinculadas A y A).

En el documento de Liskov, Rivest y Wagner que introdujo la noción de modificable cifrar bloques, encontramos este modo:

Comoloexplicalaleyenda,losvaloresde $ Z_i $ que se usan como ajustes en el cifrado son concatenaciones IV / contador. En la mitad izquierda del diagrama, los bloques de mensajes distintos al último se cifran aplicando el TBC directamente a ellos. (El resto del diagrama muestra el último bloque de mensajes cifrado por un tipo de cifrado de flujo y el cálculo de una etiqueta de autenticación).

Podríamos tomar su idea de derivar una clave para cada bloque de mensaje cifrando un IV y un contador de bloque con una clave maestra y pensar en refactorizarlo en una construcción de un TBC $ E ^ T_k $ fuera de un cifrado de bloque convencional $ E'_k $ :

$$ E ^ T_k (m) = E '_ {E'_k (T)} (m) $$

No sé si es un TBC seguro, pero el documento ofrece esta construcción que no necesita cambiar la clave del cifrado del bloque subyacente (una operación que es costosa con muchos cifrados):

$$ E ^ T_k (m) = E'_k (T \ oplus E'_k (m)) $$

Refactorizando tu modo para usar esa construcción obtendríamos algo como:

$$ C_i = E'_k (IV || i \ oplus E'_k (P_i)) $$

Y me parece que cualquier ataque de texto plano elegido en la confidencialidad de este modo más simple implicaría un ataque correspondiente en TAE, por lo que la seguridad de TAE implicaría la confidencialidad de este modo.

Probablemente debería ir sin decir que tendrías que estar loco para implementar todo esto por tu cuenta.