Cifrado en Flujo Autentificado

El Cifrado en Flujo Autentificado adopta las mismas premisas que el cifrado en Bloque Autentificado, se basan en un cifrado subyacente apoyado por mecanismos de autentificación. El inconveniente de este enfoque es que no se puede reducir la seguridad del esquema a un problema conocido como, “indistinguible” que aportan los cifrados en bloque con las permutaciones aleatorias. Describimos dos esquemas que fueron diseñados por criptógrafos que enfocaron su trabajo hacia la seguridad y la eficiencia de los cifrados.

 

HELIX – Phelix.

Fast Encryption and Authentication in a Single Cryptographic Primitive, fue diseñado por Niels Ferguson, Doug Whiting, Bruce Schneier, John Kelsey, Stefan Lucks y Tadayoshi Kohno en 2.003. Su objetivo era producir un cifrado de flujo rápido, con una funcionalidad MAC incorporada, simple y sin patentes. Las primeras pruebas publicadas fueron sobre un Pentium II siendo el doble de rápido que Rijndael ó Twofish y comparable en velocidad a RC4, está optimizado para equipos de 32 bits. La sobrecarga por mensaje cifrado / autentificado es baja, por lo que es adecuada para mensajes pequeños. Es eficiente tanto en hardware como en software y con algunos cálculos previos, puede cambiar efectivamente las claves por mensaje sin una sobrecarga adicional.

 

Helix puede usarse como cifrado de flujo puro al ignorar los cálculos de MAC al final. Y como cualquier cifrado de flujo, es un generador de números casi aleatorios criptográficamente fuerte. Para cada entrada (clave, “nonce” N) produce un flujo de datos casi aleatorios. Esto hace que también sea adecuado para su uso como PRNG.

 

Helix toma una clave K de hasta 32 bytes de longitud, una “nonce” N de 16 bytes y un mensaje M ∈ (Σ8). Solo utiliza algunas operaciones simples: Módulo 232, XOR de cadenas de 32 bits, y rotaciones a nivel de bits.  Sin embargo cada iteración de Helix, denominada “bloque”, utiliza 11 XOR, 12 adiciones modulares y 20 rotaciones a nivel de bits por cantidades fijas de 32 bits, con una longitud de 128 bits. Así que no es tan fácil aplicarlo.

 

El equipo desarrolló su algoritmo para procesardores Intel, ampliando lo dicho anteriormente sobre rendimientos:

  • Velocidades de aproximadamente 7 ciclos por byte, comparado con AES es bastante más rápido, AES se ejecuta aproximadamente a 15 ciclos por byte.
  • AES realiza aproximadamente 160 búsquedas de tablas y 160 XOR de 32 bits para cifrar 16 bytes. Esto significa que AES utiliza aproximadamente 10 consultas y 10 XOR por byte.
  • Helix utiliza más operaciones, pero con una diferencia clave, AES realiza búsquedas de memoria en tablas, mientras que Helix limita su trabajo al archivo de registro.

 

En 2.004 Frédéric Muller publicó dos ataques contra Helix, el primero demostró que la clave se puede recuperar más rápido que con la fuerza bruta si el atacante puede forzar el uso de los “nonce” ó Vector de Inicialización (IV), más de una vez. El ataque requiere aproximadamente 212 palabras de texto sin formato elegidas de forma adaptativa y 288 operaciones. Más tarde Souradyuti Paul y Bart Preneel demostraron, en dos ocasiones, que los ataques de Muller podían reducirse utilizando algoritmos que desarrollaron para resolver ecuaciones diferenciales de adición y que además, el ataque anterior podía implementarse con texto claro seleccionado con una complejidad de datos de 235,64.

 

A partir de esta problemática, Doug Whiting, Bruce Schneier, Stefan Lucks y Frédéric Muller modificaron Helix para agregar 128 bits al estado interno, denominándolo Phelix.

 

Encryption in HELIX PHELIX Authenticated Flow - Cifrado en flujo Autentificado HELIX PHELIX

En 2.006 Hongjun Wu y Bart Preneel  demuestran que Phelix es vulnerable a un ataque de recuperación de clave y que la complejidad computacional del ataque es mucho menor que la del ataque contra Helix.

Tanto en Helix como en Phelix el texto simple se usa para afectar el estado interno del cifrado. Para lograr alta velocidad, en el cifrado, utiliza el texto sin formato afectando a la secuencia de claves sin pasar por suficientes capas de confusión y difusión. Esta es la debilidad intrínseca en la estructura de Helix y Phelix, además de otros cifradores.

 

Proponen que la seguridad del cifrado se puede mejorar si se utiliza una función segura de una sola vía para generar el estado inicial del cifrado desde la clave y el “nonce”. Entonces, incluso si se recupera el estado interno de un “nonce” en particular, el impacto en la seguridad del cifrado es muy limitado ya que la clave del cifrado no se ve afectada. Creemos que este enfoque puede aplicarse para mejorar la seguridad de todos los cifrados que utilizan el texto plano para afectar el estado interno. Sin embargo, no mejora significativamente la seguridad del MAC en Helix y Phelix. Una vez que se recupera un estado interno, el atacante puede falsificar muchos mensajes relacionados con ese punto en particular.

 

 

 

SOBER-128.

La primera versión fue propuesta por G. Rose en 1.998 como un algoritmo basado en operaciones de 8 bits, en 2.003 junto con P. Hawkes desarrollan una nueva versión para operaciones de 32 bits, denominada SOBER-128. La nueva versión conserva muchas de esas características pero también introduce un método para autenticar mensajes.Encryption in SOBER Authenticated Flow - Cifrado en flujo utentificado SOBER

 

SOBER-128 es un cifrador de flujo orientado a software que utiliza un registro de desplazamiento de retroalimentación lineal (LFSR) sobre GF (232) en combinación con varios componentes de filtrado no lineal (NLF) con adiciones módulo 232, XOR, desplazamiento circular y sustitución de 8 X 32 bits en una caja S diseñada en su núcleo. Se agrega una función de retroalimentación no lineal de texto plano (PFF) cuando se requieren autentificación y cifrado.

 

Konst depende solo de la clave y es independiente del vector de Inicialización (IV). No cambia después de la inicialización, por lo que podemos considerar que es una constante dependiente de la clave.

 

Cuando se utiliza para AE, primero se genera una secuencia de claves utilizada para hacer un XOR con el mensaje Tc, luego usa una llamada a un API denominada “maconly” para procesar los datos asociados. Al igual que Helix, también retroalimenta el texto plano en el generador de flujo de claves. Las pruebas realizadas por Hawkes y Rose indicaron que tiene una velocidad comparable a la de Helix.

 

En 2.004 Dai Watanabe, Soichi Furuya y Toshinobu Kaneko demostraron que la función de generación de MAC y la función de cifrado autentificado es vulnerable bajo el supuesto de que el atacante intercepta el mensaje, cambia algunos bits del mensaje y lo envía al receptor, es este caso, el atacante puede falsificar un mensaje con probabilidad 2−6 y 2−27 respectivamente.