Foros:
Por Agustín
Bueno, pues este Fucked-OTP es hijo ilegítimo de AESito32, que tan poca fortuna tuvo en vuestras manos, especialmente por la implacable pericia de LlamameX, que tardó menos en descerrajarlo que yo en concebirlo. He mantenido casi todos los rasgos de su papá, sobre todo porque así la implementación que ya tenéis funcionará perfectamente, con un leve cambio.
La única diferencia es que, a partir del segundo bloque, la clave se va formando con los propios caracteres del texto plano, para crear una especie de falso OTP. De este modo podríamos averiguar si el flujo de caracteres del propio fichero proporciona una clave razonablemente fuerte, es decir, si un falso OTP se puede comportar como un OTP, cosa que dudo mucho.
Vamos p'allá...
1. El alfabeto
Es el habitual, de 32 caracteres
ABCDEFGHIJKLMNÑOPQRSTUVWXYZ_.,:;
2. La clave
La clave inicial es de 32 caracteres, que se completa, si es necesario, por el viejo procedimiento
K[L+i] = K[i] + 1
Por ejemplo, la clave
LOS_LAMELIBRANQUIOS
se convierte en
LOS_LAMELIBRANQUIOSMPT.MBNFMJCSB
3. Nuevo Alfabeto
El mismo procedimiento para obtener el alfabeto desordenado que se mantendrá durante todo el cifrado -hay que dar alguna oportunidad a los criptoanalistas- Lo copio de AESito32 tal cual
a) Se obtienen las posiciones de la clave en el alfabeto base, lo que nos dará la lista:
12 16 20 28 12 01 13 05 12 09 02 19 01 14 18 22 09 16 20 13 17 21 29 13 02 14 06 13 10 03 20 02
b) Luego se ordena esta lista para obtener una secuencialización, de forma que podamos tratar con las repeticiones.
Clave ordenada 01 01 02 02 02 03 05 06 09 09 10 12 12 12 13 13 13 13 14 14 16 16 17 18 19 20 20 20 21 22 28 29 Secuencia 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
c)Ahora procedemos a desordenar el alfabeto de la siguiente manera: Tomamos la primera letra, que es, lógicamente, la A. Como el primer valor de la clave es el 12, que aparece por primera vez en la posición 11 (empezando por cero) de la secuencia, la letra A irá a la posición 11 del alfabeto
00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 __ __ __ __ __ __ __ __ __ __ __ A_ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __
Hay que marcar de algún modo que la posición 11 ya está ocupada. Yo lo he implementado borrando el valor 11 de la matriz de posiciones de la clave.
A continuación tomamos la B, a la que le corresponde el valor 16 de la clave, cuya primera posición en la secuencia es la 20, luego la B va a la posición 20:
00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 __ __ __ __ __ __ __ __ __ __ __ A_ __ __ __ __ __ __ __ __ B_ __ __ __ __ __ __ __ __ __ __ __
y así sucesivamente, hasta que nos queda el alfabeto desordenado de esta forma:
FMKX;,HZJP.AEIGSW_NYBQTÑLCR:UODV
4. Bloques de 32 caracteres, que se desordenan
Empezamos a cifrar un texto como éste
LA_REVOLUCION_PALESTINA_POR_RODOLFO_J._WALSH_EN_ESTE_AGOSTO_DE_EN_QUE_RECRUDECE_LA_AGRESION_DE_ISRAEL_EN _MEDIO_ORIENTE_Y_EN_QUE,_CORRESPONDIENTEMENTE,_SE_MULTIPLICAN_LAS_MENTIRAS_IMPERIALISTAS_PROPAGADAS_POR_LOS _GRANDES_MONOPOLIOS_DE_LA_COMUNICACION,_RESULTA_IMPRESCINDIBLE_LEER_LO_QUE_ESCRIBIERA_ESTE_INSIGNE_Y_RECONO CIDO_PERIODISTA_Y,_MAS_QUE_ESO,_ESTE_CONSECUENTE_COMBATIENTE_REVOLUCIONARIO,_INTEGRANTE_DE_MONTONEROS,_QUE _DESAPARECIERA_EN_MARZO_DE_A_MANOS_DE_LA_DICTADURA_DE_VIDELA._ES_ESTA_LA_VERDADERA_HISTORIA,_DOCUMENTADA_A UN_CON_FUENTES_QUE,_COMO_LA_ONU,_SI_PUEDEN_SER_SOSPECHADAS_DE_PARCIALIDAD,_NO_ES_PRECISAMENTE_EN_FAVOR_D E_LA_RESISTENCIA_PALESTINA,_Y_RELATADA_POR_UN_RODOLFO_WALSH_SOBRE_EL_QUE_HOY_YA_ES_UNIVERSAL_SU_CREDIBILIDA D_Y_HONESTIDAD_INTELECTUAL,_UN_ESCRITOR_ALABADO_MUNDIALMENTE_Y_RECONOCIDO_COMO_UN_CLASICO_DE_LA_LITERATURA _POLITICA_Y_COMO_UN_EXCELSO,_PENETRANTE_E_INSUPERABLE_INVESTIGADOR._EL_PRESENTE_TRABAJO_DE_RODOLFO_WALSH_F UE_PUBLICADO_EN_EL_DIARIO_NOTICIAS,_EN_JUNIO_DE_._PUBLICAMOS_ADEMAS_LA_POLEMICA_POSTERIOR_ENTRE_WALSH_Y_EL_E NTONCES_EMBAJADOR_DEL_ESTADO_DE_ISRAEL_EN_ARGENTINA._EL_CONJUNTO_DE_ESTOS_MATERIALES_ES_REPRODUCIDO_EN_BASE_ A_LOS_CUADERNOS_DE_LA_REVISTA_JOTAPE_QUE_APARECIA_EN_LOS_Y_A_LA_EDICION_REALIZADA_POR_LA_EDITORIAL_ULTIM O_RECURSO,_EN_MAYO_DE_._
a) Tomamos el texto en bloques de 32 caracteres
Bloque LA_REVOLUCION_PALESTINA_POR_RODO
b) Generamos una clave nueva, a partir de la anterior, por el procedimieto ya descrito, de tomar para cada carácter, el que le sigue en el alfabeto base. Aunque esto parece excesivamente trivial, no lo es tanto, porque las posiciones de esas letras van a referirse al alfabeto modificado, y la secuencia ya no será tan simple. Eso también viene de la Omelette.
Nueva clave MPT.MBNFMJCSBÑRVJPTNQU,NCÑGNKDTC
cuyas posiciones en el alfabeto modificado son:
Posiciones de la clave 02 10 23 11 02 21 19 01 02 09 26 16 21 24 27 32 09 10 23 19 22 29 06 19 26 24 15 19 03 31 23 26 Posiciones ordenadas 01 02 02 02 03 06 09 09 10 10 11 15 16 19 19 19 19 21 21 22 23 23 23 24 24 26 26 26 27 29 31 32 Secuencia 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
c) Mediante esta clave se desordena el primer bloque de caracteres, por el procedimiento ya descrito.
Bloque desordenado LLEURACLAERROOT__VNI_SD_OIPOPNOA
d) Se realiza XOR entre cada carácter del bloque desordenado y cada carácter de la clave, usando las posiciones de ambos en el alfabeto modificado
En nuestro caso tenemos los siguientes valores:
Bloque cifrado C_RT:VAL.;XQP.EGCT;V;Y:X;RZSAEAN
Hasta aquí todo es idéntico al algoritmo de AESito32. La novedad viene ahora, porque no seguimos generando la clave por el naïf procedimiento anterior, sino que:
5. Nueva Clave: El bloque desordenado
El bloque desordenado del texto plano se toma como clave para cifrar el siguiente bloque. En nuestro ejemplo, la nueva clave será:
Nueva clave LLEURACLAERROOT__VNI_SD_OIPOPNOA
Así de sencillo.
De este modo vamos obteniendo el siguiente texto cifrado:
C_RT:VAL.;XQP.EGCT;V;Y:X;RZSAEAN ,HHÑTTMBOZATEFFOXZNOFZ_ÑEU,NLXY; E_WDWZBFJRXOOE:ZGBGOETXDJOT;XFÑD EDTZ_ÑOFSXDAXWYTFPKL_IOBNOJYJZJO SOFS;YXFD:TTXL_FIBMSDNBROIVF:ZOR :XFSLYAZX:_OBTKTDZQKY:JC:.EQ.RTZ ZFOCDULTTEFAY_UKNG._WZW;WRJKR,FX VGJRKPWFVÑ;ZT;PHFYD;PS_FMNQTUUAA RGFFQFFUP,K,AÑKXZR,CBXW;_XPQVEOJ
6. Descifrado
El descifrado sigue los mismos pasos para el completado de la clave y el desordenamiento del alfabeto. Al tomar el primer bloque cifrado, se hace el XOR con la clave, y lo que se obtiene es el bloque desordenado, que se tomará como clave para descifrar el siguiente. En suma:
a) Completar la clave, si es necesario
b) Desordenar el alfabeto, por el mismo procedimiento de la fase de cifrado
c) Generar una clave nueva, por el método descrito
d) Leer un bloque de 32 caracteres del cifrado
e) Hacer XOR con la clave. Eso nos proporciona el bloque en claro desordenado
f) Tomar el bloque en claro desordenado como clave para el siguiente bloque
g) Reordenar el bloque mediante la clave vigente, y escrbirlo en el fichero de salida
h) Volver a d)
Como podéis ver, no se trata de nada nuevo, sino de una forma de "self-synchronizing stream cipher" o de "ciphertext autokey" (CTAK). (http://en.wikipedia.org/wiki/Stream_cipher), que presentan diversas vías de atque, a diferencia de los auténticos OTP con clave aleatoria infinita, que tienen Secreto Seguro. Mi esperanza es que al tomar como clave el bloque desordenado se incorpore suficiente entropía como para dificultar los ataques basados en texto probable. Pero dada la voracidad reinante por estas aguas, no las tengo todas conmigo.
Problema
El problema consiste en descifrar este fichero:
Pues si,
Se te va a echar de menos
Y quien ataca a Rubik2???
Y quien ataca a Rubik2??? Agustiiiiiiiiiiin!!!!!!!!!!!!! donde estás!!!!
Tratando de encajarlo
Tratando de encajar el p. cubo de Rubik. No sé si podré llegar a implementarlo.
Es que ya que LlamameX ataca
Es que ya que LlamameX ataca a tu cifrado, alguien tiene que atacar al suyo ahora que se nos eclipsa momentánemamente Sqrmatrix. Sospecho que ya ha hecho sus propios intentos de auto-descriptado. Yo conseguí implementarlo a base de reciclar cachos de otro programa y convertir Javascript en Vbscript. También hice un intento de análisis por AGs, sin resultado. El análisis de frecuencias promente más, se repiten secuencias cifradas con el mismo texto claro.
Tienes toda la razón
Intentaré implementarlo, pero es que lo del cubo me desespera.
Ese es el factor psicológico
Un nivel de protección subliminal basado en que el cubo no puede resolverse XDD
Voy a intentar atacar con un AG
No se si siendo purista será un AG de verdad o una entelequia, pero le veo muchas posibilidades a una función de coste basada en la distancia recorrida en el descifrado de una columna partiendo de un valor conocido. Creo que si sale bien puedo ahorrarme mucho cálculo y sacar el alfabeto derivado. Ya os contaré.
Algún día
Algún día podríais explicar -en plan fácil- cómo se construye un AG.
Uy a mi no hagas mucho caso con eso
De hecho cojo lo que me interesa de la teoría purista y dejo correr el resto. Lo que voy a plantear es un criterio basado en la distancia que se recorre en el descifrado en cadena antes de desechar un candidato a alfabeto, si la distancia recorrida es superior a la de una versión anterior doy por buena la mutación y sigo mutando desde ahí, si no la descarto y pruebo aleatoriamente otra. Dentro de las posibilidades a mutar voy bajando la probabilidad de selección a los cambios que voy consolidando. No se si puedo caer en callejones sin salida, pero bueno, a ver que sale.
La cadena a descifrar será el siguiente trozo de una columna:
Que puesto que sus carácteres anteriores son dos Ñ (con lo que la primera letra de la secuencia sería la tercera Ñ seguida), con lo que es muy probable que esa Ñ represente al XOR de 2 espacios en el claro, así que nuestro punto de partida en el claro es "_". Además la cadena tiene otras dobles y triples Ñs muy prometedoras. A partir de ahí a probar alfabetos a ver cuantos carácteres descifran sin salirse de los límites de una ditribución regenta para 100 letras. En el momento que esos límites se superan se mira hasta donde hemos llegado. Si llegamos a 100 tenemos alfabeto seguro.
Ya se que me faltan muuuchos elementos para llamar a esta entelequía AG y seguro que a estas alturas Tokamak se está echando las manos a la cabeza y exclamando ¡pero que barbaridad!, pero le voy a dar una oportunidad a la idea.
Nunca pensé
Nunca pensé que se pudiera atacar por ahí el alfabeto derivado.
No es tan distinto
No es tan distinto, pero habría que hacer lo siguiente:
-Crear una población de a alfabetos distintos
-Después valoramos la aptitud de cada uno ellos, de acuerdo a la función propuesta
-Seleccionamos individuos para el cruce de forma aleatoriamente sesgada en función de la aptitud
-Cruzar dos a dos los individuos (alfabetos) seleccionados con un método que les permita mantener los 32 caracteres distintos, como con el Order Crossover, para generar uno o dos individuos nuevos.
-Con una cierta probabilidad (0.002, por ejemplo) mutar aleatoriamente un indivduo, permutando un gen (carácter) al azar por otro.
-Repetir n veces (generaciones) o hasta que la aptitud ya no progrese generación tras generación.
-Tomar el individuo con mejor aptitud, su genotipo (alfabeto) codificará la mejor solución hallada hasta el momento.
Pues, sí, me gustaría, pero
Pues, sí, me gustaría, pero el tiempo, ya sabes...
Entre tanto, puedes mirar esta explicación, es bastante buena:
www.it.uc3m.es/jvillena/irc/practicas/06-07/05.pdf
Muchas gracias
Voy a mirar lo del AG, a ver si me entero.
Tengo malas noticias para LlamameX
No se si es un error de implementación, del algoritmo, o del propio navegador, no me puse analizarlo demasiado.
Pero si cifro
AAAAAAAAAAQQQQQQQQQQWWWWWWWWWWEEEEEEEEEERRRRRRRRRRTTTTTTTTTTYYYYYYYYYYcon la clave
LOS_LAMELIBRANQUIOSy luego la vuelvo descifrar obtengo
AAAAAAAAAAQQQQQQQQQQWWWWWWWWWWEEEEEEEEEERRRRRRRRRRTTTTTTTTTTYYYYYYYYYFFFFFFFYFFFFFFFFFFFFFFFFFFFfíjate que entre la penúltima Y y la ultima tenemos 7 Fs de caracteres de relleno.
Y un
Padding
Eso puede ser debido a que los bloques son de 32 caracteres, y si el úlimo bloque es menor, se completa con caracteres basura antes de cifrar, aunque eso debería ocurrir después de la última letra, claro. Vuelve a intentarlo.
***************
REEDICIÓN
***************
Lo he comprobado, y ocurre como dices. Ya lo verá LlamameX, no parece un error importante.
No tengo esto abandonado
Aunque lo parezca. Eso si, voy al ralentí. Estoy haciendo encaje de bolillos con n-gramas en columna (apilar el texto en columnas y buscar n-gramas en ellos), con lo que voy consiguiendo algunas relaciones del estilo:
Con estas relaciones espero conseguir un juego de restricciones que me permita atacar el alfabeto derivado y obtener la clave.
Mis intentos con los AG no han sido demasiado satisfactorios. He visto que podría llegar a obtener la convergencia, pero partiendo desde resultados muy próximos a la solución, con lo que no me es nada útil.
Más que nada que se vea algo de actividad en estos temas, que ha caído en picado.
Tranquilo
Ve haciendo lo que puedas, que seguro que vas en la buena dirección.
Más madera
Precisaría disponer de bastante más cantidad de texto cifrado con la misma clave. Este bichejo, aunque tiene sus debilidades, precisa de bastante estadística para atacarlo en condiciones y aún así va a costar, puesto que habrá que especular mucho.
Por otra parte, se me ocurre una cosa para un AG contra el alfabeto pero me cuesta acabar de plantearlo, a ver si a Tokamak se le ocurre como: La idea es que el XOR de las parejas sigue una distribución muy característica que depende de las probabilidades de cada uno de los integrantes. Esas probabilidades son fácilmente calculables para un alfabeto determinado. Se trataría de ir generando alfabetos cuyas probabilidades fueran acercándose al perfil de distribución que muestra el cifrado.
Por ejemplo, la "V" es el caracter más infrecuente. Que un carácter aparezca poco es por que las combinaciones que la generan aperecen poco. Una de esas 32 combinaciones tiene que incluir al "_", por lo que su alta frecuencia tiene que venir compensada por una muy baja, por ejemplo de la "W". Igualmente deberemos ir compensando el resto de caracteres probables con improbables hasta conseguir su distribución concreta o algún valor muy cercano. Pero determinar esas combinaciones también afecta al resto, puesto que cada pareja que asignemos a conseguir la "V" no la podemos asignar ya a conseguir otros carácteres, con lo que se generan restricciones para los alfabetos que derivemos desde ese.
Entonces se trataría de conseguir alfabetos congruentes desde distribuiones de probabilidad de sus parejas lo más cercanas posible a la de nuestro cifrado. A partir de un conjunto completo de relaciones ya debería ser fácil (dependerá de lo cíclicas que sean esas relaciones) obtener el alfabeto derivado y desde él la clave. Esto es lo que estoy intentando desde n-gramas en las columnas pero me hace falta mucha más casuística para cubrirlo todo, con lo que igual desde un AG pueda lograrse con menos esfuerzo. De todos modos los datos que más o menos tengo pueden incorporarse como parte de la configuración de salida. Los trios que más o menos cuadran (también podrían estar bailados algún caracter) son los siguientes:
A ver si podemos cargarnos a este pequeño cabroncete, bastante más duro de roer de lo que parecía al principio.
Oops!
Comprendo que quieras más texto cifrado, pero ¿por qué con la misma clave? Ya sabes que eso va contra las normas de seguridad más elementales, aunque alguna vez se haya hecho en estas páginas con el ánimo de facilitar las cosas. Si tienes un método, debería darte igual que se tratara de otra clave. Acláramelo, porfa.
Ah no no,
No tiene por que ser con la misma, lo decía por que en el otro reto me lo preguntaste. No es para hacer nada raro, sólo es para tener más texto. De todos modos si es la misma clave se resuelve el reto al averiguarla XDD.
Tener 2 textos con la misma clave, de todos modos, sólo será útil en el primer bloque de 32, puesto que desde ahí divergirán. Seguramente se podrá sacar alguna pista de ello, pero no es lo que tenía en mente.
El método es el que ya comentaba. Analizar n-gramas en vertical para sacar relaciones entre las f(A[i]), pero dado que ahí no hay estructura, sólo estadística de aparición de caracteres, necesito más material.
Hola, es muy interesante,
Hola, es muy interesante, pero no me acabo de enterar bien:
Se podría pensar en una población de individuos, cada uno de ellos formados por 32 parejas f(A)^F(B), inicialmente generadas al azar, y que luego irían evolucionando, pero ¿cómo evaluamos la aptitud de un alfabeto determinado? ¿como sé que es mejor o peor para nuestros fines que otro cualquiera?. Si puedo llegar a saber eso, entonces podría plantearlo fácilmente.
La idea es la siguiente
Partimos de las frecuencias de aparición de los carácteres en el cifrado (no de las letras en si, si no de sus frecuencias) expresada como números entre 0 y 1, es decir, tenemos una colección de 32 números. Esa será la distribución de referencia a la que nos hemos de acercar.
Por otra parte, un alfabeto dado generará una distribución de probabilidad determinada para las parejas de carácteres en base a las frecuencias teóricas de cada uno de ellos. Una pareja dada de LETRAS tendrá el valor del XOR de sus posiciones en el alfabeto y cada valor del XOR posible estará generado por 32 posibles parejas (16 en realidad, puesto que A^B es lo mismo que B^A). Así, mientras las posiciones siempre darán los mismos XORs, las letras que las ocupen tendrán mayor o menor probabilidad de aparecer, condicionando la distribución final.
Por ejemplo, en un caso muy básico, partimos de un alfabeto de 4 letras como el siguiente:
Donde supongamos que las frecuencias teóricas de los carácteres son las siguientes:
Imaginemos un albafeto candidato
Un cifrado tipo Ci=f'(f(Ai)^f(Bi)) donde f(x) es la función de substitución y f'(x) su inversa genera esta tabla de XOR
Las probabilidades de aparición de las letras serán pues
Es decir
Si esta distribución teórica se acerca a la real del cifrado es que vamos bien. Se trataría pues de buscar una función que nos mida la distancia entre distribuciones y usarla para buscar la convergencia. Como pegas es que las frecuencias en algunos casos sólo se diferencian en el tercer dígito decimal, con lo que el riesgo de falsos positivos y negativos es grande.
¿Lo ves posible?
Pero, con cada alfabeto que
Pero, con cada alfabeto que probásemos tendríamos que codificar un texto largo con él, para medir su distribución ¿no?, o bien probamos con las frecuencias reales de los caracteres del cifrado, como en la última tabla que nos pones. ¿Es así? Eso si lo podría hacer
Para agilizar
Probaria con las probabilidades teóricas que genera. Cifrar un texto nos consumiria mucho cálculo
Ni en mil años
Ni en mil años se me hubiera ocurrido un planteamiento semejante. Es muy sutil, esperemos que dé resultados. Este fucked hijo de AESito está resultando más duro de lo que pensaba.
Cifrado largo (con otra clave)
https://www.dropbox.com/s/7bjrmz2h8ed5ba4/Fucked-OTP-largo.txt
Pues si lo entendiste
Pues si lo entendiste reexplícamelo, porfa, porque creí haberlo capiscado, pero ya no me cuadra...¿qué son la frecuencias teóricas de los caracteres?
Las del castellano
Yo acostumbro a usar las de la Regenta (calculadas por Agustín) que salen en la Wikipedia
http://es.wikipedia.org/wiki/Frecuencia_de_aparici%C3%B3n_de_letras
Hummm
Ese texto largo, ¿es el mismo concatenado muchas veces?
No
Pero en las novelas los nombres se repiten... Glusp!
Ah ya veo
Hay un problema de formato. Si te miras el fichero del dropbox verás que va hacuendo particiones cada tanto. ¿Tienes una versión bien concatenada aunque haya que meterla en un ZIP?. Si no ya mirare yo de generarme una.
Lamentablemente
Estaré sin acceso al ordenador toda la semana
Perfecto
Sí, se puede aplicar, ya sólo necesito un procedimiento sencillo para generar la tabla Xor de cada alfabeto, y me pongo a implementarlo. ¿Sugerencias?
Es decir, cómo genero esta tabla para cada alfabeto, cuál es el procedimiento:
Lo que faltaba
Ahora se han aliado LlamameX y Tokamak. Sálvese quien pueda.
¡Pero si no sé cómo! no sé
¡Pero si no sé cómo! no sé como generar esa dichosa tabla para cada alfabeto. ¿Tú sabes? solventado eso está chupao
Perdonad, estaba fuera este puente
A ver es sencillo lo de la tabla, se genera igual que se cifra. Se obtiene el valor de la letra de la fila y la columna en el alfabeto candidato, se xorea y se representa como el valor de ese xor en el derivado.
Vale, pero ¿puedes explicar
Vale, pero ¿puedes explicar como llenas la tabla del ejemplo con el cifrado Ci=f'(f(Ai)^f(Bi)) ?
Pues como te decia
Tal y como se cifra f(Ai) es la posición en el derivado (en nuestro caso del candidato) de Ai si lo representamos como número, que es lo que nos interesa para el XOR. En el ejemplo f(C)=3. (Si lo representaramos como letra seria la correspondiente al alfabeto base en esa posición f(C)=D). La inversa f'(Ai) será la letra del alfabeto derivado de esa posición. En el ejemplo, si representamos como número f'(3)=C.(o f'(D)=C si se hace como letra)
Así por ejemplo en la posición de la tabla (1,2), empezando en 0, tenemos
¡Por fin!. Sencillísimo, sí
¡Por fin!. Sencillísimo, sí,pero no lo acababa de coger. Me gustan tus ataques, por lo elegantes y "académicos" que son (una vez que los entiendo, horas o semanas después, claro).
En cuanto llegue a casa me pongo a implementarlo.
Pues ahora...
...haz el favor de explicarlo tú, a ver si así me entero yo.
Espero ver el ataque en marcha. A mí me parecía que el FUCKED iba a ser indestructible, pero ya empiezo a ver su final.
[3359] Resumen del magistral comentario
Puede que resumir aquí el magistral comentario «Me alegro que resulte interesante» del sábado 10 de noviembre de 2012 que no tiene ninguna farfolla matemática y que tan amablemente nos dejó LlamameX hace hoy, precisamente, un mes; nos permita llegar a entender algo más de todo este interesante y avanzado reto criptológico. Aunque el aparato matemático y la programación que se llegue a implementar nos sean inasequibles siempre puede quedar algo que despierte nuestra imaginación o siente las bases de su futura comprensión:
Gracias por vuestro gran esfuerzo y paciencia para que quienes no tenemos una base matemática y de programación tan avanzada como ahora quisiéramos, podamos llegar a entender día a día, semana a semana... la casi totalidad de este singular reto.
Saludos cordiales,
Pedro Fernández
--
P.S. Puede que mi comentario haya quedado mal anidado dado que quería ubicarlo como respuesta al de LlamameX y ahora aparece en esta otra ubicación que es en mi opinión demasiado petulante porque quita protagonismo a los otros comentarios que son los verdaderamente importantes. Os ruego me disculpéis.
Gracias, Pedro
Gracias por tu resumen. Cada día me maravilla más la sutileza de nuestros brillantes criptoanalistas, de los cuales últimamente es LlamameX el que puebla mis pesadillas.
Debo reconocer -como ya hice en su día- que ha dado una vez mas en el clavo con el asunto de la A traducida a Ñ en el alfabeto derivado. Lo digo porque sé que no devalúo el reto al hacerlo, ya que él está seguro de lo que dice.
Ya sabía yo que debería haber desordenado el alfabeto para cada bloque, pero entonces me pareció que era demasiado retorcimiento.
Los cifrados son como las presas hidráulicas: una vez que se abre una grieta, por pequeña que sea, el hudimiento está asegurado.
(Parcos) resultados hasta ahora
Bueno, ahora que Pedro nos ha refrescado un poco la memoria, os cuento lo que he conseguido, aunque me he desanimado un poco porque hasta ahora no he logrado que el algoritmo evolutivo converja adecuadamente.
Los alfabetos que logré tienen el espacio como A, lo que contradice el hallazgo de LlamameX, confirmado por Agustín.
Por ejemplo obtuve el siguiente alfabeto
Con su tabla de verdad:
Que nos proporciona el siguiente listado de frecuencias. La primera columna de cifras son las frecuenciasde referencia que utilizo habitualmente, la segunda son las probabilidades de aparición de las letras del alfabeto analizado.
Como función de coste sumo las diferencias (en valor absoluto) de las frecuencias reales y de las probabilidades de aparición de cada caracter. Para este caso veréis que es 0,397340914192. Cuanto más pequeño, mejor.
Otros candidatos podrían ser:
Hasta ahora solo tengo esto, pero quizá se pueda perfeccionar. Espero sugerencias de la distinguida concurrencia..
Pues algo no va bien
Porque la primera letra del alabeto derivado es, como dedujo LlamameX, la Ñ.
En principio parece correcto restar las frecuencias entre cada candidato a alfabeto derivado y las del alfabeto ordenado. El problema es la forma de obtención de cada alfabeto derivado, que no acabo de pillarla. Si se trata de ir variando al azar -anque sea genéticamente- tenemos una explosión de 31!, lo que quizá sea excesivo
Por otra parte, la probabilidad de que se produzca un "cruce" entre dos letras es proporcional al producto de sus respectivas frecuencias. Si se hace una tabla de 31 * 31 productos de ese tipo, se podría buscar la combinación de letras resultantes que se adapten a ese espectro. Imagino que en muchos casos las diferencias serán irrelevantes, pero en algunos quizá se puedan discernir los emparejamientos.
Es sólo una idea, partiendo de mi desconocimiento de lo que en realidad buscáis.
Imagino que atacas el reto original
Si es así puedo darte algunas restricciones sacadas de los n-gramas que puedes mirar de incorporar (tengo algunas más en el segundo texto más largo). Hay que tener en cuenta, sin embargo, que las frecuencias de algunos caracteres pueden llevar a engaño, puesto que cuando nos vamos de las posiciones más frecuentes se contaminan mucho por resultados iguales pero de fuentes distintas. También la A y la E pueden intercambiar sus valores dependiendo del texto.
Las que obtuve para ese reto eran
Cada trigrama ABC es una relación del tipo f(A)=f(B)^f(C), con lo que en la tabla vendría a ser A=f'(f(B)^f(C)). Ñ** indica que la Ñ es el elemento neutro, con lo que es válido para cualquier carácter *
Un momento. Está mal. probé
Un momento. Está mal. probé con frecuencias teóricas, las de la primera columna, pero la diferencia se ha de hacer con las del cifrado. Craso error. Volvemos a empezar.
Nuevos resultados
Bueno, ahora está mucho mejor. Aunque la convergencia es muy débil, la gráfica de la función de coste tiene muchos dientes de sierra, en vez de presentar un suave descenso uniforme.
(Aún no he aplicado las restricciones que me sugieren llamameX)
El primer alfabeto obtenido es éste:
Con su tabla de verdad:
Que nos proporciona las frecuencias: (La primera columna de cifras son las frecuencias del reto original, la segunda la del alfabeto de acuerdo a la tabla de verdad.
La suma de diferencias da 0,2482
En total obtuve tres alfabetos:
Entonces ¿Sirven para algo?
No da resultados
Esos alfabetos generan las claves
Claramente incorrectas. Por lo demás no se si das los pesos correctos para la comprobación puesto que queda una distribución muy plana. La distancia máxima entre valores en la distribución del cifrado es de 0.06 mientras que en la que obtienes es de 0.008.
Sigo atento
Sigo atento vuestros trabajos, conteniendo el aliento.
¡Ay Dios! La he vuelto a pifiar
Los pesos que hay que aplicar SON LOS DE LAS FRCUENCIAS REALES, a restar de las del cifrado. ¿No? pues a rehacer el tinglado.
Paciencia, porfa,.
Páginas
opinar