RC4

[criptógrafo]

Sres. foristas,



Se comenta que el algoritmo RC4 actualmente ya no es un cifrado de flujo seguro. Pero, ¿realmente es que RC4 no es seguro o en realidad es porque se está usando mal al no usar claves diferentes en cada mensaje?

Hay alguna debilidad del RC4 que se soluciona dropeando los primeros bytes. ¿Esto no es suficiente para que sea seguro?

Personalmente hay una cosa que no me gusta del RC4: el manejo de la clave. En el vector K, si la clave es menor de 256 bytes, se repite la clave hasta completar las 256 bytes. Pero entonces con diccionarios se puede atacar fácilmente. Claro que tal vez es que el RC4 presupone que la clave que recibe es muy robusta (por ejemplo ya salada y hasheada), que la responsabilidad de clave fuerte no es del RC4 sino del programa que le envíe la clave.

¿Qué me podéis decir al respecto?



Gracias.

[criptógrafo]

Otra pregunta.

Por favor, leed esta frase:
"En 1995, Andrew Roos observó experimentalmente que el primer byte de la cadena de claves se correlaciona con los primeros tres bytes de la clave".

¿Qué quiere decir esto? ¿Qué en cualquier combinación de los 3 primeros bits de la clave (000, 001, 010, etc ...), la probabilidad de que el 1r bit de la cadena de claves que genera sea 0 no es de un 50%?

¿Alguien me lo puede confirmar?

¿Y esto como se comprueba? ¿Generando al azar 1000 claves al azar cuyos primeros 3 dígitos son 000 y ver la probabilidad de que el primer bit de la cadena de claves sea cero, y repetir los mismo, con el resto de combinaciones (001, 010, etc ...)?

Gracias.

[cpu2]

Otra pregunta.

Por favor, leed esta frase:
"En 1995, Andrew Roos observó experimentalmente que el primer byte de la cadena de claves se correlaciona con los primeros tres bytes de la clave".

¿Qué quiere decir esto? ¿Qué en cualquier combinación de los 3 primeros bits de la clave (000, 001, 010, etc ...), la probabilidad de que el 1r bit de la cadena de claves que genera sea 0 no es de un 50%?

https://www.imperva.com/docs/HII_Attacking_SSL_when_using_RC4.pdf

La pag 3 de este documento puede interesarte.

Un saludo.

[criptógrafo]

Gracias, cpu2.



Otra pregunta. ¿Por que cuando se dropea bytes, el número de bytes dropeados es múltiplo de 256 fijo? ¿Hay alguna razón criptográfica para ello?

Lo pregunto porque si da igual que los bytes drapeados sean múltiplos, o no, de 256, se podría usar una pimienta. Por ejemplo, se podría dropear n * 256 + pimienta, donde n es fijo y pimienta es un número al azar del 0 al 255 (o del 0 al 511, etc ...) desconocido. No sé si eso haría más seguro, o no, el RC4.

Otra consideración es que el vector inicial S, en lugar de inicializarlo con la serie 0, 1, 2, ..., 256, inicializarlo con una permutación al azar (o sea, sin ninguna relación con la clave). Tampoco sé si esto haría más seguro, o no, el RC4.

Y muchas ideas más para mejorar el RC4, ...



Saludos.

[cpu2]

Nunca profundice el algoritmo RC4, el motivo te lo dire mas abajo. Yo lo que pienso sobre el tema de 256 que comentas, es por el primer algoritmo que toma todas las posibles permutaciones de 256 bytes, cuando se hace un swap a S se le hace el mod 256, lo mas seguro es que sea ese el motivo.

Como te comente arriba, hablo un poco desde lo superficial, si quieres saberlo al 100% lee el pdf que explica hasta el ultimo punto de rc4.

Otra consideración es que el vector inicial S, en lugar de inicializarlo con la serie 0, 1, 2, ..., 256, inicializarlo con una permutación al azar (o sea, sin ninguna relación con la clave). Tampoco sé si esto haría más seguro, o no, el RC4.

Y muchas ideas más para mejorar el RC4, ...

Desde mi punto de vista, no perderia ni un minuto en un algoritmo que ya a sido vulnerado, como puedes ver en el protocolo WEP.

Para que vas a mejorar rc4, teniendo rc5, y bueno te diria que dejases rc5, existe rc6.

Un saludo.

[criptógrafo]

un algoritmo que ya a sido vulnerado, como puedes ver en el protocolo WEP.

Gracias, cpu2.



Por lo quede leído, en otras paginas web, que el problema no está en el algoritmo RC4 sino en el protocolo WEP:

