Cifrado por batido de bits
Por Agustín
Que sepáis que he desarrollado este invento contraviniendo las rigurosas consignas del personal de la clínica psiquiátrica “El Puzzle Asesino”, donde me han prohibido hasta hacer el sudoku del periódico, porque dicen que mi debilitado cerebro puede hacer un fundido en negro definitivo en cualquier momento. Tuve que garabatear el rosco en los márgenes del prospecto del Haloperidol, y después, aprovechando la visita de un sobrinito, usar su esmarfón para mandarle a Admin este documento. Por cierto, cómo se sufre con esos teclados táctiles, donde nunca sabes si has pulsado tres veces el 6 para escribir una O, o cuatro veces el 9 para que salga una Z, y lo que aparece en la pantalla es un burlón emoticono...
Ya sabéis que, en mi opinión, un reto imposible de resolver no tiene ningún interés, por lo que he preparado un artilugio relativamente simple, casi minimalista, diría yo. Como la diferencia esencial entre los cifrados modernos y los clásicos es la manipulación de bits, he preparado un ejercicio que trata de demostrar que, en efecto, los tejemanejes con estas unidades básicas de información confieren, de por sí, cierta solidez a los cifrados. Para ello me he limitado a introducir cierta entropía en la cadena de bits del texto plano, en función de la clave, renunciando a realizar ninguna operación adicional, ni siquiera un miserable XOR. El asunto consiste en ir eligiendo bits, en función de los valores de las letras de la clave, e ir colocándolos a la izquierda o a la derecha de la ristra, como sugiere la figura:

Me adelanto a presentar mis excusas, en el caso de que el artefacto ya esté inventado.
El alfabeto
Vamos a manejar un alfabeto formado por 32 símbolos, que contienen veintisiete letras (con la Ñ), más un separador, y cuatro signos de puntuación.

De manera que podemos asignar a cada símbolo un código de cinco bits:

La clave
La clave constará de un conjunto símbolos del alfabeto, de longitud ilimitada, a la que se le aplicarán los tratamientos que luego se explican.
El problema de la clave corta
Aunque soy un aficionado mindungui, no creáis que no me doy cuenta de ciertas debilidades clamorosas que tiene el bicho, aunque otras se me escaparán, seguramente. Por ejemplo, si la clave es corta, los bits movidos serán muy pocos, y la mayor parte del texto plano quedaría a la vista. Como la ley de Murphy -¡el de la cerveza no, hombre!- exige considerar al usuario como un perfecto imbécil, y tampoco podemos obligar a nadie a escribir y recordar claves kilométricas, haremos que la clave se expanda hasta medir 160 caracteres como mínimo, mediante un sencillo truco: Se irán añadiendo letras con los valores.

donde L es la longitud de la clave inicial. Es decir, si la clave introducida por el indolente usuario es “VALE”:

La V nos daría la W, la A nos daría la B, etc. La completaríamos añadiendo letras de aquesta guisa:

Parecerá una chorrada, y probablemente lo sea, pero así tenemos más probabilidad de mover muchos más bits, aunque es posible que algunos se muevan varias veces y otros ninguna, por lo que no se garantiza que no queden grupos reconocibles, hélas. Debo adelantar que luego se modificará el alfabeto, de forma que las posiciones de los símbolos añadidos, WBMF... etc., no guardarán una relación tan sencilla con los que les preceden.
Tratamiento del alfabeto
A partir de la clave se trastocará el alfabeto, vieja costumbre de discutible valor práctico, pero a la que los viejos aficionados (y más aún los aficionados viejos) no podemos sustraernos.
Las posiciones de las letras de la clave inicial nos van a indicar las letras que extraeremos del alfabeto base para incorporarlas al alfabeto modificado. Para obtener la primera letra calcularemos la suma de las posiciones de las letras de la clave, módulo 32:

De manera que la primera letra a extraer será la “J”.
A partir de ese punto obtendremos la posición de las letras a extraer mediante

es decir, vamos sumando, cíclicamente, las posiciones de las letras de la clave, haciendo módulo con la longitud del alfabeto base menguante, L-alfa.
En este caso obtendríamos el siguiente alfabeto:

Re-evaluación de la clave
Al modificar el alfabeto, la clave original, expandida, tiene ahora las siguientes posiciones:

cuya distribución pseudoaleatoria (¿oíste, viejo?) servirá para suministrar entropía a los bloques de bits.
El algoritmo de cifrado
Aparte de alguna triquiñuela para darle algo de fuerza al sistema, el algoritmo consiste básicamente en los siguientes pasos:
1. Descomponer el texto plano en bloques de 32 caracteres. Si el último bloque tiene menos de 32 caracteres, se completará con letras del alfabeto base obtenidas a partir de las posiciones de la clave expandida, mediante:

donde K(i) son las sucesivas letras de la clave.
Se añade 1, tanto a la posición de la letra clave como al valor del índice, para evitar todos los productos nulos que se darían para todas las ocurrencias del primer carácter del alfabeto derivado en la clave, y del primer carácter de la misma.
2. Convertir cada bloque en una ristra de bits, a razón de cinco bits por símbolo, según se mostró anteriormente. Eso nos da bloques de 160 bits.
3. Ir extrayendo de la ristra los bits que tengan las posiciones dadas por:

4. Colocar el bit extraído al principio (izquierda) o al final (derecha) de la ristra, según la siguiente tabla:

5. Juntar los bloques y tomar los bits de cinco en cinco para extraer las letras correspondientes del alfabeto.
La fuerza del cifrado
Según mis cuentas, si se consigue batir bien la tortilla nos encontraríamos con una ristra desordenada de 160 bits. Eso significa que un ataque de fuerza bruta debería ensayar 160! permutaciones, es decir, 4.7 * 10^284, una robustez bastante superior a la del fenecido ACYNOS. Pero lo más probable es que el desorden introducido no haya sido suficiente, y también estoy seguro de que los avezados analistas, como mellon, sqrmatrix y los demás, sabrán encontrar atajos que simplifiquen el problema, quizá atacando la falta de aleatoriedad del batido de bits.
El descifrado
El descifrado consiste en los siguientes pasos:
1. A partir de la clave, se genera el alfabeto derivado como se definió en la fase de cifrado.
2. Se expande la clave y se le asignan a sus caracteres las posiciones en el nuevo alfabeto, igual que en el cifrado.
3. Se descompone el texto cifrado en bloques de 32 caracteres.
4. Se codifica cada bloque en binario usando cinco bits por carácter.
5- Se revierte el proceso de dispersión de bits tomando la clave por el final, y aplicando las reglas establecidas en el cifrado, es decir, tomar el bit de la derecha del bloque o de la izquierda, según los valores de K(i) y de (i) (ver la tabla correspondiente).
6. Se inserta el bit en el bloque en la posición dada por

7. Al terminar de recorrer toda la clave en sentido inverso, se decodifican los bits resultantes, tomados de cinco en cinco, con lo que se obtendrán los caracteres en claro, si todo ha funcionado bien.
Un ejemplo
Imaginemos que el texto fuera:

