Buenas, aprovechando ambos retos quiero lanzarme al mundo del criptoanálisis y demás cuestiones, pero no se ni por donde empezar, ¿alguna recomendacion? (tengo el cryptool por si ayuda), admin si ves más correcto mover este comentario adelante :)

Anda es verdad: donde hay la secuencia arroba punto, mete un enlace, también me pasa en el artículo de TRFR 2.0, precisamente el que subió Admin y no puedo modificar. Pero como en los archivos de descarga no se produce el fenómeno, en realidad tampoco tiene mucha importancia.

¡Quietooooos! No os abalancéis sobre mí pidiéndo que os explique cómo lo he reuelto, ni cuál es el texto oculto, ni nada de nada. Quiero decir que he terminado de analizar la salida de MIMIC para cualquier entrada, y he llegado a la conclusión de que es invulnerable a cualquier ataque sobre la estadística de las letras del cifrado. Ahora alguno estará esperando que exponga páginas y páginas de análisis de cadenas estocásticas o, al menos, de grandes tablas de resultados estadísticos que avalen mi tesis. Y yo, como colega vuestro que soy os debo una explicación, y esa explicación os la voy a dar, porque como colega vuestro que soy...

100/17 = 5.88 ~ 6

Ahí es ná, mi sedudo estudio, ¿eh? Pues bien. La cosa es como sigue:

El signo más repetido en un texto castellano es el separador o espacio, que en muchas estadísticas publicadas no figura, pero que aquí es un símbolo más del alfabeto, y tiene efecto en la transfomación de este monstruoso Proteo. Si el texto cifrado com MIMIC está en castellano, la frecuencia relativa de aparición del separador "_" será aproximadamente de un 17%, lo que quiere decir que nos encontraremos con uno de estos símbolos cada 6 caracteres, por término medio, y los que hayáis leído la descripción del algoritmo ya sabéis que cada repetición implica la activación del mecanismo de transformación del alfabeto, que es quien hace de clave. La situación aún será peor en la práctica, porque antes de que se repita un espacio podrá darse de vez encuando la repetición de alguna otra letra. Por ejemplo, en

1234567890123456789012345678901
ESTE ASESINO DE CRIPTOANALISTAS
---|--|-----| etc.

antes de que se repita el espacio, que está en las posiciones 5 y 13 (¡ocho caracteres) ya se ha repetido la E, que está en la posición 1 y 4, y la S, que está en las posiciones 2 y 7. Es decir, que tendríamos proteicas transformaciones en las posiciones 4, 7, y 13, si lo he entendido bien, que tampoco....

Esas distancias tan cortas imposibilitan cualquier estudio de frecuencias que pueda detectar siquiera cuándo se ha producido una transición, mucho menos, qué letras, planas o de la clave, han ido apareciendo.

Es decir, tenemos un estupendo OTP con clave aleatoria e infinita, alimentada por los propios caracteres del texto plano, pero de una manera inextricable. Punto y final. Enhorabuena, LlamameX, porque además de ser un magnífico analista, has encontrado un cifrado seguro, la Piedra Filosofal de todo criptógrafo. La única pega que el cifrado pueda tener es si las alteraciones del alfabeto-clave consumen mucho tiempo, haciéndolo ineficiente, de hecho se podrán producir más de las necesarias, incluso algunas consecutivas, aunque esto podría eliminarse con algún condicional que no sé si el algorimto tiene ya previsto. Pero no hay mal que por bien no venga, y ya he escrito en otro lugar que un poco de ineficiencia en un algoritmo podría ser un buen seguro frente ataques de fuerza bruta contra la clave. Otro punto y final, y ya van dos.