El principal problema radica en que no implementa adecuadamente el vector de iniciación del algoritmo RC4, ya que utiliza un enfoque directo y predecible para incrementar el vector de un paquete a otro. Además existe un problema con el tamaño de los vectores de iniciación. A pesar de que se pueden generar muchos vectores, la cantidad de tramas que pasan a través de un punto de acceso es muy grande, lo que hace que rápidamente se encuentren dos mensajes con el mismo vector de iniciación. Conociendo los IV utilizados repetidamente y aplicando técnicas relativamente simples de descifrado puede finalmente vulnerarse la seguridad implementada. Aumentar los tamaños de las claves de cifrado aumenta el tiempo necesario para romperlo, pero no resulta imposible el descifrado.

Saludos.

[Serapis]

Si manejas bytes y sumas los valores de 2 bytes, como resultado obtienes o un valor de un byte o un valor superior al límite de un byte, luego si haces un modulo 256 (o and 255), sigues teniendo un valor en el rango de byte.

El array de semila posee 256 bits, luego a un nivel distinto, necesita hacer lo mismo... cada vez que se alcanza el bit 256º operando sobre la semilla, debe regresar al bit 1º...

[criptógrafo]

Si manejas bytes y sumas los valores de 2 bytes, como resultado obtienes o un valor de un byte o un valor superior al límite de un byte, luego si haces un modulo 256 (o and 255), sigues teniendo un valor en el rango de byte.

El array de semila posee 256 bits, luego a un nivel distinto, necesita hacer lo mismo... cada vez que se alcanza el bit 256º operando sobre la semilla, debe regresar al bit 1º...

Gracias, NEBIRE.



Supongo que tu aporte es para responder a esta pregunta:

¿Por que cuando se dropea bytes, el número de bytes dropeados es múltiplo de 256 fijo? ¿Hay alguna razón criptográfica para ello?

Pero no veo que el motivo que indicas justifique que necesariamente el número de bytes a dropear sea múltiplo de 256. El número podría ser un múltiplo de 256 fijo más pimienta (un número entero al azar entre cero y 255, que no se guarde en ningún lugar).

No obstante, dudo que esta medida haga mejorar, de manera significativa, la seguridad del RC4, ya que aunque no se sepa cuantos bytes son dropeados, habrá correlación de los primeros bytes de emitidos respecto a los primeros bytes de la clave introducida por el usuario. Bueno, es cuestión de probar, ...




Saludos.

[criptógrafo]

Sres. foristas,



Como he compartido antes en este hilo, Andrew Ross observó una correlación estadística entre el primer byte emitido y los tres primeros bytes de la clave. Y esta correlación se demostró teóricamente. Yo creo que la causa de esta correlación está, en el algoritmo KSA.

El algoritmo KSA del RC4 es el siguiente:

Código [Seleccionar] Expandir


j = 0;
for i = 0 to 255
{
  j = (j +S[i] + K[i]) mod 256;
  intercambia S[i] and S[j];
}


El primer intercambio del algoritmo KSA es el siguiente:
Incialmente este algoritmo asigna a j valor 0 + S[0] +K[0] = K[0], ya que S[0] = 0 inicialmente. Entonces intercambian S[0] con S[K[0]], con lo cual S[0] pasa a tener valor K[0] y S[k[0]] pasa a tener valor cero.

Luego, puede ser, o no, que el valor se S[0] sea nuevamente intercambiado. Y como el algoritmo KSA no garantiza que el valor S[0] sea nuevamente intercambiado, podemos afirmar, que una vez ejecutado el algoritmo KSA, lo siguiente:
Probabilidad(S[0] = K[0]) > 1 / 256
Y, entonces, ello representa una debilidad (como corolario de los postulados de Golomb).

Esa debilidad es muy fácil de resolver: Por ejemplo, en lugar de inicializar la j con valor cero, inicializarla son un entero al azar entre cero y 255. Este valor debe ser pimienta (nunca sal), y, de esta manera, una vez ejecutado el algoritmo KSA, la Probabilidad(S[0] = K[0]) = 1 / 256, que es como debe de ser según los postulados de Golomb).

O sea, que propongo como algoritmo KSA del RC4, el siguiente:

Código [Seleccionar] Expandir


j = entero al azar entre cero y 255;
for i = 0 to 255
{
  j = (j + S[i] + K[i]) mod 256;
  intercambia S[i] and S[j];
}



Yo creo que ese cambio es pequeño pero muy potente para eliminar las correlaciones entre los primeros bytes de la clave y los primeros bytes emitidos por el RC4. ¿Estáis de acuerdo con mi afirmación?



Gracias.