El primer bloque de caracteres sería:

Al que le corresponde el siguiente código binario:

El batido de bits proporciona:

que corresponde a los siguientes símbolos del alfabeto:

El cifrado completo resulta ser:

Al descifrarlo obtenemos:

Obsérvese que hay unos caracteres aleatorios añadidos al final, que deben ser descartados.
El reto
Aquí tenéis un texto cifrado con la Omelette, para que podáis hincarle el diente.

El fichero completo (1585 KB) está en:
Espero que LlamameX tenga tiempo para implementar uno de sus mundialmente famosos JavaScripts, y colgarlo de la “nube” antes de que el FBI se lo impida.
Aparte de los puntos que Admin tenga a bien regalaros, yo puedo ofreceros una alcachofa de ducha escocesa, un instrumento de lavativa king size, y una cachiporra quitapenas, que he sustraído habilidosamente al personal de la clínica.
Un cordial saludo a todos.
Agustín
Estadística del batido
Agustín11 Abril 2012 - 8:52pm
La combinación de los valores de la clave K[i] y del índice i que se usa para calcular la posición del bit a extraer, con la fórmula
Pos = (K[i] + 1)(i + 1) modulo 160no produce una buena aleatoriedad. No es cierto que haya valores inalcanzables, pero desde luego algunos son mucho más probables que otros, entre 156 y 13. El cero es el valor más probable, con lo que más o menos la mitad de las veces el primer bit irá a la izquierda, no produciendo cambio alguno.
No creo esto que sirva para mucho, porque los valores concretos dependerán de la clave, pero he calculado la frecuencia de cada posición a extraer, probando con todos los valores posibles de la clave [0..31] para cada índice posible [0..159]. Nunca se sabe lo que otros pueden lograr con la información a la que uno no le ve valor alguno
Tras los posts perdidos: El estado de la cuestión
Agustín31 Marzo 2012 - 12:27pm
He esperado varios días para ver si el sitio -o sea, admin- recuperaba algunos de los posts que han desaparecido de este foro, que no recuerdo exactamente cuántos son. Me da la impresión de que el "crash" se ha llevado también el interés por la pequeña Omelette que algunos compañeros -y amigos- se empeñaban afanosamente en mantener. Creo que en mi último post "El estado de la cuestión", trataba de resumir las principales aportaciones de los analistas kriptopoleros para resolver este pequeño ejercicio de criptografía mindungui. Lo de mindungui va por el autor y el engendro en si, porque algunos de los ataques han tenido una brillantez digna de mejor marco que el pobre acertijo al que han sido dirigidos.
Sin menospreciar otras aportaciones, como las de Periquillo entre otros, hay que destacar dos elegantísimos estudios, uno de LlamameX, que a partir del alfabeto derivado es capaz de determinar los 32 primeros caracteres de la clave (sobre todo si es legible). Por supuesto dicho alfabeto no se conoce en el cifrado problema -ya que depende de la ignota clave- pero el trabajo permitiría acotar la complejidad del sistema a un modesto 32!
La otra pieza maestra es la sorprendente técnica de sqrmatrix para ubicar los bits originales del texto plano a partir de los bits del cifrado, mediante una ingeniosa aplicacion de la operación AND a la plantilla de bits. Por supuesto, al igual que en el caso de LlamameX, la ristra de los bits del cifrado es desconocida a falta del alfabeto derivado. De nuevo, y de forma definitiva, la complejidad queda acotada a 32!
Me he decidido a repetir esta información para que, en el caso de que el reto quedara abandonado, estuvieran a la vista, al menos, los principales logros consegidos por los atacantes.
Os agradezco a todos la atención prestada.
Agustín
Tampoco he abandonado yo
sqrmatrix8 Abril 2012 - 12:04am
Sigo en ello, aunque con mis típicas ausencias, pero sin dejar de pensar de vez en cuando en el reto. Aunque descarto ya la posibilidad de un ataque contra el criptograma a secas, sigo con el ataque con texto claro. No sé si será posible. Estoy desarrollando algo que no sé si permitirá un ataque con texto en claro sin necesidad de conocer el alfabeto desordenado, pero lo que tengo ya es interesante (al menos para mí), aunque no permita resolver el reto ni con texto claro. Estoy batallando con ello, porque unas veces me da la impresión de que sí permitirá el ataque con texto claro, y otras veces no.
Tenía ya la impresión de que no podría realizar el ataque con texto claro, y estaba escribiendo lo que había conseguido para publicarlo aquí, cuando de repente he visto un indicio que quizá me permita el ataque (con texto claro, y sin conocer el alfabeto desordenado). Tardaré algo de tiempo en escribir lo que tengo, porque tengo que mirar esta posibilidad.
Interesante
Agustín8 Abril 2012 - 2:27pm
Yo te aseguro que es interesante para mucha gente. Esperamos tus noticias.
Todavía me voy a retrasar un poco más
sqrmatrix15 Abril 2012 - 11:31am
Se me está alargando la cosa. Estoy ahora codificando lo que tengo para ver que funciona, y se me van abriendo nuevos caminos, que tengo que pensar, y codificar. De momento lo que estoy probando funciona, y creo que voy a poder realizar el ataque con texto conocido sin necesidad del alfabeto desordenado. Vais a tener que tener un poquito de paciencia hasta que termine el desarrollo, porque tampoco puedo dedicarle mucho tiempo. De todas formas, este ataque no permitirá resolver el reto (como de costumbre :) ).
No tenemos prisa
Agustín15 Abril 2012 - 1:49pm
Lo más probable es que lo termines antes de que termine la crisis económica.
Por otra parte, esos atques con texto conocido, aunque no resuelven el cifrado, son unos ejercicios muy interesantes.
Un saludo
Yo tampoco he abandonado
periquillo2 Abril 2012 - 9:43am
Yo tampoco he abandonado. De hecho, mi sistema encuentra la solucion (probado con la encriptacion con la clave VALE) pero en medio de 40.000 falsos positivos más. Si encuentro que diferencia la solucion de los 40.000 falsos prositivos sin tener que probar 40000 ^ 5 posibilidades, lo aplicare a los 40.000 candidatos que tengo para el texto.
Reconozco que he bajado exponencialmente mi tiempo dedicado al problema y que ahora simplemente me pongo a pensar sobre él un par o tres de veces a la semana.
un saludo
Me alegro
Agustín2 Abril 2012 - 1:58pm
Me alegro de verte por aquí. Esperaremos a que las ideas maduren.
Un saludo
Aún no lo he abandonado
LlamameX31 Marzo 2012 - 8:29pm
He levantado el pie del acelerador pero no he puesto punto muerto. Tengo un medio ataque basado en las teorías esotéricas de los siameses pero necesita, si no hay mucha suerte, de bastantes días de cálculo. Estoy buscando alguna manera de reducirlo pero francamente lo veo difícil.
No adelanto más hasta tener resultados que contar, sólo que sepas que sigo en ello aunque sea a punta de gas.
Me alegro
Agustín1 Abril 2012 - 1:11am
Me alegro de verte por aquí. Tengo muchas ganas de ver a tus siameses en acción.
Desandar lo andado
LlamameX14 Marzo 2012 - 2:55pm
Después de estrellarme contra el muro he caído en que estaba partiendo de un supuesto equivocado. Estaba asumiendo que el esquema de Omelette era sustitución+desorden cuando en realidad no hay ninguna sustitución. El alfabeto derivado "simplemente" (entre comillas puesto que para nada es simple) se usa para codificar el caracter durante la fase de desorden. De hecho, si no desordenáramos no habría cifrado alguno, el texto quedaría en claro.
Esto, que debería haber sido obvio para mi, puesto que he codificado el algoritmo, me ha mantenido en un camino equivocado que ahora me dispongo a desandar.
El hecho de que no haya sustitución, curiosamente, no simplifica el ataque. Al contrario, me lo dificulta enormemente. Si una columna de carácter mantuviera sus 5 bits intactos no me daría ninguna información sobre el alfabeto derivado, puesto que la codificación no dejaría ningún rastro en la columna final (que mostraría el carácter en claro de esos 5 bits). De hecho el máximo de información se obtiene en el caso de mantener 4 bits, donde podemos intuir una relación entre carácteres aún manteniendo una relevancia estadística.
Así, la columna interesante sigue siendo la 21, pero la aproximación tiene que ser otra. Sigo creyendo que tenemos 4 bits (es la única manera en que se explican las frecuencias bajas), pero los caráteres presentados NO son los del alfabeto derivado, son los del texto en claro algo desviados por haber perdido un bit y posiblemente desplazar el hueco dejado. La columna de carácter seguramente tampoco estará en la misma posición relativa en el bloque que la que ocupaba en el texto en claro.
Imaginemos pues que los bits originales de la columna de caracter son [b1,b2,b3,b4,b5]. Tendremos, asumiendo la hipótesis del mantenimiento del orden, las siguientes 10 posibilidades de tener 4 bits:
No tenemos ni idea del valor de los bits individuales que representan la posición del carácter en el alfabeto derivado. Lo que sí sabemos es que la frecuencia de aparición estará muy relacionada con la del carácter en claro que representan y que la diferencia de un bit la relacionará con la del carácter con la que comparte 4 bits iguales. Los llamaré siameses.
La primera cosa que deberemos determinar es cual de los 10 esquemas corresponde al reparto de bits. Una primera aproximación es asumir que la suma de las frecuencias de los dos carácteres siameses debería coincidir con la suma de esos mismos carácteres en una distribución "regenta", aunque ese es un criterio muy complicado de verificar puesto que deberíamos comparar entre todas las posibles parejas de ambas distribuciones (col 21 y regenta). Una vez hecho esto, asumiendo acertar, aún tendríamos que determinar que integrante de cada pareja corresponde con la de la otra distribución. Eso son 2^16 posibilidades.
Otra línea que parece más prometedora es partir de que las posiciones entre siameses comparten los mismos 4 bits en todos los casos. Debería ser más o menos viable buscar que bits determinan esas posiciones en base a que los siameses deben tener una distribución parecida, ya que comparten 4 bits y podemos asumir que el quinto va a ser bastante aleatorio, ya que no depende de ellos. Esto junto con que podemos esperar que determinados carácteres se representen a sí mismos (coincidan las distribuciones de la col21 con la regenta) puede ayudarnos a determinar cual de las 10 es la más razonable. (Punto de atasco actual XD)
Una vez consigamos esto debería ser bastante mecánico (como hacer sudokus) obtener el alfabeto derivado y atacar la clave.
Al estilo Bletchley
Agustín14 Marzo 2012 - 7:20pm
Me recuerda el estilo de aquellos analistas, que ponían nombres a los pequeños grumos de orden que creían percibir en aquél montón de signos sin sentido, dicho sea esto sin pretender comparar la pobre Omelette con el cifrado alemán.
En efecto, no hay sustitución, sino tan solo desorden o, al menos, un intento de crearlo. Me hubiera gustado utilizar un buen generador de números pseudoaleatorios, pero al final opté por generar entropía a partir de la clave, exclusivamente. Decidí que el algoritmo sería lo más simple posible: "tchac, tchac, tchac", batir los bits a izquierda y derecha, y nada más.
Trataré de pensar en lo que dices, para ver si se me ocure algo; pero resulta mucho más fácil inventar un galimatías que tratar de resolverlo.
Un saludo.
Será en lo único en que nos parecemos XD
LlamameX15 Marzo 2012 - 4:26pm
Madre mía, compararse con esos monstruos...
Bueno, siguiendo con la nueva la nueva línea de investigación. Dándole más vueltas a la idea veo que en el fondo no es tan importante cual de los 10 esquemas es el usado. Es mucho más revelador averiguar si el bit ajeno queda a la derecha o a la izquierda.
Me explico. Si estamos en el caso [b,b,b,b,x] las posiciones de los carácteres siameses serán consecutivas en el alfabeto derivado, mientras que si estamos en [x,b,b,b,b] estarán separadas 16 posiciones. Dado que no tenemos idea de los valores de los bits comunes ni hay relación entre los carácteres no siameses nos va a dar igual lo que valgan. No los tendremos en cuenta ahora.
Así, si podemos realmente agrupar las 16 parejas de siameses correctamente podemos empezar a especular con la clave a partir de un posible alfabeto derivado.
Podemos intentar trabajar con los 6 primeros carácteres del derivado a ver si pueden ser generados por algúna clave con texto en claro (no aleatoria). Esto son, en el caso [b,b,b,b,x], 3 parejas de siameses y en el [x,b,b,b,b] 6 carácteres no siameses.
En el primer caso lo tenemos relativamente sencillo puesto que son 16*15*14(3 parejas de 16 posibles)*2^3(ordenaciones de elementos de las parejas)*32(posibilidades del caracter A)=860.160 combinaciones. El segundo caso es muchísimo más complicado ya que tendremos que analizar 16*15*14*13*12*11(6 parejas de 16)*2^6(escoger el primer o segundo elemento de cada pareja)*32(posibilidades del caracter A)=11.808.276.480, es decir, inabordable para mis medios.
Y eso siempre habiendo acertado emparejando siameses.
Con eso podríamos averiguar en paralelo carácteres de la clave y del alfabeto derivado. Si la clave es aleatoria, pues ni eso. Lo que si parece que se posibilitan son los ataques de diccionario, pues permitirian comprobar si se generan siameses congruentes con las distribuciones de la columna 21.
Razonamiento complejo
Agustín15 Marzo 2012 - 5:05pm
Espero que sqrmarix y los demás se esten enterando de algo, pero a mí me cuesta bastante seguir tu razonamiento. Tal vez podrías detallarlo más con algún ejemplo seguido paso a paso, como hizo sqrmatrix recientemente con sus plantillas de bits y las operaciones AND.
Por ejemplo, no entiendo por qué es tan importante la "columna 21", que parece un término de un relato bélico.
Yo tampoco lo acabo de entender
periquillo15 Marzo 2012 - 6:35pm
Y lo que tampoco entiendo en que te basas para suponer que la columna 21 tiene al menos 4 bits no alterados y pertenecientes al mismo caracter.
Casi ni yo mismo me sigo XD
LlamameX15 Marzo 2012 - 6:34pm
La verdad es que efectivamente esto ya esta casi en el plano esotérico. Para entendernos, Omelette es durísimo. Al principio, llevado por la idea equivocada de la sustitución lo vi aborbable y hasta fácil, ya que se podían encontrar suficientes indicios estadísticos que permitieran obtener el alfabeto derivado y de ahi la clave.
Sin la sustitución nos quedan pocos clavos ardiendo a los que agarrarse, de hecho sólo me queda la columna 21. ¿Por qué la veo importante? por que es la única que tiene una distribución de frecuencias que puede asociarse a una aproximación a un alfabeto. Tenemos frecuencias más o menos altas en un extremo y muy bajas (cercanas al 0) en el opuesto. Esto sólo ocurre tan claramente en esta columna. En las demás la entropía (no la he calculado) debe ser muy alta. La única que se le aproxima en algo es la 20 pero ya es bastante más rara, aunque posiblemente tenga 3 bits originales.
Si tenemos en cuenta el comportamiento de una columna "normal" (fuera de estas 2) vemos que tienen una distribución muy uniforme y lo que es más importantes, sin valores extremos. Esto nos lleva a pensar que a nivel de bit el batido genera valores muy aleatorios. Por eso encontrar una columna con (casi) ceros es una anomalía estadística que sólo puedo justificar por que retenga mucha de la información original.
Si la columna estuviera intacta (es decir 5 de 5 bits) tendríamos en ella una distribución perfecta para el idioma y además con los carácteres originales. Dado que no es así hemos de haber perdido alguno. Asumo que sólo hemos perdido 1 ya que en el caso de haber perdido 2 sería muy difícil mantener el 0, puesto que los 2 bits ajenos casi seguro provendrían de carácteres originales distintos, con lo que la aleatoriedad sería muy alta.
Además, la teoría parece cumplirse. Si tenemos 4 bits (los que sean) del caracter original y les añadimos un bit ajeno aleatorio, tendremos el efecto de obtener más o menos un 50% de cada uno de los dos carácteres que comparten esos 4 bits. Por ejemplo si codificamos "_" como 11011 y "C" como 11001 y hemos perdido el 4º bit, todas las instancias de "_" y "C" nos dejaran 1101x (o x1101, según haya quedado la columna), dado que consideramos x aleatorio tendremos un 50% de 11011 y otro 50% de 11010 (que representaremos por carácteres distintos a "_" y "C" en el cifrado, claro). Esto parece confirmarse en el caso sintomático de la columna 21 con los 0.008% del ":" y la "W" en la columna 21, dificilmente explicables si no es por esta causa.
La otra cuestión es la hipótesis salvadora del manteniemiento del orden. Considero terriblemente improbable que se mantengan 4 bits de una columna del original en una (otra) columna del cifrado si esos bits han de provenir del batido. Creo que sencillamente es imposible que sea así. La única manera razonable de tenerlos es que nunca se hayan ido, que, como decía, hayamos perdido uno por el camino y hayamos llenado el hueco con uno ajeno. Dado que al sacar el bit nos llevamos también su hueco a uno de los extremos del bloque, el bit ajeno sólo puede quedar a la izquierda o a la derecha de los 4 que nos han quedado. De ahí las formas [x,b,b,b,b] o [b,b,b,b,x].
A partir de ahí viene el resto del razonamiento. ¿Cómo explotarlo sin tener idea de la codificación en bits?. Pues poco se puede hacer salvo tratar de confirmar que un determinado inicio de alfabeto derivado se corresponda con un determinado inicio de clave. Eso se podría hacer sin recurrir a toda este montaje pero entonces nos enfrentaríamos con un terrible 32! de combinaciones posibles y la incapacidad de abordarlo con recursos domésticos.
Todo esto a la espera de que a alguien inspirado de verdad se le ocurra un ataque más ingenioso. Le aplaudiría a rabiar.
Ya me parecía a mí
Agustín16 Marzo 2012 - 1:37am
El sentido del humor que no falte. Lo que a mí me falta es pesquis. Concretamente, no consigo dar con la Columna 21, perdida en combate por la selva de bits. Tal como entiendo el invento, la escasa aleatoriedad del batido depende de los valores de las letras de la clave expandida -que dependen del alfabeto derivado, que a su vez depende de la clave inicial-, y de si los valores pares o impares están en posiciones pares o impares. Como tú ya has señalado con anterioridad, hay claves buenas -crean más entropía- y claves malas, independientemente de su longitud, y además el usuario no puede predecirlo, salvo que sea un genio del cálculo mental. Con todo este preámbulo, no concibo que haya una columna que juegue un papel primordial, por lo que deduzco que esa circunstancia -la posición de la columna importante- dependerá de la clave ¿estoy en lo cierto? ¿Te estás refiriendo a lo que ocurre con la clave "VALE"?
Bueno, creo que tú también te mereces un aplauso, aunque tu análisis esté ya en el reino de lo esotérico.
El ejemplo
sqrmatrix10 Marzo 2012 - 12:35pm
Ok, debería haber puesto un ejemplo en la anterior explicación. Pero como nunca es tarde si la dicha es buena, ahí va el ejemplo.
Voy a trabajar con el primer bit del texto del Quijote con la clave "VALE" y el alfabeto desordenado "F.,KOJLX:;AQV_BSZNÑIUWYERCDHMTGP".
Definimos ahora la máscara que representará las posibles posiciones que puede ocupar este primer bit. Como no sabemos dónde podrá estar, todas las posiciones serán posibles, así que comenzamos definiendo la máscara como:
Paso 1:
Tomamos el primer fragmento de texto, con su correspondiente fragmento de criptograma:
Obtenemos las codificaciones en binario de ambos fragmentos, utilizando el alfabeto desordenado:
Leemos el primer bit de la codificación del texto (porque estamos obteniendo la posición de este bit en el criptograma). En este caso, el primer bit de la codificación del texto vale "1". Este valor estará presente en la codificación del criptograma, por lo que las posiciones que puede ocupar este bit en el criptograma serán aquellas que ocupen los bits con valor "1". Los bits con valor "0" serán posiciones prohibidas.
Así, pues, ya podemos descartar posiciones en la máscara. Para ello, basta hacer un AND lógico entre la máscara y la codificación del criptograma:
Repetimos este proceso con el siguiente fragmento de texto. Nótese que ahora la máscara ya no tiene todos los bits activos, es decir, que hemos reducido las posibilidades de ocupación del primer bit del texto en el criptograma. Cada paso irá, normalmente, reduciendo estas posibilidades, hasta que quede sólo una.
Paso 2:
El siguiente fragmento de texto es:
Y su correspondiente fragmento de criptograma es:
La codificación del texto es:
Y la del criptograma:
El primer bit del texto vale ahora "0". Esto significa que este bit sólo puede estar, en el fragmento del criptograma, en las posiciones que ocupen los bits que valen "0". No podemos hacer AND directamente entre la codificación del criptograma con la máscara porque las posiciones que ahora son válidas están codificadas como "0", con lo que quedarían en la máscara borradas estas posiciones. Pero si invertimos los bits de la codificación del criptograma obtendremos estas posiciones válidas con valor "1", y ya podremos aplicar el AND lógico.
Por cierto, hacemos el AND lógico porque las únicas posiciones que puede ocupar el bit serán aquellas que sean permitidas simultáneamente en la máscara y en la codificación del criptograma.
La inversión de los bits de la codificación del criptograma es:
Ahora ya podemos hacer el AND lógico:
Repetiremos los pasos, utilizando los razonamientos de los dos anteriores pasos:
Paso 3:
El primer bit es "0":
Paso 4:
El primer bit es "0":
Paso 5:
El primer bit es "0":
Paso 6:
El primer bit es "0":
Paso 7:
El primer bit es "0":
En este punto, observamos que en la máscara hay un único bit activo, o lo que es lo mismo, que tenemos una única posición que puede ocupar el primer bit del texto. Esta posición es la posición 51 (empezando a contar desde 0). Con esto, ya podemos determinar el valor del primer bit del texto correspondiente a cualquier fragmento de criptograma, pues basta consultar el valor del bit en la posición 51 en el fragmento del criptograma.
Si siguiéramos repitiendo este proceso, veríamos que este bit se seguiría manteniendo activo (de lo contrario, habría un error en alguno de los datos utilizados en el proceso).
Esto se repite para todos los bits de los fragmentos para obtener las posiciones que ocupan en los correspondientes fragmentos de criptograma, de forma que, obtenidas todas estas posiciones, podremos descifrar cualquier criptograma con la misma clave.
Ahora sí, compadre
Agustín10 Marzo 2012 - 6:04pm
Ahora si que se entiende. Me parece una idea muy elegante. Hay que saber manejar bien las funcions lógicas para que se te ocurra ese método. Creo que es un buen paso hacia adelante.
El problema del descifrado se reduce, como en el ataque de LlamameX, a conocer el alfabeto derivado, y redunda en la idea de que el batido en sí es irrelevante. Es un palo para la Omelette, pero las cosas son como son.
Enhorabuena.
No es tan simple
sqrmatrix10 Marzo 2012 - 7:59pm
El ataque necesita también texto en claro, conociendo su cifrado correspondiente. Es decir, que este ataque no se puede llevar a cabo únicamente con el alfabeto desordenado (a diferencia del ataque de LlamameX que sí lo permite con algunas limitaciones). Si se puede obtener el alfabeto desordenado y suficiente texto en claro, entonces este ataque permitiría obtener el resto del texto. Pero sin ambas cosas, no se puede llevar a cabo.
Pasate al hojaldre
tokamak10 Marzo 2012 - 7:19pm
Si hubieras dispuesto los bits en una matriz cuadrada y traspuesto filas y columnas, no estarías en esta situación (y no nos habríamos divertido tanto)
Esta trasposición creo que se parece más a la masa del hojaldre que a la tortilla...
¡Ésa también me la sé!
faxvfnts10 Marzo 2012 - 8:10pm
El hojaldre se prepara, básicamente, con harina y mantequilla; pondré dos ejemplos:
PASTA QUEBRADA
==============
Primero hemos de tamizar la harina a través de un colador de metal o tamiz, para que nos quede bien aireada o "suelta", en un cuenco y agregando una pizca de sal para preparaciones saladas o una cucharada de azúcar para las dulces. Luego cortamos la mantequilla en trozos pequeños y la añadimos junto con un huevo y unas cucharaditas de agua, no más. Ahora hay que formar una bola en el menor tiempo posible teniendo muy en cuenta que esta pasta saldrá mejor cuanto menos se manipule. Una vez se enfríe en la nevera ya podremos hacer la empanada (empanadillas, pastelitos salados... o pasteles dulces si hemos optado por el azúcar en lugar de la sal).
Descífrese al gusto :-P
MASA SEMIHOJALDRADA
===================
Aquí la harina tamizada va encima de la mesa formando un cono o volcán. En el cráter o hueco vertemos la mantequilla que tiene que estar ablandada como si fuera una pomada, unas cucharadas de agua fría, otra de zumo de limón y sal. Aquí sí se debe manipular bien hasta que esté todo unido. Se forma una bola y se deja enfriar al fresco un buen rato.
Ya sé que faltan las cantidades y proporciones pero eso lo dejo para el departamento de cálculo porque en lenguaje binario no se me da bien.
Esta información ha sido sustraída al enemigo en fechas recientes. Espero que os sirva de algo... Agustín, no te desanimes que a mí la omelette aux bits me sigue divirtiendo y sigo aprendiendo que es de lo que se trata. Saludos.
Pues mira
Agustín11 Marzo 2012 - 1:07am
Nunca he sabido hacer esas masas, y creo que voy a probar tus recetas. Igual me salen mejor que las tortillas, je, je.
Nivel
Agustín10 Marzo 2012 - 2:41am
Es frecuente en criptografía que los sistemas de ataque tengan mucha más complejidad y más nivel conceptual que el criptosistema objetivo. Por ejemplo, el método Kasiski es más complejo que el algoritmo de Vigènere. En este caso está pasando lo mismo. Por eso mismo me va a hacer falta un rato para entender tu procedimiento. Espero que los demás participen.
Creo que es un muy buen trabajo, aunque yo no lo pille en la primera lectura. Pasará como cuando llegó un cura nuevo al pueblo: "Habla muy bien", decía un vecino, "no se le entiende nada"
EDICION
El post es en respuesta a sqrmatrix, por supuesto, aunque por error lo he colgado fuera de su hilo.
Esto es lo único que he conseguido
sqrmatrix10 Marzo 2012 - 1:56am
Lo que voy a mostrar aquí no va a permitir resolver el criptograma, pero como de costumbre, quizá dé ideas a otros.
He encontrado un ataque con texto y alfabeto desordenado conocidos. Curiosamente, este ataque, aunque nos permite descifrar todos los criptogramas con la misma clave, no nos permite determinar la clave utilizada.
Por el hecho de conocer el alfabeto desordenado podemos determinar la expresión del criptograma en bits. Obtengamos también la expresión binaria del texto (con el alfabeto desordenado). Es decir, que vamos a trabajar con bloques de bits.
Lo primero que tenemos que observar es que cada bit de cada bloque del texto se corresponde con un mismo bit del correspondiente bloque del criptograma. De esta forma, si el bit del texto vale 1, el correspondiente bit del criptograma valdrá también 1, y lo mismo cuando vale 0.
Si tomamos varios bloques de texto con sus correspondientes bloques de criptograma, observaremos que los valores que vaya tomando el bit de texto de una determinada posición también los tomárá otro bit en otra determinada posición de los bloques de criptograma. De esta forma, observamos que un bit en una determinada posición de los bloques de texto formará una secuencia de valores, secuencia que se repetirá en los bloques de criptograma en otra posición.
Si obtenemos una secuencia suficientemente larga de valores de un bit en una determinada posición de los bloques de texto, esta secuencia será diferente de las demás secuencias del resto de bits y, por tanto, podemos buscarla en los bloques de criptogramas, determinando de esta forma la posición a la que se mueve ese bit desde el texto hasta el criptograma. Haciendo esto en todos los bits del texto, obtendremos todas las posiciones a las que se mueven en el criptograma, y podemos construir una tabla que nos indique este movimiento y que nos permitirá descifrar el criptograma. Ya indiqué en un post anterior que este cifrario es equivalente a un cifrario en el que se usa una tabla para indicar las posiciones a las que se mueven los bits. Es aquí donde obtenemos esta tabla. Esta tabla no nos permitirá obtener la clave, pero sí nos permitirá descifrar el criptograma, y cualquier otro criptograma codificado con la misma clave.
Este procedimiento es bastante simple de realizar. Para ello, utilizaremos máscaras. Estas máscaras tendrán 160 bits (tantos como los bloques de texto y criptograma). Estas máscaras representarán las posiciones que puede ocupar, en el criptograma, un bit de una determinada posición del texto.
Al comienzo, esta máscara tendrá todos los bits activos, porque no sabemos dónde puede estar el bit, con lo que cualquier posición será válida.
En el primer paso, obtenemos el valor del bit en un bloque de texto. Si el bit vale 1, está claro que las posiciones que puede ocupar en el criptograma serán aquellas en las que los bits valen 1, y si vale 0, las posiciones que puede ocupar serán aquellas en las que los bits valen 0.
En el primer caso, basta hacer un AND lógico del bloque del criptograma con la máscara para eliminar las posiciones prohibidas (aquellas en las que los bits del criptograma valen 0).
En el segundo caso, basta con invertir los bits del criptograma, de forma que ahora las posiciones permitidas son las que ocupan los bits con el valor 1 debido a esta inversión, y realizar el AND lógico como se ha explicado para el anterior caso.
Este paso se repite con sucesivos bloques de texto y sus correspondientes criptogramas. En cada paso se irán reduciendo los bits activos de la máscara (salvo en el peor de los casos, en el que el AND lógico se haga con un criptograma con al menos los mismos bits activos que la máscara, caso en el que el número de bits activos no variaría).
Llegará un momento (salvo raras excepciones, o si no hay suficientes bloques de texto) en el que en la máscara quede un único bit activo. La posición de ese bit dentro de la máscara será la posición a la que se mueve el bit en cuestión desde el texto hasta el criptograma.
Realizando este proceso con todos los bits del texto, determinaremos las posiciones que ocupan, y con ello, construiremos la tabla que nos permitirá descifrar el criptograma, pues bastará consultarla para saber a qué posición hay que mover el bit del criptograma en el texto. Luego, sólo hay que invertir la codificación que se realizó con el alfabeto desordenado, ya que el texto obtenido es con el alfabeto desordenado.
Este proceso puede hacerse en paralelo, es decir, trabajando con 160 máscaras, una por bit de texto, de forma que si obtenemos una de ellas con un único bit, la posición que ocupe ese bit en el resto de las máscaras se borrará, ya que cada bit ocupa una posición distinta. Esto puede reducir la cantidad de texto necesaria.
Probando con el Quijote, cifrado con la clave "VALE", se necesitaron 19 bloques de texto en claro para obtener la tabla de descifrado (estos bloques fueron los del comienzo del texto).
Hay que notar que no es necesario que el texto sea consecutivo. Lo que sí hay que tener en cuenta es que hay que tomar bloques completos de texto con sus correspondientes bloques de criptograma.
No se si te acabo de pillar
LlamameX10 Marzo 2012 - 4:20am
¿Puedes poner un ejemplo aunque sea simplificado?
Respecto a obtener el alfabeto desordenado he hecho algunos avances prometedores pero aún falta un largo trecho. A ver si podemos complementar una cosa con la otra.
Mis intentos, no avanzo mucho pero sigo en ello
LlamameX7 Marzo 2012 - 3:23pm
Más que nada para que Agustín no crea que ya me he rendido.
Los análisis de frecuencias por columnas me dieron una sorpresa. La columna 21 tiene un perfil casi perfecto de distribución de frecuencias que apuntaban a una coincidencia de los 5 bits (ahora creo que son 4). Las frecuencias son las siguientes:
Que podrían indicar el alfabeto derivado
E_UPSJR:.LFGNDQOBÑIVYTXKZHMA,;CW
Al cual le apliqué mi método sin ningún resultado. (cosas del estilo
VXXCRHJULQAEÑGPJFLDC...). La columna 20 también promete aunque tiene resultados menos adecuados.
En el tema de los bits de coincidencia (es decir cuantos bits de una misma columna de carácter del texto claro aparecen en una determinada columna de caracter del cifrado, obviamente las posiciones de dichas columnas no tienen por que coincidir). Pensando como puede llegar a ocurrir es bastante lógico pensar que no se agruparan por que los bits vayan coincidiendo en orden en un extremo del bloque (eso parece extremadamente improbable) si no más bien por que el proceso de batido no extrae ningún (o como mucho uno) bit y los mantiene contiguos. Eso implicaría que las columnas de bits no sólo permanecerían unidas si no que además mantendrían el orden.
Siendo así, si tuviéramos los 5 bits en una columna tendríamos un patrón de sustitución simple. En ese caso deberíamos esperar una frecuencia alrededor de un 18% del espacio, cosa que en la columna 21 vemos que no sucede exactamente.
Sin embargo, si tenemos 4 bits, deberiamos tener 2 carácteres con frecuencias altas parecidas, cada una de ellas mediatizadas por la aportación del segundo carácter que comparte 4 bits con el espacio. Si suponemos que ese segundo carácter tiene una frecuencia normal, pongamos de un 3%, deberíamos encontrar 2 carácteres con unos (18+3)/2=10.5%, cosa que se parece más a lo que ocurre en la columna 21.
Del mismo modo debería pasarnos con los carácteres menos probables, la K y la W y si nos fijamos tenemos 2 candidatos que clavan la frecuencia para cada uno, 0.008% y 0.13% (recordemos que el segundo carácter que les aporte bits aumentará su aparición).
En definitiva, creo que esa columna es la Piedra de Roseta de omelette. Ahora estoy buscando métodos para probar asignaciones de bits que me permitan lanzar hipótesis a verificar para candidatos a alfabeto derivado.
Sigo con las frecuencias
LlamameX7 Marzo 2012 - 6:58pm
Tenemos las siguientes parejas de frecuencias relacionadas.
Por arriba
Por abajo
Si miramos las coincidencias de bits (las columnas de bits deben ser las mismas para todos ellos) podríamos establecer las correspondencias
(AB) y (WV), que nos indicaría que los bits 1,2,3 y 4 pertenecen al carácter original.
Asumiendo esto tendríamos para el carácter "_" las siguientes posibilidades (con la hipótesis del mantenimiento del orden)
Y para la "K"
No es mucho, pero es un inicio
Piedra de Rosetta
Agustín7 Marzo 2012 - 5:05pm
odría ser que alguna columna hiciera el papel de piedra de Rosetta. Dada la pobre aleatoriedad del batido, sería posible un pleno de 5 bits, es decir, que alguna columna de texto plano quedara invariable, aunque ni afirmo ni niego que eso haya ocurido en el cifrado problema. De todas formas, esa circunstancia dependerá de la clave, y podría darse en unos cifrados y en otros no.
Lo que sí puedo decir, sin rebajar el reto (qué más dará 32! que 32! - 1), es que el alfabeto derivado que propones
E_UPSJR:.LFGNDQOBÑIVYTXKZHMA,;CWno podría diferir más del que usa el cifrado.Ya imaginaba que no te habías rendido, sobre todo después de tu brillante éxito inicial, y espero que no te rindas.
Un saludo
Ya lo tenía claro
LlamameX7 Marzo 2012 - 7:02pm
Lo puse más que nada por ser exhaustivo en las líneas de investigación.
Lo que si es cierto es que la dificultad de omelette depende mucho de una buena clave y eso no implica necesariamente una clave larga, si no de circunstancias bastante ajenas al usuario.
Lo reconozco
Agustín7 Marzo 2012 - 9:33pm
En efecto, la aleatoriedad del batido depende de circunstancias imprevisibles, relativas a los valores pares e impares de las letras de la clave y los de sus posiciones.
AG K.O.
tokamak4 Marzo 2012 - 1:09pm
Me temo que mis implementaciones de AGs no van a ayudar con la tortilla. Me he tirado toda la mañana del sabado dale que te pego, pero no he detectado ni la más mínima convergencia entre la clave y la solución. Era clarísima con Lapyznos, y muy leve, pero existía, con ACYNOS (me resolvía hasta claves de longitud 5).
Con la tortilla nada de nada, no puede resolver ni el criptograma con la clave VALE. El culpable es el batido de bits, que borra muy bien cualquier regularidad, así que habrá que estudiar otros enfoques. Ya lo siento. Snif!
Me llevas ventaja
Agustín4 Marzo 2012 - 1:22pm
Porque yo aún tengo que entender bien cómo funcionan los AG.
Gracias, Igor21
Agustín2 Marzo 2012 - 9:46pm
Gracias por tu ayuda.
Tenía dudas porque la combinatoria siempre me pareció una obra del diablo (del diablo de los números, supongo), y porque las posiciones de los bits para el batido pueden repetirse. Quiero decir que si, gracias al trabajo de LlamameX, conocemos los primeros 32 movimientos, por ejemplo:
no puedo eliminarlas del conjunto de posiciones disponibles para los 128 movimientos restantes. En la práctica, la pregunta sería ¿cómo saco partido de esos movimientos conocidos para probar la combinatoria de los 128 que faltan?
Mi impresión es que tengo que combinar igualmente los 160 elementos tomados de 80 en 80 (en el caso más complejo), y que, en todo caso, podría eliminar 32 sucesos, es decir que la complejidad sería:
O sea, la complejidad apenas habría disminuido desde el punto de vista combinatorio aunque, evidentemente, se habrán abierto vías de ataque más "humanas", como heurísticas sobre el resto de la clave, etc.
No sé qué te parecerá todo este rollo, igual se ma ha ido la pinza
El estado de la cuestión
Agustín2 Marzo 2012 - 5:57pm
Después del descubrimiento de LlamameX ¿está muerta la omelette? ¿agoniza, tan solo?
En primer lugar, hay que localizar el alfabeto derivado, lo que tiene una dificultad de
C = 32! = 2.6 * 10^35
bueno, algo menos, según periquillo. Y en cada caso hay que aplicar el algoritmo de LlamameX con la esperanza de que la clave sea legible y podamos reconocerla.
Si se llega a ese punto, si la clave tiene 32 caracteres o menos, ya está resuelto el problema, pero si mide más de 32 caracteres no tendríamos más que una porción (32) de los 160 movimientos del batido de bits, o sea que aún quedaría algo de trabajo, pero seguramente nada que los LlamameX, los Tokamak y los Periquillo (por citar sólo a los que están en la brega) no puedan superar.
Por intentar darle al ejercicio un poquito de rigor, me gustaría calcular la complejidad que le queda al algoritmo. Tenemos, el factorial, 32! (o menos), y luego, de los 160 bits que hay que mover, eliminamos los 32 ya detectados, y nos quedan 128. Aquí necesito la ayuda de Igor21, pero voy a tratar de seguir su razonamiento, y supondré que tengo que combinar 128 elementos tomados de 54 en 54 (suponiendo que la mitad sean ceros, que es el caso más complejo). En suma, tendríamos
Y todo eso dependiendo de que el usuario no haya puesto una clave boba.
O sea, que como aportación a la ciencia criptográfica, hay que reconocer que la a la Omelette le faltan huevos, con perdón.
P.S.
Tengo algunas dudas sobre el cálculo de C2, a ver si a alguien se le ocurre cómo mejorarlo
Pequeño gazapo
igor212 Marzo 2012 - 9:04pm
He comprobado los cálculos y coinciden como no podía ser de otra forma. El único comentario sería sobre un gazapo, ya que en el enunciado has puesto 54 en lugar de 64 (a pesar que luego has usado 64 que es lo correcto).
Casi de nada me entero
faxvfnts2 Marzo 2012 - 7:18pm
No, si ya decía yo (v.s. "Tengo una pregunta" #comment-68133) que las preguntas tienen su importancia aunque, en principio, resulten chocantes.
Como en otros retos, no me entero de gran cosa pero lo que se aprende es impagable.
También admiro lo duro que le dáis al problema siendo, a la vez, suaves con las personas... bueno, a la vista está que un zote como servidor pueda participar en estas artes "culinarias".
[chiste] Por cierto, ayer soñé que me comí la tortilla :-P [/chiste] ¡Gracias!
Los retos de Kriptópolis
Agustín5 Marzo 2012 - 3:10am
Normal. Esto de los retos de Kriptópolis es como un club de amigos que se divierten dándole un poco al coco, y se tienen un gran respeto. Y, por otra parte, cualquiera puede participar si está dispuesto a poner coco y respeto.
En general, los retos que se presentan no tienen un gran aparato matemático, pero es cierto que algunos de ellos, aunque puedan ser de lápiz y papel, resultan algo engorrosos, y requieren algunas nociones de programación. Si repasas bien las explicaciones y preguntas lo que necesites, puedes comprenderlo todo.
Y esta es una buena ocasión para agradecer la hospitalidad de Kriptópolis para estos entretenimientos tan gratos.
Admin
Agustín1 Marzo 2012 - 10:29pm
Creo que, independientemente de quién llegue a descifrar el reto, LlamameX le ha dado una fuerte dentellada, y se merece una parte del premio, digamos la mitad, si te parece bien.
No no no
LlamameX2 Marzo 2012 - 1:12pm
No es falsa modestia, es que aún no he hecho nada que merezca ese premio. Ya lo explico en el hilo del subproblema.
Implementación VB
tokamak1 Marzo 2012 - 12:36pm
Hola, aquí os dejo la implementación de este criptosistema en VB. Es muy útil si trabajáis con Excel, porque os deja los cifrados en la hoja, para posteriores análisis.
Como ya me lo han preguntado otras veces, para meterlo en Excel tenéis que hacer esto:
En el Botón Microsoft Office escojer sucesivamente:
- opciones de Excel
- Más frecuentes
- Mostrar ficha Programador
- Grupo Código
- Visual Basic
- Insertar Módulo
- Archivo Cerrar
También funciona en Open Office.
y aquí va el módulo:
la función que devuelve los resultados es omelette, y hay que pasarle el valor C ó D según cifremos o descifremos, el texto en claro o cifrado, y la clave.
Por ejemplo, si en la casilla A15 tenemos "C", en la 13, tenemos el texto a cifrar y en la 14 la clave, en la casilla donde queremos el cifrado, escribiremos:
Cara al finde, os prometo un intento de criptoanálisis con Algoritmos evolutivos de este criptosistema.
VB de la Omelette en LibreOffice ¡OK!
faxvfnts1 Marzo 2012 - 3:45pm
Ingredientes:
- LibreOffice v3.4.2
Nota.- En otras versiones creo que será similar, probando se aprende mucho aunque erremos =8-)
- Abrir un nuevo documento LibreOffice Calc
- Ir al menú Herramientas -> Macros -> Organizar Macros -> LibreOffice Basic que nos abre un cuadro de diálogo mediante el cual, podremos añadir el código que tan amablemente nos ha proporcionado tokamak. Yo lo hice en Mis macros -> Standar > Modulo1 y la edité y guardé varias veces para que el comprobador de código hiciera su trabajo y, si había algún error, corregirlo sobre la marcha... en concreto la función "añadir" la cambié por "add" y un "for ñ" que había por ahí tuve que reconvertirlo en "for n". De momento no detecté mayor problemo aunque para mí ya fue bastante "omelette aux bits" por ahora.
Nota.- Ojo que al guardar el documento en formato de LibreOffice, el código Basic se guarda también. Al guardar en otro formato, la IDE de Basic de LibreOffice Basic no se guarda.
¿Que si seguiré mirando la omelette? Sí, pero hoy no... manaña ¡Uf!
Perfecto gracias
tokamak1 Marzo 2012 - 4:54pm
for ñ je je se me acaban los nombres de variables..
Gracias
Agustín1 Marzo 2012 - 2:57pm
Buen trabajo
Subproblema
Agustín1 Marzo 2012 - 12:51am
LlamameX está convencido de que si se tiene el alfabeto derivado se puede determinar la clave. He estado pensando en ello, y es posible que así sea, no solamente con el alfabeto, claro, sino a partir de los bits del cifrado, que sí son conocidos teniendo el alfabeto. Como me parece una cuestión teórica importante que puede afectar a los trabajos del análisis, he decidido presentaros un subproblema, es decir, un fichero cifrado de longitud suficiente, con la información añadida del alfabeto derivado. A diferencia del Quijote del ejemplo, la clave es bastante más larga, eso sí.
Si se comprobara que es posible determinar la clave y, por tanto, resolver el cifrado, toda la dificultad de Omelette estaría en acertar el alfabeto, es decir que su complejidad se reduciría a 32! ~ 10^35. También se deduciría que la batida de bits no es más que un incordio, pero que no añade dificultad alguna al ataque. Mi opinión, que espero se refute, es que la complejidad se reduciría a
C(160, 80) ~ 10^47
(según los cálculos de Igor21)
Sería un poco menos quizás, por las posicions que nunca se tocan, según Lucho.krp. Pero aún quedaría faena.
Veamos:
Aquí tenéis el cifrado completo: Fichero cifrado
¿Te había pedido un cifrado?
LlamameX1 Marzo 2012 - 2:20pm
UN_CIFRADO_ME_HA_PEDIDO_LLAMAMEX
Hasta ahí llego (los últimos los adivino), pero como pasamos de 32 carácteres ya no puedo seguir con este sistema.
Genial!
tokamak1 Marzo 2012 - 4:45pm
Llamamex es un mago. He aquí por qué me gustan más lo cifrados muy muy sencillos, sin florituras que puedan ocultar una posible debilidad. Centrándonos solo en un proceso, que sea lo más elegante posible, es más fácil estar atento a las debilidades, en vez de construir algo con muchas interacciones, con la esperanza de que se tapen las vergüenzas unos pasos a otros.
Coincido
Agustín1 Marzo 2012 - 6:52pm
Para medir la fuerza de un sistema es preferible que no esté embarullado con operaciones abstrusas.
Chapeau!
Agustín1 Marzo 2012 - 2:59pm
(Touché! Foutu! Emmerdé! Renvoyé! Encombré! Inutile! Fainéant! Dégueulasse! Bon-à-rien! Clok! Clok! Clok! Clok! Clok! Clok! Clok! Clok! Clok! Clok!)
Es decir, que lo has demostrado. Dado el cifrado y el alfabeto derivado, la cosa está hecha. Complejidad=32! Q.E.D.
En efecto, la clave era:
UN_CIFRADO_ME_HA_PEDIDO_LLAMAMEX_Y_EN_MI_VIDA_ME_HE_VISTO_EN_TAL_APRIETO
Gente: La omelette ya está en su punto para ser comida.
Ahora faltaría la explicación del método, porfa.
Enhorabuena.
P.S.
¿Y no puedes averiguar el resto de la clave? Porque de ser así quizá no puedas descifrar el texto. Explícate, admirado amigo.
Q.E.D. todavia no
periquillo2 Marzo 2012 - 2:13pm
La complejidad sigue siendo 32! (o menos), porque creo que lo complicado es precisamente obtener el alfabeto derivado y por fuerza bruta y a lo "facil" se tienen que probar los 32! alfabetos posibles.
De todas formas, como dije hace dias, no es necesario probar 32! alfabetos sino menos. En realidad se tienen que probar "familias de alfabetos" que son equivalentes y que tienen la letra con todo ceros y la letra con todo unos iguales y luego las letras con un bit a uno, con dos, etc, etc se pueden intercambiar.
En el otro mensaje publique la formula y creo recordar que rondaba un coste de 10^18.