Bueno, cabría una forma de ataque si se dan las circunstancias adecuadas y es, como no, un ataque con texto conocido, donde las habilidades de sqrmatrix podrían ser decisivas. Esto no es una tontería, aunque yo lo diga, porque en los mensajes de la profesión suele haber encabezamientos, destinatarios, fechas, etc. que el atacante puede conocer o intuir. El mando japonés tuvo un nivel muy bajo de seguridad en sus mensajes, durante la guerra del Pacífico, porque, además de suponer que su idioma no lo hablaba nadie más que ellos, ponían unas enormes parrafadas protocolarias en los encabezamientos.

Renunciado ya a la cebada, el burro va a ver si puede enfrentarse al otro objetivo, aunque con las esperanzas algo decaídas.

Punto y final III

Como vi este cifrado tan sólido, ni se me ocurrió hacer un AG de los míos para atacarlo, como hice con LAPYZNOS. Y probablemente hubiese tenido exito, pues a medida que la clave converge hacia la solución, también lo hacen, al menos, las primeras posiciones del texto en claro generado.

veamos:

DEFEN

PLATORNLZOYHDSMUKÑLEKY,MQOPC@URWLXYJ@M@UUDEK*.DDGGPZ@@FLQDAB*M,I.HCLFHBWCLBMQXRDOBAJMGE,YVTOF*XHXRAAA

DEFENS

PLATON.__,VDMAWL*RTGJIKYKPM,GT,BNK,@IY_REBAZWODGETQOÑFJCW*SJRQKASNYYOQP..EQCCGXJTG@HOÑEGVJYA.GYXLFAAA

DEFENSA

PLATON_BUNSUUID*AENY*IFCQBCK@WUJREJFBAYWFXNDNW@YDDHRB*GWTEFEPD*WB_@DYHLAYAJÑXW.LLHFVE*MBSTIVQZM*ÑAAAA

DEFENSA_

PLATON_CRIT,NBN*RFQHPXPMPN,ÑDZÑXMBDNREWZV*ÑAWYFR,Y,IVJAYSLYOM@IZXOOANÑDUNMVFESBBYJJDAG_NPLVERBYTLDAAA

DEFENSA_DE

PLATON_CRIJPNVEG,OOSYCM@PÑBZ@MW.BJVCYHJM@LHFP@M*EZWSZ.FFR_QLVKNOOÑ,V.WGCYAJI*Y@,ÑMPUKW@PJMOOVILIO.AAA

DEFENSA_DE_SO

PLATON_CRITINBB,OCJJH*XÑQDMTHLFAC@GTCN,LNL*VMHVRLT,HT_.CVLVMQSW__HZAV,G_JAXVPOENÑ*OCLDCRYVEIUYXSJFAAA

DEFENSA_DE_SOCRA

PLATON_CRITON_IN,FYWZDT.KSQEOCS@I*BGYZY_KL@KVS.BNQBEOSEG@U,AIKWJL_RUYY@,BAJV*ÑPEL*KPJNXKJS@*ZJJD_QAAA

DEFENSA_DE_SOCRATES

PLATON_CRITON_INTRODUCCION_EL_CRITON_ES_EL_MAS_BREVE_DE_LOS_ESCRITOS_

Está claro que este criptosistema es vulnerable a ataques con métodos heurísticos como los AGs o el Recocido simulado. Omelette era mucho menos vulnerable en este aspecto.

Gracias a Sqrmatrix y a Llamamex por este bonito reto.

Ps.

Yo creo que el problema de convergencia de la clave se puede arreglar, haciendo este sistema más sólido, es decir, hace falta MIMIC 2.0

me digo a mí mismo qué hubiera pasado si en vez de tirar para letras hubiera tirado para ciencias. Qué envidia me dáis. Enhorabuena.

Aquí muestro el primer paso del análisis de MIMIC que hice (bueno, en realidad no fue éste el que hice primero, pero creo que es mejor mostrarlo el primero para entender mejor el resto de los pasos).

El cifrario MIMIC puede considerarse una forma enrevesada de cifrario XOR. Analizaremos primero cómo podemos atacar un cifrario XOR.

