Un cifrado de flujo es un cifrado de clave simétrica en el que los dígitos de texto plano se combinan con un flujo de dígitos de cifrado pseudoaleatorio (flujo de claves). En un cifrado de flujo, cada dígito de texto sin formato se cifra uno a la vez con el dígito correspondiente del flujo de claves, para dar un dígito del flujo de texto cifrado. Dado que el cifrado de cada dígito depende del estado actual del cifrado, también se conoce como cifrado de estado. En la práctica, un dígito es típicamente un bit y la operación de combinación es un exclusivo-o (XOR).

El funcionamiento del generador de flujo de claves en A5/1, un cifrado de flujo basado en LFSR que se utiliza para cifrar conversaciones de teléfonos móviles.

El flujo de claves pseudoaleatorio se genera típicamente en serie a partir de un valor semilla aleatorio utilizando registros de desplazamiento digitales. El valor semilla sirve como clave criptográfica para descifrar el flujo de texto cifrado. Los cifrados de flujo representan un enfoque diferente del cifrado simétrico al cifrado de bloques. Los cifrados de bloque operan en grandes bloques de dígitos con una transformación fija e invariable. Esta distinción no siempre es clara: en algunos modos de funcionamiento, una primitiva de cifrado de bloque se utiliza de tal manera que actúa eficazmente como un cifrado de flujo. Los cifrados de flujo normalmente se ejecutan a una velocidad mayor que los cifrados de bloque y tienen menor complejidad de hardware. Sin embargo, los cifrados de flujo pueden ser susceptibles a graves problemas de seguridad si se utilizan incorrectamente (como en los ataques de cifrado de flujo); en particular, el mismo estado inicial (semilla) nunca debe usarse dos veces.

Inspiración suelta de la libreta de un solo uso

editar

Los cifrados de flujo se pueden ver como una aproximación a la acción de un cifrado irrompible probado, la libreta de un solo uso (OTP). Un teclado de una sola vez utiliza un flujo de claves de dígitos completamente aleatorios. El flujo de claves se combina con los dígitos de texto plano uno a la vez para formar el texto cifrado. Claude E. Shannon demostró que este sistema era seguro en 1949. Sin embargo, el flujo de claves debe generarse completamente al azar con al menos la misma longitud que el texto sin formato y no se puede usar más de una vez. Esto hace que el sistema sea complicado de implementar en muchas aplicaciones prácticas y, como resultado, la almohadilla de un solo uso no se ha utilizado ampliamente, excepto en las aplicaciones más críticas. La generación, distribución y gestión de claves son fundamentales para esas aplicaciones.

Un cifrado de flujo utiliza una clave mucho más pequeña y conveniente, como 128 bits. Basado en esta clave, genera una secuencia de claves pseudoaleatoria que se puede combinar con los dígitos de texto sin formato de una manera similar al pad de un solo uso. Sin embargo, esto tiene un costo. El flujo de claves ahora es pseudoaleatorio y, por lo tanto, no es verdaderamente aleatorio. La prueba de seguridad asociada con la libreta de un solo uso ya no es válida. Es muy posible que un cifrado de flujo sea completamente inseguro.

Un cifrado de flujo genera elementos sucesivos del flujo de claves en función de un estado interno. Este estado se actualiza esencialmente de dos maneras: si el estado cambia independientemente de los mensajes de texto sin formato o de texto cifrado, el cifrado se clasifica como un cifrado de flujo síncrono . Por el contrario, los cifrados de flujo de sincronización automática actualizan su estado en función de los dígitos del texto cifrado anterior.

Cifrados de flujo sincrónico

editar
 
Máquina de cifrado Lorenz SZ utilizada por el ejército alemán durante la Segunda Guerra Mundial

En un cifrado de flujo síncrono, se genera un flujo de dígitos pseudoaleatorios independientemente del texto plano y los mensajes de texto cifrado, y luego se combina con el texto plano (para cifrar) o el texto cifrado (para descifrar). En la forma más común, se utilizan dígitos binarios (bits) y el flujo de claves se combina con el texto sin formato utilizando la operación exclusiva o (XOR). Esto se denomina cifrado de flujo aditivo binario.

En un cifrado de flujo síncrono, el remitente y el receptor deben estar exactamente en el mismo paso para que el descifrado sea exitoso. Si se agregan o eliminan dígitos del mensaje durante la transmisión, se pierde la sincronización. Para restaurar la sincronización, se pueden probar varias compensaciones de forma sistemática para obtener el descifrado correcto. Otro enfoque es etiquetar el texto cifrado con marcadores en puntos regulares de la salida.

