Autor Tema: Algoritmo criptográfico

0 Usuarios y 1 Visitante están viendo este tema.

21 Diciembre, 2006, 04:30 pm
Leído 5562 veces

KaStarKo

  • $$\Large \color{#6a84c0}\pi$$
  • Mensajes: 23
  • Karma: +0/-0
Hola, imaginemos que tenemos un mensaje compuesto por los bloques A y B. Tenemos además una clave compuesta por los bloques Ka y Kb .

Y quiero obtener un mensaje cifrado compuesto por los bloques Ca y Cb . Una manera de proceder sería la siguiente:

Ca = A xor Ka
Cb = B xor Kb

¿Cuál es el problema de este sistema? pues que si se tiene conocimiento sobre el contenido de uno de esos bloques, se puede obtener una parte de la clave.

Veamos, yo soy un "enemigo" que intercepta el mensaje cifrado compuesto por Ca y Cb . Pero tengo la suerte de conocer A (no conozco B). Automáticamente podré obtener Ka, haciendo Ka = A xor Ca

Esto puede parecer extraño... ¿para qué quiero la clave que cifra A si ya conozco A? pues porque normalmente la clave es menor que el mensaje, y si el mensaje esta compuesto por más bloques, la contraseña se volverá a aplicar tal cual en algún momento, es decir, podré obtener el valor de otro bloque de texto sólo conociendo A.

¿Qué puedo hacer para dificultar eso?

Pues fijémonos en que los bloques se pueden representar en base binaria (que es lo que he hecho para aplicar xor, y lo que hacen los ordenadores para tratarlos), ahora podemos ver que si permutamos los ceros y unos del mensaje, la cantidad de ceros y unos no variará...

Pues bien, lo que hago es permutar los bits de A en función del bloque B y viceversa. De manera que podré recuperar A y B, el cambio es invertible... Pero el atacante ahora no sabe qué forma tendrá el bloque A! por lo tanto no podrá aplicar el ataque explicado anteriormente...

El problema es que sólo se pueden hacer nueve permutaciones con este sistema, porque sólo hay 9 posibilidades, B tiene 0 unos, 1 uno, 2 unos, 3 unos, 4 unos, 5 unos, 6 unos, 7 unos, o 8 unos. La seguridad aumenta bien poco...

¿Qué hago? puedo hacer A <- A xor B pero entonces no podré aplicar la misma protección a B... pues hago lo siguiente!

hago A <- A xor B , entonces permuto A en función de B, y B lo permuto en función de A(de la nueva A, que tiene tantos unos activados como el antiguo (A xor B)) . Bueno, ahora vemos que para cada B diferente tenemos un nuevo bloque A diferente.

Pero B no está tan protegido... pues hacemos lo mismo al revés después de haber aplicado eso...

Así que tenemos:
Ao = A
B0 = A
A1 = (A xor B) permutado en función de B
B1 = B permutado en función de (A xor B)
A2 = A1 permutado en función de (A1 xor B1)
B2 = (A1 xor B1) permutado en función de B1

Esta permutación de la que hablo se puede hacer mediante un algoritmo o mediante tablas... he comprobado que hacer un algoritmo tan "seguro" como las tablas es complicado (pero posible, el problema es que las tablas se tienen que escoger con cierto cuidado).

Las tablas tienen un tamaño de (2 elevado a la cantidad de bits del bloque) multiplicado por 9 . Como yo tenía bloques de un byte, tengo 256 x 9 = 2304 entradas en esa tabla.

Bueno, el cómo se hacen las permutaciones es lo de menos, podría hacerse mediante una función o mediante tablas.

Después de hacer eso aplico el xor con las claves... pero hay un problema... cuando A o B son todo ceros o unos... las permutaciones no hacen nada, y la clave es igual de recuperable...

Así que para evitar eso, hago lo siguiente:

Ca = (A xor Ka) permutado en función de Kb
Cb = (B xor Kb) permutado en función de Ka

En esos casos entonces ya no se puede recuperar la clave tan fácilmente... pero.. sigue habiendo un problema! i gordo. Si se conocen A y B y  los dos tienen o todo ceros o todo unos (A i B de forma independiente, quiero decir, que si A tiene todo ceros y B todo unos, es igual de inseguro) las claves Ka y Kb se pueden seguir recuperando :(

¿Y qué hacemos? puesaquí a mí se me acabaron las ideas... así que decidí aplicar una segunda ronda de cifrado con otras dos subclaves Ka2 y Kb2 . Pero me gustaría poder arreglarlo sin recurrir a un segundo par de subclaves...

Bueno, supongamos ese problema solucionado, sigue habiendo problemas.... Y es que aunque hayamos conseguido cifrar con éxito un bloque de 2 bytes, el texto entero sigue siendo débil a criptoanálisis estadístico. Si se conoce la lengua usada en ese lenguaje se pueden conocer los pares de letras más probables, así que si tenemos pares de letras cifradas muy frecuentes es muy probable que se correspondan con un par muy frecuente en ese lenguaje...

Que hago? Pues hago que a cada bloque se usen subclaves distintas... pero.. no quiero caer en el error de necesitar una clave tan larga como el mensaje, pues sería tan inseguro transmitir la clave como el propio mensaje!

Me decido por tener 4 claves diferentes, cada bloque la cambio, pero cada 4 bloques vuelvo a aplicar la primera... eso sigue siendo débil frente a criptoanálisis estadístico... pero.. a ver, 4 bloques de 2 bytes hacen un total 8 bytes, encontrar probabilidades en conjuntos de ocho letras es un problema ya harto difícil de resolver... así que ya podemos considerar este cifrado mínimamente seguro con una clave de 128 bits.  128 = (32)x4 = (16x2)x4=(8x2x2)x4 ... :P Bueno, eso esta claro, jeje. No pretendo enseñaros a multiplicar, xD. Sólo mostraba de donde salían los 128 bits de la clave.

El caso es que este cifrado se puede mejorar. Y lo hago de la forma siguiente:
Tengo un registro de 2 bytes (16 bits) que va cambiando a lo largo del cifrado de forma que varía en función de los valores del texto plano, antes de cifrar cada bloque hago un xor entre el texto plano y ese registro (guardándolo en el texto plano, no en el registro), luego aplico el cifrado sobre eso, el caso es que como el registro depende de todo el texto anterior, no hay suficiente con conocer el texto plano en ese punto para intentar averiguar la subclave en ese punto. ¿Y cómo hago variar el registro?

A ver, lo que hago es hacer un xor entre el registro y el segundo par de claves usado en ese bloque. Luego lo cifro como antes, pero cifrandolo con el primer par de claves usado en ese bloque, y finalmente, hago una segunda ronda cifrando eso con el texto plano. Como vemos el registro depende fuertemente de todo el texto anterior.

Ahora mis problemas son los siguientes: Demostrar que este cifrado no tiene estructura de grupo... (sin tener en cuenta lo del registro ni lo de la segunda ronda), porque si no, la segunda ronda no tendría ningún sentido, pues seria equivalente cifrar 2 veces con dos claves a cifrar 1 vez con otra clave... yo lo he probado para bloques de 3 bits (bueno, bloques de 6 bits formados por 2 de 3), pero no sé cómo probarlo (o refutarlo) para el caso general de n bits.

¿Son iguales de seguras todas las permutaciones que yo pueda hacer? ¿Es preferible usar tablas o una función? ¿Cualquier tabla que escriba la puedo implementar en forma de función?