En un cifrario XOR, tenemos dos cadenas de texto, emparejadas carácter a carácter, y el criptograma se obtiene aplicando la función XOR a cada par de letras enfrentadas. Evidentemente, el número de caracteres que debe haber en el alfabeto debe ser una potencia de 2. Para descifrar, basta emparejar los caracteres del criptograma con los de la clave, y realizar la operación XOR.

Bien, sabemos que si la clave es aleatoria, y no disponemos de ella, es imposible determinar el texto original a partir del criptograma. La cosa cambia cuando estamos ante una clave formada por un texto (y es lo que vamos a suponer para este reto).

Para descifrar un criptograma XOR con estas características, podemos usar un ataque de diccionario. Para ello, necesitamos un lemario que disponga de todas las posibles palabras.

El ataque es muy simple, aunque también puede ser lento, y puede fracasar si aparecen palabras en el texto o en la clave que no aparezcan en el lemario utilizado.

Para facilitar las explicaciones, primero hay que definir algunos conceptos:

- "Separador": respecto de un lemario, un separador es un carácter que separa las palabras del lemario entre sí para formar un texto. Aparece antes y después de las palabras, pero no forma parte de ellas. Pueden aparecer dos o más separadores juntos, y las reglas de formación de textos (que pueden o no coincidir con las reglas gramaticales) determinarán cómo y cuándo pueden aparecer juntos. Pueden considerarse también como separadores grupos de dos o más caracteres que cumplen lo ya dicho.
- "Texto válido": respecto de un lemario y unos separadores, diremos que un texto es un texto válido si está formado por palabras del lemario separadas por separadores. El fragmento de texto puede empezar y/o terminar con separadores.
- "Fragmento de texto válido": respecto de un lemario y unos separadores, diremos que un texto es un fragmento de texto válido si es un texto válido que empieza por la parte final de una palabra del lemario, separada del texto por un separador, y/o termina en un separador seguido del comienzo de una palabra del lemario

Un texto válido es un caso especial de un fragmento de texto válido.

Como ejemplo de separadores, tenemos los propios del lenguaje castellano: " " (espacio), "," (coma), "." (punto), ";" (punto y coma), etc.. Como ejemplo de grupos de caracteres que funcionan como separadores, tenemos ". " (punto seguido de espacio), ", " (coma seguida de espacio), "..." (puntos suspensivos), etc..

Como ejemplo de textos válidos (y, por tanto, también de fragmentos de texto válidos), suponiendo como lemario las palabras del lenguaje castellano, y como separadores sus signos de puntuación y el espacio, son textos válidos: "EN_UN_LUGAR_DE_LA_MANCHA", "_DE_LA_MANCHA", "EN_UN_LUGAR_", "_LUGAR_DE_LA_MANCHA, ", etc.

Como ejemplo de fragmentos de texto válidos, con las suposiciones anteriores, tenemos los siguientes ejemlos: "EN_UN_LUGAR_DE_LA_MANC", "GAR_DE_LA_MANCHA", "GAR_DE_LA_MAN".

Puede darse el caso de que un texto sea simultáneamente un texto válido, y un texto no válido, pero fragmento de texto válido. Esto ocurre cuando el texto en cuestión comienza por una palabra que es a su vez el final de otra palabra, y/o cuando termina por una palabra que es a su vez el comienzo de otra palabra. Por ejemplo, "EN_UN_LUGAR_DE_LA_MANCHA", "EN" es el final de varias palabras, como por ejemplo, "TIENEN", y "MANCHA" es el comienzo de varias palabras, como por ejemplo, "MANCHADA". Así, el texto "EN_UN_LUGAR_DE_LA_MANCHA" puede ser tomado como texto válido, y también como fragmento de texto, que podría provenir de "TIENEN_UN_LUGAR_DE_LA_MANCHA", "EN_UN_LUGAR_DE_LA_MANCHADA", "TIENEN_UN_LUGAR_DE_LA_MANCHADA", o cualquier otra combinación de palabras que comiencen y terminen por esas palabras.