Sin embargo, si un dígito se corrompe durante la transmisión, en lugar de agregarse o perderse, solo un dígito del texto sin formato se ve afectado y el error no se propaga a otras partes del mensaje. Esta propiedad es útil cuando la tasa de errores de transmisión es alta; sin embargo, hace menos probable que el error se detecte sin más mecanismos. Además, debido a esta propiedad, los cifrados de flujo síncronos son muy susceptibles a ataques activos: si un atacante puede cambiar un dígito en el texto cifrado, podría realizar cambios predecibles en el bit de texto plano correspondiente; por ejemplo, voltear un bit en el texto cifrado hace que el mismo bit se invierta en el texto sin formato.

Cifrados de flujo de sincronización automática

editar

Otro enfoque utiliza varios de los N dígitos de texto cifrado anteriores para calcular el flujo de claves. Estos esquemas se conocen como cifrados de flujo de sincronización automática, cifrados de flujo asíncronos o clave automática de texto cifrado (CTAK). La idea de la autosincronización se patentó en 1946 y tiene la ventaja de que el receptor se sincronizará automáticamente con el generador de flujo de claves después de recibir N dígitos de texto cifrado, lo que facilita la recuperación si se eliminan o se agregan dígitos al flujo de mensajes. Los errores de un solo dígito tienen un efecto limitado y solo afectan hasta N dígitos de texto sin formato.

Un ejemplo de un cifrado de flujo auto-sincronización es un cifrado de bloques en modo de la retroalimentación de cifrado (CFB).

Basado en registros de desplazamiento de retroalimentación lineal

editar

Los cifrados de flujo binario a menudo se construyen utilizando registros de desplazamiento de retroalimentación lineal (LFSR) porque se pueden implementar fácilmente en hardware y se pueden analizar matemáticamente fácilmente. Sin embargo, el uso de LFSR por sí solos es insuficiente para proporcionar una buena seguridad.[1][2]​ Se han propuesto varios esquemas para aumentar la seguridad de las LFSR.

Funciones de combinación no lineales

editar
 
Un enfoque consiste en utilizar n LFSR en paralelo, combinando sus salidas mediante una función booleana binaria de n entradas (F).

Debido a que los LFSR son inherentemente lineales, una técnica para eliminar la linealidad es alimentar las salidas de varios LFSR paralelos en una función booleana no lineal para formar un generador de combinación. Varias propiedades de dicha función de combinación son críticas para garantizar la seguridad del esquema resultante, por ejemplo, para evitar ataques de correlación.

Generadores controlados por reloj

editar

Normalmente, los LFSR se escalonan con regularidad. Un enfoque para introducir la no linealidad es hacer que el LFSR se sincronice de manera irregular, controlado por la salida de un segundo LFSR. Dichos generadores incluyen el generador de parada y arranque , el generador de pasos alternos y el generador de contracción .

Un generador de pasos alternos comprende tres LFSR, que llamaremos LFSR0, LFSR1 y LFSR2 por conveniencia. La salida de uno de los registros decide cuál de los otros dos se utilizará; por ejemplo, si LFSR2 emite un 0, LFSR0 se sincroniza, y si emite un 1, LFSR1 se sincroniza en su lugar. La salida es el OR exclusivo del último bit producido por LFSR0 y LFSR1. El estado inicial de los tres LFSR es la clave.

El generador intermitente (Beth y Piper, 1984) consta de dos LFSR. Un LFSR se sincroniza si la salida de un segundo es 1, de lo contrario, repite su salida anterior. Luego, esta salida se combina (en algunas versiones) con la salida de un tercer LFSR sincronizado a una velocidad regular.

El generador de contracción adopta un enfoque diferente. Se utilizan dos LFSR, ambos cronometrados regularmente. Si la salida del primer LFSR es 1, la salida del segundo LFSR se convierte en la salida del generador. Sin embargo, si el primer LFSR genera 0, la salida del segundo se descarta y el generador no genera ningún bit. Este mecanismo sufre de ataques de sincronización en el segundo generador, ya que la velocidad de la salida es variable de una manera que depende del estado del segundo generador. Esto se puede aliviar almacenando la salida en búfer.

Generador de filtros

editar

Otro enfoque para mejorar la seguridad de un LFSR es pasar todo el estado de un solo LFSR a una función de filtrado no lineal.

Otros diseños

editar
 
RC4 es uno de los diseños de cifrado de flujo más utilizados.

En lugar de un dispositivo de conducción lineal, se puede utilizar una función de actualización no lineal. Por ejemplo, Klimov y Shamir propusieron funciones triangulares (funciones T) con un solo ciclo en palabras de n bits.

Seguridad

editar

Para que un cifrado de flujo sea seguro, su flujo de claves debe tener un período largo y debe ser imposible recuperar la clave del cifrado o el estado interno del flujo de claves. Los criptógrafos también exigen que el flujo de claves esté libre de sesgos incluso sutiles que permitan a los atacantes distinguir un flujo de ruido aleatorio, y libre de relaciones detectables entre flujos de claves que correspondan a claves relacionadas o nones criptográficos relacionados. Eso debería ser cierto para todas las claves (no debería haber claves débiles), incluso si el atacante puede saber o elegir algún texto plano o cifrado.

Al igual que con otros ataques en criptografía, los ataques de cifrado de flujo pueden ser de certificación, por lo que no son necesariamente formas prácticas de romper el cifrado, pero indican que el cifrado podría tener otras debilidades.

El uso seguro de un cifrado de flujo síncrono seguro requiere que nunca se reutilice el mismo flujo de claves dos veces. Eso generalmente significa que se debe proporcionar un nonce o clave diferente para cada invocación del cifrado. Los diseñadores de aplicaciones también deben reconocer que la mayoría de los cifrados de flujo brindan no autenticidad sino privacidad : es posible que los mensajes cifrados se hayan modificado en tránsito.

Los períodos cortos para los cifrados de flujo han sido una preocupación práctica. Por ejemplo, los cifrados de bloque de 64 bits como DES se pueden utilizar para generar un flujo de claves en el modo de retroalimentación de salida (OFB). Sin embargo, cuando no se utiliza la retroalimentación completa, el flujo resultante tiene un período de alrededor de 232 bloques en promedio; para muchas aplicaciones, el período es demasiado bajo. Por ejemplo, si el cifrado se realiza a una velocidad de 8 megabytes por segundo, se repetirá una secuencia de bloques de período 232 después de aproximadamente media hora.[cita requerida]

Algunas aplicaciones que utilizan el cifrado de flujo RC4 son atacables debido a debilidades en la rutina de configuración de claves de RC4; las nuevas aplicaciones deben evitar RC4 o asegurarse de que todas las claves sean únicas e idealmente no relacionadas (como las generadas por un CSPRNG bien sembrado o una función hash criptográfica) y que los primeros bytes del flujo de claves se descarten.

Los elementos de los cifrados de flujo suelen ser mucho más sencillos de entender que los cifrados de bloque y, por lo tanto, es menos probable que oculten debilidades accidentales o maliciosas.

Los cifrados de flujo se utilizan a menudo por su velocidad y simplicidad de implementación en hardware y en aplicaciones donde el texto sin formato viene en cantidades de longitud desconocida, como una conexión inalámbrica segura. Si se usara un cifrado de bloque (que no opera en un modo de cifrado de flujo) en este tipo de aplicación, el diseñador debería elegir entre la eficiencia de transmisión o la complejidad de implementación, ya que los cifrados de bloque no pueden trabajar directamente en bloques más cortos que su tamaño de bloque. Por ejemplo, si un cifrado de bloque de 128 bits recibe ráfagas de texto sin formato de 32 bits, tres cuartas partes de los datos transmitidos serían de relleno. Los cifrados de bloque se deben utilizar en el robo de texto cifrado o en la terminación de bloque residual modo para evitar el relleno, mientras que los cifrados de flujo eliminan este problema al operar naturalmente en la unidad más pequeña que se puede transmitir (generalmente bytes).

Otra ventaja de los cifrados de flujo en la criptografía militar es que el flujo de cifrado se puede generar en una caja separada que está sujeta a estrictas medidas de seguridad y se alimenta a otros dispositivos, como un aparato de radio, que realizará la operación xor como parte de su función. Este último dispositivo se puede diseñar y utilizar en entornos menos estrictos.

ChaCha se está convirtiendo en el cifrado de flujo más utilizado en software;[3]​ otros incluyen: RC4, A5/1, A5/2, Chameleon, FISH, Helix, ISAAC, MUGI, Panama, Phelix, Pike, Salsa20, SEAL, SOBER, SOBER-128, y WAKE.