El fundamento del ataque que voy a presentar es el siguiente. Tenemos una función, "XOR", en la que se genera el criptograma "C" a partir del texto "T" y la clave "K", de la forma T XOR K=C ("T", "K" y "C" definen tanto letras como textos, todos de la misma longitud, y la operación XOR se aplica a pares de letras emparejadas de cada variable). Por otro lado, la función XOR tiene la propiedad de que conocido el valor de dos de las componentes de la anterior igualdad, podemos obtener el valor de la tercera componente haciendo XOR de las dos componentes conocidas. Por último, puesto que tanto "T" como "K" forman un texto válido, los valores que pueden tomar estarán limitados a fragmentos de texto válidos.

Visto esto, tenemos el siguiente ataque. Tomamos todos los fragmentos de texto válido, y los asignamos a una de las variables desconocidas, da igual cuál, pues son intercambiables. Supongamos que lo asignamos a la variable "T". Hallamos la operación XOR con el criptograma "C" para obtener el valor de la otra variable, en este caso "K", y comprobamos si generan un fragmento de texto válido. Aquellos fragmentos de texto que no generen un fragmento de texto válido se descartan como fragmentos de texto no válidos. Aquellos que sí generen un fragmento de texto válido se toman como candidatos del texto o de la clave, no sabemos aún si es texto o clave, y los textos que han generado también se toman como candidatos de la otra variable. Obtenemos así pares de texto y clave, que habrá que examinar para determinar cuáles son el mensaje que buscamos.

Este ataque, según se ha explicado, es impracticable (salvo textos de pocos caracteres), ya que habría que obtener todos los textos posibles de la longitud del criptograma (una cifra astronómica).

Basta observar que si tenemos un texto válido, el texto generado será también válido y, por tanto, cualquier fragmento del primer texto generará una fragmento de texto válido. Así que lo único que hay que hacer es ir obteniendo el texto palabra a palabra (o incluso letra a letra), comprobando que cada nueva palabra (o letra) genera el correspondiente fragmento de texto válido. Por otro lado, también se observa lo siguiente: supongamos que tenemos generado el fragmento de texto válido "K" mediante el texto "C", obtenido este último mediante palabras completas. Al añadir una nueva palabra a "C" (con el separador o separadores necesarios), para saber si el nuevo texto obtenido "K'" es válido, no hace falta comprobarlo entero, sino sólo a partir del último separador que tenía antes de añadirse la palabra. Para entenderlo mejor, veamos un ejemplo.

Tenemos el texto "EN_UN_LUGAR_DE_LA_MANCHA", y la clave "SANCHO_FUE_EL_ESCUDERO._", con el alfabeto del reto "ABCDEFGHIJKLMNÑOPQRSTUVWXYZ_.@*,". Al hacer XOR, obtenemos el criptograma "WNVWKTPPSEJ,I,,XCÑOE,N__". Si no conociéramos ni el texto ni la clave, realizaríamos el procedimiento aquí descrito. Vamos a olvidarnos de momento de todos los candidatos, y vamos a centrarnos en las palabras del texto y de la clave. Cuando llegáramos a la palabra "EN", obtendríamos el fragmento de texto "SA", que serían candidatos. Pero también llegaríamos a la palabra "SANCHO", que generaría el fragmento de texto "EN_UN_". Centrémonos en este par de textos. El siguiente paso sería añadir a "SANCHO" otra palabra, con un separador. Acabaríamos llegando a "SANCHO_FUE", que generaría el fragmento "EN_UN_LUGA", y es aquí donde quería llegar para explicar cómo no es necesario comprobar que, al añadir la siguiente palabra, se compruebe el texto completo, sino sólo a partir del último separador. Bueno, la siguiente palabra con la que nos encontraríamos sería "EL", que al añadirla al texto que ya tenemos, obtendríamos "SANCHO_FUE_EL", y obtendríamos al hacer XOR "EN_UN_LUGAR_D". Como se ve, sólo es necesario comprobar a partir del último espacio que hemos obtenido un fragmento de texto válido, es decir, en lugar de comprobar que "EN_UN_LUGAR_D" es un fragmento de texto válido, sólo nos basta comprobar que "LUGAR_D" es un fragmento de texto válido. Igualmente, no hace falta hacer "XOR" con todas las palabras que tenemos, es decir, con "SANCHO_FUE_EL", sino sólo la parte del fragmento que necesitamos, es decir, a partir de la posición que ocupe "LUG", o sea, "_FUE_EL".

Este ataque puede mejorarse. Por ejemplo, si al hacer XOR el texto obtenido es un fragmento de texto válido que termina con el comienzo de una palabra del lemario, podemos intercambiar el texto que estábamos deduciendo por el texto que estábamos obteniendo con XOR. Ahora, tan sólo hay que probar con las palabras que comiencen por la terminación del texto que tenemos. De nuevo, esto se verá mejor con un ejemplo.

En el ejemplo anterior habíamos obtenido, con el texto "SANCHO_FUE", el texto "EN_UN_LUGA". Observamos que al final tenemos un comienzo de palabra. Pues si intercambiamos los textos, ahora buscaremos todas las palabras que comiencen por "LUGA", las añadiremos al texto, haremos XOR, y comprobaremos si genera un fragmento de texto válido. Tenemos las palabras "LUGANO", "LUGAR", "LUGAREÑO", etc. Al probar con "LUGANO" (que, como todo el mundo sabe, es un ave paseriforme :) ), obtenemos "SANCHO_FUEEP", que no es un fragmento de texto válido, porque no existe la palabra "FUEEP", ni ninguna palabra comienza por "FUEEP". La siguiente es "LUGAR", que genera el texto "SANCHO_FUE_", que sí es un fragmento de texto válido. "LUGAREÑO" genera el texto "SANCHO_FUE__GP", que tampoco es un fragmento de texto válido, porque ninguna palabra comienza por "GP" (y si no estuvieran permitidos los dobles espacios, eso también descartaría "LUGAREÑO" como palabra válida).

Cuando nos encontramos en el texto obtenido con XOR con un texto válido, es decir, que termina con una palabra del lemario (si tenemos tanto una palabra, como el comienzo de una palabra, el caso del comienzo de una palabra se trató en el ejemplo anterior, y aquí se explica el caso de la palabra completa), lo que tenemos que hacer es añadir al texto (en este caso, nos da igual cuál de los textos tomemos, porque la operación será la misma) todas las combinaciones de separadores permitidas, y ver si el texto generado es un fragmento de texto válido. En caso de que el separador coincidiera en texto y en clave, la función XOR generó el valor 0 (ya que se está haciendo XOR de dos valores iguales), lo que significa que al probar con un separador (o cualquier carácter), obtendremos el mismo separador al hacer XOR, lo cual es válido, y tendremos que ramificar los intentos. En este caso, si los separadores tienen ciertas reglas, se utilizarán para intentar reducir las ramificaciones.

Veamos otro ejemplo de lo dicho. Supongamos ahora el fragmento de texto válido "ERA_UN_LUGAR_DE_LA_MANCH", con la misma clave y alfabeto de antes. Al probar con la palabra "SANCHO", obtenemos "ERA_UN", que termina con la palabra válida "UN" (suponemos comprobadas todas las palabras que comienzan por "UN"). En este caso, probaríamos con todas las combinaciones de espacios permitidas. "_", "," y "." nos generarían los mismos separadores (ya que al coincidir en el texto y la clave el mismo carácter, el criptograma tendrá en esa posición el valor 0, y la operación XOR de un valor con 0 da como resultado el mismo valor), lo cual es válido. No obstante, si suponemos como norma que en los textos tanto el punto como la coma van seguidos de espacio, podemos probar las combinaciones "._" y ",_", que en este caso generan "ERA_UN.U" y "ERA_UN,U", que no siguen la norma de coma o punto seguido de espacio (en este caso, nada nos asegura que todos los puntos y las comas tengan que estar seguidos de espacio, pero es una pista más).

Este ataque no nos garantiza el éxito, pues es necesario que todas las palabras que aparecen tanto en el texto como en la clave estén también en el lemario utilizado. Es posible también que se generen muchas ramificaciones (esto es, muchos fragmentos de texto válidos que analizar), lo que gasta mucho tiempo y memoria. Todavía no he probado este ataque en un caso real, pues tampoco lo he implementado completamente. En el caso de que aparezcan palabras que no estén en el lemario, siempre se pueden registrar los progresos hechos para echarles un vistazo manualmente. La intuición del criptoanalista puede determinar la palabra que falta. Y si no, siempre se pueden saltar unos caracteres del criptograma para iniciar un nuevo análisis en el resto del criptograma que queda.

En este último caso, como no sabemos dónde empieza la siguiente palabra, habrá que realizar un tanteo. Se selecciona una posición a partir de la cual analizar, se realiza el análisis indicado antes, y si no progresa, se pasa a la siguiente posición, así hasta encontrar un fragmento de texto válido (en este caso, el nuevo fragmento de texto obtenido con XOR puede no empezar con una palabra completa, sino con el final de una palabra, a diferencia del análisis realizado al principio del criptograma). En este caso, aunque no se empiece en una posición válida, con el avance del análisis es muy probable encontrar un separador en la posición correcta, ya que la probabilidad de encontrar un separador en la misma posición en dos textos diferentes es relativamente muy alta, y a partir de ese separador, el análisis se realiza en el comienzo de una palabra del texto o de la clave.

El mayor problema que presenta este ataque es que haya palabras en la clave y/o el texto que no tengamos en el lemario. Los lemarios que existen no tienen conjugaciones verbales, plurales, géneros, prefijos ni sufijos. Cuando me puse a realizar el primer ataque, lo que hice fue coger todos los lemarios que encontré, y construir uno con todas las palabras de todos. Después, me construí unas funciones en Java para obtener plurales, géneros y conjugaciones verbales de verbos regulares, todo esto aplicado a todas las palabras. Para los géneros, añadía a la palabra "S", "ES", etc, según las normas generales de formación de plurales. Para los géneros, si la palabra terminaba en "A", la cambiaba por "O" y viceversa, y no recuerdo si alguna otra operación. Para los verbos, cogía las palabras que terminaban en "AR", "ER" o "IR", y obtenía la conjugación suponiendo que fueran verbos regulares. De cada uno de ellos obtenía más de 3000 combinaciones (no todas correctas, por supuesto). Mi idea era obtener todas las posibles palabras a partir de las del lemario, para construir un superlemario que abarcara un buen porcentaje de todas las posibles palabras. Interrumpí el proceso cuando ví que el archivo que estaba generando ocupaba 90 MB y todavía estaba con las letras que empezaban por "A". Java no puede manejar tanta información en memoria, y manejarla con accesos a disco haría el proceso muy lento. Para solventar este problema se me ocurrió una idea que al final no llevé a cabo, y era mantener la lista de las palabras del lemario original, pero a la hora de realizar las consultas, de cada palabra consultada se obtendrían todas las palabras derivadas y se realizarían las consultas a esas palabras obtenidas. El proceso seguiría siendo lento, pero seguramente menos lento. Lo que no hice fue obtener palabras con prefijos y sufijos. Pensaba hacerlo más tarde, cuando probara lo anterior.

Este ataque puede generalizarse a otros cifrarios que tengan ciertas características:

Si tanto el mensaje como la clave son textos, basta con que cumpla el cifrario esta característica:
- Si C(i)=f(T(i),K(i)) es la función que obtiene el carácter del criptograma "C(i)" a partir del carácter del texto "T(i)" y el carácter de la clave "K(i)", deben existir funciones f' y f" tales que T(i)=f'(C(i),K(i)) y K(i)=f"(T(i),C(i))

Si el mensaje y/o la clave no son textos, además de la anterior característica deben cumplir la siguiente:
- El mensaje y la clave deben estar formados por concatenaciones de caracteres que sigan unas reglas que limiten las posibles combinaciones formadas para que puedan ser deducidas por el procedimiento explicado sin presentar demasiadas ambigüedades (el procedimiento consistiría en ir deduciendo los textos carácter a carácter, o mediante grupos de caracteres, y si hay grupos de caracteres prohibidos, servirán para descartar combinaciones utilizadas)

Un ejemplo de cifrario al que se puede aplicar este ataque es el Vigenère, sobre todo cuando la clave es un texto muy largo.

En el cifrario MIMIC encontré unas vulnerabilidades que me hicieron pensar que quizá podría obtener estas funciones f' y f" y, con ello, aplicar este ataque. Esas vulnerabilidades las mostraré en el siguiente paso. No conseguí obtener estas funciones, salvo parcialmente.

Como he dicho, no he aplicado este ataque a un caso real, y no sé si será muy efectivo. Algo efectivo sí es, porque ha permitido resolver el reto.

Me ha hecho gracia la construcción de las conjugaciones de los verbos. Hace la tira de años (13 ó 14) me enfrenté a un problema similar: necesitaba una base de datos con verbos conjugados, que no existía por ninguna parte (quería construir un parser para analizar oraciones)
Así que me descargué un programa que los conjugaba (pero sólo mostraba en pantalla el resultado), y me hice un programita que leía de una base de datos y enviaba pulsaciones al teclado, para alimentar al programa con los verbos de una base de datos.
Entonces recogía los resultados del portapapeles (enviaba las teclas CTRL+C) para, al fin, guardar las conjugaciones en una base de datos. Total 500.000 registros, comenzando por las formas de "ababillar", con todas las conjugaciones de miles de verbos. Lo consiguió en una semana de funcionamiento.
Ese inmenso (e inútil) trabajo que guardaba como monumento a la ociosidad, podrá ser ahora utilizado para el mal gracias a la inspiración de sqrmatrix...

En este cuarto y último paso describiré la idea que tenía en mente para seguir desarrollando el análisis de MIMIC, con la que esperaba conseguir una porción mayor de la clave y el texto claro, pero que al final no conseguí desarrollar. Como la idea la tengo en el aire, al desarrollarla aquí para su publicación quizá no la haya explicado de la manera más óptima.

En el paso anterior obtuvimos los candidatos a texto claro-clave, pero sólo hasta la repetición del primer carácter del texto claro. Esto nos permitió obtener también los primeros caracteres del primer alfabeto desordenado. Supongamos que tenemos los siguientes caracteres del texto claro, hasta que se repita la siguiente letra, porque a partir de esa repetición, se cambia de nuevo el alfabeto desordenado. Si hacemos XOR de esos caracteres, obtenemos los correspondientes caracteres del segundo alfabeto desordenado. Si tuviéramos todos los caracteres del primer alfabeto desordenado, podríamos determinar con seguridad los caracteres correspondientes de la clave. Pero como no los tenemos, lo más seguro es que no podamos determinarlos, sobre todo porque la determinación de un carácter depende de la determinación del carácter anterior, ya que el nuevo carácter se determina por un desplazamiento a partir de la letra anterior, y si no conocemos la letra anterior, no podemos conocer su posición y, por tanto, no podemos calcular su desplazamiento.

Tomemos la primera letra que hemos calculado del segundo alfabeto desordenado. Su posición en el segundo alfabeto desordenado coincidirá con la posición de la letra, ya que todavía no hemos podido cifrar un bloque de texto de longitud la del alfabeto. Para determinar la correspondiente letra de la clave, es necesario que este carácter de este segundo alfabeto desordenado esté presente en el primer alfabeto desordenado. Si tenemos suerte, podremos determinar esta letra de la clave. Si no, no podremos determinarla, ni las siguientes. Y así se seguiría, hasta encontrar una letra del segundo alfabeto desordenado no presente en el primero, o hasta terminar con todas las letras. Se comprobaría si el fragmento de clave obtenido es un fragmento de texto válido, y se seguirían los pasos explicados en los pasos anteriores. Si resulta que hemos podido determinar todos los caracteres de la clave en este segundo fragmento de texto claro, repetimos el proceso con el tercer fragmento. Hay que tener en cuenta que en este paso ya se ha añadido a la clave un carácter aleatorio (que calculamos como se explicó en pasos anteriores), que habrá que tener en cuenta a la hora de comprobar el fragmento de clave obtenido. Si encontramos este carácter, es posible que hayamos determinado la clave completa. Lo comprobamos descifrando el criptograma con la clave obtenida, sin el carácter aleatorio.

En caso de que hayamos encontrado un carácter del segundo alfabeto desordenado no presente en el primero, podemos hacer una operación que quizá nos permita descartar algunos candidatos. Esta operación consiste en calcular un fragmento del segundo alfabeto desordenado a partir del fragmento que tenemos del primero. Para ello, basta calcular de forma normal el segundo alfabeto desordenado, a partir de lo que tenemos del primer alfabeto desordenado, pero sólo hasta completar los caracteres de la clave que tenemos. Al aplicar este método, obtendremos la posición de una letra en el primer alfabeto que deberemos colocar en el segundo alfabeto. Estas letras se colocarán en las primeras posiciones del segundo alfabeto, hasta llegar a las letras que ya tenemos del segundo alfabeto, por lo que no hay posibilidad de sobreescribirlas. Nos podemos encontrar con las siguientes posibilidades:

- Tomamos una letra de las que tenemos en el primer alfabeto, y esa letra no existe en el segundo alfabeto: en este caso, añadimos esta letra en el segundo alfabeto, tal y como se hace en el cálculo del alfabeto desordenado
- Tomamos una letra de las que tenemos en el primer alfabeto, y esa letra ya existe en el segundo alfabeto: en este caso, estamos ante un alfabeto con letras repetidas, lo cual es incorrecto y, por tanto, el fragmento de texto con el que estamos trabajando es incorrecto. El error puede estar tanto en la última parte añadida, como en el candidato con el que estamos trabajando. Supondremos que es esta última parte añadida la errónea, así que la eliminamos, y buscamos otra parte a añadir
- Tomamos una letra del primer alfabeto que desconocemos: dejamos la letra en el segundo alfabeto vacía y continuamos con el proceso

Creo que esto se puede desarrollar aún más. Por ejemplo, si añadimos a la clave un fragmento posible, obtenemos más letras del primer alfabeto desordenado. Si alguna de estas letras se encuentra entre las letras que hemos encontrado del segundo alfabeto desordenado, podemos repetir el cálculo de este segundo alfabeto desordenado, como se indicó antes, a ver si hay errores. Si los hay, habría que ver dónde está el error, si en la clave, en el texto, o en ambos. Si no los hay, podemos seguir avanzando. Podemos repetir esto para obtener nuevos fragmentos de texto y clave, aunque cada vez es más incierto que lo que estamos obteniendo sea correcto. Con estos nuevos fragmentos, obtenemos diferentes fragmentos de alfabetos desordenados consecutivos (haciendo XOR con el texto claro que estamos probando y la clave. Cada repetición de letra determina el final de un alfabeto desordenado y el comienzo del siguiente) y probamos claves, a ver si no se producen errores, o si tenemos suerte de encontrar la clave. Quizá haya más cosas que se puedan hacer.

Hasta aquí lo que se me había ocurrido. Como ya he dicho, todo esto no lo llegué a desarrollar, así que no sé si es efectivo o no.