Comparación

editar
Cifrado de flujo Año de creación Velocidad (ciclos por byte) (bits) Ataque
Longitud de clave efectiva Vector de inicialización Estado interno Más conocido Complejidad computacional
A5/1 1989 54 o 64 (in 2G) 22 (en 2G) 64 Compensación de tiempo-memoria activa de KPA o KPA ~ 2 segundos o 239.91
A5/2 1989 54 114 64? Active 4.6 milisegundos
Achterbahn-128/80 2006 1 (hardware) 80/128 80/128 297/351 Fuerza bruta para longitudes de bastidor L  ≤ 244.

Ataque de correlación para L  ≥ 248.

280 resp. 2128 para L ≤ 244.
CryptMT 2005 Variable hasta 19968 19968 (2008) (2008)
FISH 1993 Variable Ataque conocido de texto plano (KPA) 211
Grain Pre-2004 80 64 160 Derivación de claves 243
HC-256 Pre-2004 4 (WP4) 256 256 65536
ISAAC 1996 2.375 (W64-bit)
4.6875 (W32-bit)
8–8288
(generalmente 40–256)
8288 (2006)

Derivación de estado interno débil de primera ronda

4.67×101240 (2001)
MUGI 1998–2002 128 128 1216 (2002) ~ 282
PANAMA 1998 2 256 128? 1216? Colisiones hash (2001) 282
Phelix Pre-2004 up to 8 (Wx86) 256 + un nonce de 128-bits 128? Diferencial (2006) 237
Pike 1994 Variable (2004) (2004)
Py Pre-2004 2.6 8–2048?
(generalmente 40–256?)
64 8320 Teoría criptoanalítica (2006) 275
Rabbit 2003-Feb 3.7(WP3) – 9.7(WARM7) 128 64 512 (2006) (2006)
RC4 1987 7 WP5[nota 1] 8–2048
(generalmente 40–256)
RC4 no toma una IV. Si se desea una IV, se debe mezclar con la clave de algún modo. 2064 Derivación de claves de bytes iniciales de Shamir o KPA 213 OR 233
Salsa20 Pre-2004 4.24 (WG4)
11.84 (WP4)
256 un nonce de 64 bits + una posición de transmisión de 64 bits 512 Método probabilístico de bits neutrales 2251 para 8 rondas (2007)
Scream 2002 4–5 (Wsoft) 128 + un nonce de 128-bits 32? Función redonda de 64 bits
SEAL 1997 32?
SNOW Pre-2003 128 o 256 32
SOBER-128 2003 hasta 128 Fragua de mensajes 2−6
SOSEMANUK Pre-2004 128 128
Trivium Pre-2004 4 (Wx86)
8 (WLG)
80 80 288 Ataque de fuerza bruta (2006) 2135
Turing 2000–2003 5.5 (Wx86) 160
VEST 2005 42 (WASIC)
64 (WFPGA)
Variable
(generalmente 80–256)
Variable
(generalmente 80–256)
256–800 (2006) (2006)
WAKE 1993 8192 CPA & CCA Vulnerable
Cifrado de flujo Año de creación Velocidad (ciclos por byte) (bits) Attack
Longitud de clave efectiva Vector de inicialización Estado interno Más conocido Complejidad computacional

Trivia

editar

Véase también

editar
  1. P. Prasithsangaree and P. Krishnamurthy (2003). Analysis of Energy Consumption of RC4 and AES Algorithms in Wireless LANs. Archivado desde el original el 3 de diciembre de 2013. 

Referencias

editar
  1. Beth, T.; Piper, F. C. (1985). «The Stop-and-Go-Generator». En Beth, Thomas, ed. Advances in Cryptology. Lecture Notes in Computer Science (en inglés) (Springer): 88-92. ISBN 978-3-540-39757-1. doi:10.1007/3-540-39757-4_9. Consultado el 26 de enero de 2021. 
  2. «Understanding Cryptography, A Textbook for Students and Practitioners…». archive.is. 8 de diciembre de 2012. Archivado desde el original el 8 de diciembre de 2012. Consultado el 26 de enero de 2021. 
  3. https://blog.cloudflare.com/do-the-chacha-better-mobile-performance-with-cryptography/

Enlaces externos

editar

En inglés: