Te agradezco de verdad este resumen.

Después de todas las movidas del sitio estoy con stress postraumático ;)

Bueno, aquí explicaré el ataque a Omelette Aux Bits con texto conocido. Perdonad que haya tardado tanto, pero las circunstancias no me dejaron escribir ni desarrollar el ataque antes.

En el anterior ataque que publiqué, se necesitaba el alfabeto desordenado. En este ataque sólo se necesita texto y criptograma suficientemente largos. Este ataque no permitirá resolver el reto, pero creo que va a resultar interesante.

Este ataque se ha alargado un poco, así que lo escribiré en varias partes.

Como curiosidad interesante, en el anterior ataque obtuvimos una tabla de cifrado y su correspondiente tabla de descifrado que nos permitían, junto con el alfabeto desordenado, cifrar y descifrar los mensajes encriptados con la misma clave. Si consideramos el par alfabeto desordenado-tabla cifrado/descifrado como clave, tenemos que con este ataque que presento aquí obtenemos 240 claves (al menos para el ejemplo dado), es decir, 240 pares alfabeto desordenado-tabla cifrado/descifrado que permiten cifrar y descifrar mensajes encriptados con una misma clave. Si no me equivoco, este número se debe a que obtenemos claves para todas las permutaciones de los 5 bits de cada carácter (5!=120) y sus valores binarios inversos (cada valor tiene su inverso), por lo que tenemos en total 2*120=240 claves.

En este segundo paso agruparemos las letras del alfabeto en grupos que comparten un determinado bit (no sabemos cuál) con un determinado valor (tampoco sabemos cuál) cuando obtenemos su codificación con el alfabeto desordenado (que de momento desconocemos).

En el paso anterior obtuvimos grupos de letras diferentes para cada columna del criptograma. Las que nos interesaron entonces fueron las que tenían 16 o menos letras. En este paso nos interesarán aquellas que tengan exactamente 16 letras.

Como vimos en el anterior paso, que una columna tenga entre 9 y 16 letras diferentes es indicio de que esas letras comparten un mismo bit con un mismo valor. Supongamos que conocemos qué letras comparten un cierto bit. Sabemos que los grupos de estas letras serán de 16 letras diferentes. Por otro lado, si queremos ver qué letras comparten el mismo bit, pero con valor opuesto, basta obtener el conjunto complementario, es decir, las otras 16 letras del alfabeto. Por ser conjuntos complementarios, su intersección será nula.

El interés de agrupar las letras por un determinado bit en común con un mismo valor es el siguiente. Supongamos que conocemos la codificación de todas las letras. Podemos obtener fácilmente los conjuntos en los que las letras comparten un cierto bit con un cierto valor. Supongamos que tenemos esos conjuntos. Serán 10 en total, pues tenemos 5 bits, cada uno de los cuales puede tomar 2 valores. Ordenemos los conjuntos por el orden de bit menos significativo que representan, y los emparejamos con su complementario. Es decir, el primer conjunto representa las letras que tienen el bit menos significativo a 0, emparejado con su complementario (es decir, el que tiene el bit menos significativo a 1), el segundo está formado por las letras que tienen el segundo bit menos significativo a 0, y su complementario, y así sucesivamente.

Teniendo así los conjuntos, tomemos una letra cualquiera. Determinemos a qué conjuntos pertenece. Los conjuntos a los que pertenecerá serán aquellos que tengan su correspondiente bit al mismo valor que el bit de la letra. Si a cada conjunto le damos la etiqueta "0" o "1" en función del valor que tome el bit que representan, y escribimos estas etiquetas en orden según el conjunto tomado por la pertenencia de la letra, obtendremos la representación binaria del código de la letra. Es decir, que si disponemos de los conjuntos de letras por bits que comparten, podremos obtener una representación binaria de cada letra.

Pues bien, si obtenemos en el paso anterior los conjuntos de 16 letras (verificando que son letras que comparten un mismo bit con un mismo valor), estamos obteniendo los conjuntos que buscamos. En el ejemplo anterior, para la columna 0 del texto claro, teníamos:

Columna 0: ABDEGHIKLÑPQSXY,

Es decir, que estas letras comparten un mismo bit (no sabemos cuál) con un mismo valor (tampoco sabemos cuál). Su conjunto complementario será "CFJMNORTUVWZ_.;:", que son las letras que comparten el mismo bit que las otras, pero con valor opuesto.

Si observamos la columna 1 del texto claro, tenemos:

Columna 0: EFIJKLNÑOUWXYZ.,
Columna 1: CDEGHIMNÑPRTUWYZ
Columna 9: ABDFGLMÑORUVYZ,:
Columna 10: CEHJNPQSTWX_.;
Columna 11: ABFJKLOQSVX_.,;:

Nos interesan las columnas 0, 1, 9 y 11. La columna 10 no tiene 16 letras, por lo que no podemos determinar todas las letras que comparten el mismo bit. Si observamos, tenemos ya 4 conjuntos de letras diferentes, que con sus respectivos conjuntos complementarios, suman ya 8 conjuntos, es decir, que nos falta un conjunto más, con su complementario, para tener todos los conjuntos de letras agrupados por bits individuales compartidos:

ABDEGHIKLÑPQSXY, <-> CFJMNORTUVWZ_.;:
EFIJKLNÑOUWXYZ., <-> ABCDGHMPQRSTV_;:
CDEGHIMNÑPRTUWYZ <-> ABFJKLOQSVX_.,;:
ABDFGLMÑORUVYZ,: <-> CEHIJKNPQSTWX_.;

Siguiendo así, acabamos obteniendo los siguientes conjuntos de letras:

ABDEGHIKLÑPQSXY, <-> CFJMNORTUVWZ_.;:
ABCDGHMPQRSTV_;: <-> EFIJKLNÑOUWXYZ.,
CEHIJKNPQSTWX_.; <-> ABDFGLMÑORUVYZ,:
ACDFHIKNÑQRZ.,;: <-> BEGJLMOPSTUVWXY_
CDEGHIMNÑPRTUWYZ <-> ABFJKLOQSVX_.,;:

Con este método puede que no haga falta recorrer todas las columnas y todas las letras para obtener los conjuntos de letras. Basta obtener 10 grupos de letras diferentes de 16 letras cada uno.

Como se dijo en el anterior paso, si con una letra del texto claro no obtenemos resultados concluyentes, podemos probar con otra, hasta obtenerlos. Si aún así, para un determinado conjunto no obtenemos sus 16 letras, siempre podemos buscar entre todos los conjuntos obtenidos aquellos que sepamos con seguridad que representan el mismo, y hallar su unión. Dados dos conjuntos de 9 o más letras cada uno, ambos pertenecerán al mismo conjunto si su intersección tiene 9 o más letras. Téngase en cuenta que estamos hablando de los conjuntos con estas características que estamos buscando, y esto no puede generalizarse a la teoría de conjuntos :). En caso de encontrar dos de estos conjuntos con una intersección de 9 o más letras, los uniremos para obtener nuevas letras (si es que tienen letras que no comparten). Si dos conjuntos con 9 letras o más tienen una intersección nula, entonces uno pertenece al complementario del conjunto al que pertenece el otro. Por otro lado, si tenemos un conjunto completo de 16 letras, podemos obtener el complementario directamente.

Ahora ya tenemos los diferentes conjuntos agrupados por un mismo bit con un mismo valor, pero no sabemos qué bit comparten ni qué valor tiene ese bit. Esto lo averiguaremos en el siguiente paso.

En el paso anterior se explicó cómo obtener el alfabeto desordenado y la tabla de cifrado/descifrado utilizando el ataque con texto claro y alfabeto desordenado. Aquí se explicará otra manera, parecida.

Si el alfabeto desordenado que hemos obtenido es correcto, podemos determinar la codificación de las letras. En el primer paso obtuvimos qué columnas del criptograma contienen los bits de una determinada columna del texto claro. Ahora que tenemos la codificación, podemos determinar exactamente qué bit del criptograma contiene a qué bit del texto claro de la columna en la que estamos trabajando.

Para ello, supongamos que estamos trabajando en la columna 0 del texto claro, y que queremos determinar qué bit del criptograma contiene el bit 0 de la columna 0 del texto claro. En el paso 0 obtuvimos las columnas del criptograma que contienen los bits de esta columna 0 del texto claro. Pues bien, trabajaremos sobre estas columnas. En nuestro caso, las columnas eran la 0, 3 y 10.

El procedimiento a seguir es muy parecido al del ataque con texto claro y alfabeto desordenado. Construimos una máscara de 5 bits para cada columna del criptograma en la que vamos a trabajar, y ponemos todos sus bits a 1. Leemos el carácter de la columna 0 del primer bloque del texto claro. En este caso, tenemos:

EL_INGENIOSO_HIDALGO_DON_QUIJOTE ---> Cogemos la "E" (columna 0)

Obtenemos el código de la letra "E" con el alfabeto desordenado que estamos probando. Ahora tomamos su bit 0. Tomamos los caracteres del criptograma en las columnas 0, 3 y 10. En este caso, tenemos:

B,NZTSW,WAS.WDQXFVGAKQÑXHEVTXEGN ---> Cogemos la "B" (columna 0), la "Z" (columna 3) y la "S" (columna 10)

Hallamos la codificación de cada una de estas letras, según el alfabeto desordenado que estamos probando. Si el bit del texto claro vale 0, hallamos el inverso de la codificación de estas letras. Si vale 1, dejamos la codificación de estas letras como está. Ahora hacemos AND de cada una de estas letras con su respectiva máscara, y guardamos el resultado en la máscara. Esto, como en el ataque con texto claro y alfabeto desordenado, dejará en cada máscara los candidatos a ser los bits en los que se mueve el bit del texto claro que estamos estudiando.

Pasamos al siguiente bloque del texto claro, en este caso "_DE_LA_MANCHA_TASA_YO,_JUAN_GALL", tomamos la letra de la columna 0, obtenemos su codificación, tomamos su bit 0, tomamos el siguiente bloque del criptograma, cogemos las letras de las columnas 0, 3 y 10, obtenemos su codificación, la invertimos si el bit del texto claro vale 0, y hacemos AND con sus respectivas máscaras, y así hasta terminar con todos los bloques del texto claro.

Si en algún momento las diferentes máscaras toman simultáneamente el valor 0, entonces el alfabeto desordenado está mal, porque debería haber un bit de la columna 0 en alguna de las columnas de trabajo del criptograma, y hemos descubierto que no es así. Si al finalizar el proceso más de una máscara tiene un valor no nulo, también está mal el alfabeto desordenado (o no tenemos suficiente texto), porque un bit del texto sólo puede aparecer en un bit del criptograma.

Si el alfabeto desordenado está bien, y tenemos suficiente texto, al final sólo una máscara debería tener activo un único bit (si tuviera más de un bit activo, o bien el alfabeto desordenado está mal, o bien no tenemos suficiente texto). En este caso, hemos obtenido en qué bit del criptograma está el bit del texto claro con el que hemos trabajado (la posición será 5*columna de la máscara+posición del bit que está activo, la posición cuenta de más significativo a menos significativo). Este valor lo vamos almacenando en una tabla, que será la tabla que nos permitirá descifrar (hacemos tabla[0]=posición del bit).

Este proceso se repite para cada bit del carácter con el que estamos trabajando, y con cada carácter del texto claro. Si en algún paso se produce un error, el alfabeto desordenado que hemos elegido está mal, y tenemos que obtener otro y repetir el proceso.

Para obtener el siguiente alfabeto, cambiamos las etiquetas de cada conjunto, y obtenemos una nueva permutación, en orden, para explorar todos los casos.

Una vez terminado el proceso, tenemos el alfabeto desordenado y la tabla de descifrado (o de cifrado, dependiendo de cómo se hayan guardado los datos y se interpreten). La tabla que permite realizar la operación inversa se halla invirtiendo la tabla obtenida (haciendo tabla2[tabla[i]]=i). Para asegurarnos de que hemos obtenido el alfabeto desordenado y la tabla de cifrado/descifrado correctos, bastará cifrar el texto con este par y comprobar que el criptograma obtenido coincide con el que teníamos, o bien descifrar el criptograma y comparar el texto obtenido con el que teníamos.

Pues bien, realizando este ataque con el ejemplo dado por Agustín, utilizando todos los posibles alfabetos desordenados, resulta que se obtienen 240 pares de alfabetos desordenados-tablas cifrado/descifrado válidos que permiten cifrar y descifrar el problema. Lo curioso de estos pares es que la mitad corresponden a un mismo etiquetado de los conjuntos, y todas las permutaciones posibles, y la otra mitad corresponde al etiquetado inverso, con todas las permutaciones posibles. No sé si esto es aplicable a todos los casos, pero si es así, a la hora de buscar el alfabeto desordenado no hace falta permutar los conjuntos, sólo darle diferentes etiquetas a los conjuntos. Esto acelera mucho el proceso, ya que en el peor de los casos, habrá que realizar 16 pruebas (hay 32 posibles maneras de etiquetar los conjuntos, y si un etiquetado es solución, también lo será el etiquetado opuesto, si todo esto se cumple).

Quizá esto sea una debilidad, pero ahora no se me ocurre cómo utilizarla.

El método adaptado del de sqrmatrix va proporcionando resultados interesantes. Estoy analizando como se comoportan las demás columnas cuando en una de ellas aparece el carácter más repetido. La intención es encontrar más columnas con N bits de un byte (de 5) original, entenciendo que si cambia mucho el comportamiento de otra columna al filtrar sólo por ese eso indicará una correlación entre ellas. Por ejemplo fijando la columna 20 a "B" (el más frecuente) nos da esta afectación por columnas. Los números es el porcentaje de cambio del porcentaje (ufff) de aparición de esa letra con respecto a no filtrar, es decir, que si sin filtrar la "A" representa un 10% de las apariciones y filtrando un 15%, eso es un 50% de alteración. El resultado es en valor absoluto, puesto que nos interesa tanto los incrementos como los decrementos. No hagais mucho caso a la propia columna 20, puesto que obviamente desaparecen todos los valores salvo la "B".

Vamos bien. Acabo de obtener confirmación. 2 Columnas me dan la misma distribución de bits, es decir, que el grupo es correcto y toda la teoría es válida. Por el momento ya tengo 6 grupos. Sólo me faltan 4 para tener una ataque contra el alfabeto derivado.

Hasta ahora tengo

Col 20 ->  8 ABCDFHLMÑOTWY_;: <-> EGIJKNPQRSUVXZ.,
Col 21 -> 10 ADKNÑPQRTUWY.,;: <-> BCEFGHIJLMOSVXZ_
Col 15 -> 25 ADFGJKMNÑOPRXZ_: <-> BCEHILQSTUVWY.,;
Col 12 ->  6 ADKNÑPQRTUWY.,;: <-> BCEFGHIJLMOSVXZ_

que nervios, que nervios XDD

El alfabeto derivado es

ZIXVK,RUGEJSN.PQ_BOCDYÑTFHML:WA;

Y la clave empieza por "NO_POR_MUCHO_MADRUGAR".

Aún no descrifro todo pero casi

Resumen de meses de ataques y divagaciones.

Como cayó Omelette

De entrada buena parte del mérito hay que atribuírselo a Sqrmatrix, quien con su ataque con texto claro me dio la idea que finalmente tumbó al monstruo.

Como ya se vio desde el inicio Omelette tiene una gran debilidad y es que todos los bloques de 32 letras se baten igual: cada bit de un grupo de 160 va a parar a la misma posición destino. Sin embargo, no es nada fácil explotarla puesto que la codificación en bits no deja rastro en el cifrado final y no podemos saber, a priori, las asignaciones de mapas de bits a las letras. Por supuesto tampoco sabemos nada de las posiciones destino antes comentadas.

Antes de empezar el análisis comentar que hablaré de columnas de carácter y columnas de bit. Se refieren a los carácteres/bits que comparten la misma posición en cada grupo de 32/160.

Así puestas las cosas y tras algunos intentos infructuosos (debidos a interpretaciones erróneas del algoritmo) empecé a analizar las frecuencias por columnas de carácter. Rápidamente destacó una de ellas, la 21, que presentaba los siguientes porcentajes de aparición:

A	7,20%	P	2,55%
B	9,26%	Q	0,36%
C	3,88%	R	5,03%
D	3,42%	S	1,71%
E	5,57%	T	1,41%
F	1,16%	U	3,87%
G	5,51%	V	0,17%
H	0,14%	W	0,01%
I	2,41%	X	0,73%
J	4,74%	Y	1,52%
K	1,17%	Z	3,58%
L	1,57%	_	9,00%
M	5,47%	.	1,96%
N	3,95%	,	0,52%
Ñ	1,75%	;	3,67%
O	6,73%	:	0,01%

Lo realmente relevante no son solo las frecuencias altas, sino los casi ceros. Tener un 0 para un valor en una de las columnas es realmente difícil, ya que quiere decir que hay poquísimas combinaciones de bits que nos lo generen. Si los 5 bits vienen de carácteres distintos eso es prácticamente imposible, puesto que para cada uno de ellos hay 16 carácteres que pueden generarlo. Por ejemplo, imaginemos que para ":" tenemos "01010", donde cada bit provendría de una columna original distinta C1, C2, C3, C4 y C5. En C1 hay 16 caracteres con el bit que se vino a la C21 a 0, en C2 16 a 1, etc. Es prácticamente imposible mantener ese nivel casi a 0 sabiendo que trabajamos con unos 152.000 carácteres, unas 4750 filas.

Así pues hemos de concluir que en esa columna de carácter los bits que tenemos no provienen todos de carácteres ditintos. Tendremos 2 o más bits que vienen de la misma columna original. Si nos fijamos entonces en el resto de la distribución vemos otra cosa llamativa y es que es muy fácil agruparlos por pares de frecuencias similares. Si pensamos que la distribución de los bits individuales es bastante uniforme (esperamos un 50% de 1s y otro de 0s por columna de bit), vemos que la diferencia en un único bit nos provocaría este efecto, puesto que si los carácteres de la 21 están compuestos por [b0,b1,b2,b3,b4], la "B" y el "_" podrían tener coincidentes b0,b1,b2 y b3 y tener b4 formado por un 50% de 0s y otro de 1s.

A partir de aquí empecé a aventurar ataques basados en obtener las sumas de frecuencias por pares (lo que llamé siameses) respecto a una distribución estandard del castellano. la intención era obtener un alfabeto derivado que cuadrara tanto en las frecuencias como en el posible reparto de bits. Esos ataques ofrecían tal cantidad de falsos positivos que los hacían inviables.

Ahí estaba atascado hasta la aportación de Sqrmatrix quien genialmente analizó como sería un ataque para obtener el alfabeto derivado si dispusiéramos del texto claro y del cifrado (de lectura imprescindible).

Aunque el método no era directamente aplicable, puesto que no disponía del texto en claro si me encendió la bombilla. En vez de atacar los más que posibles 4 bits de la columna 21 había que ir a buscar nuestro bit prófugo y ver como alteraba otra columna.

Sabía que muy probablemente "B" y "_" del cifrado escondían 4 bits del carácter más probable del texto original, el "_", así que si me limitaba a ver que le ocurría a las demás columnas cuando en la 21 sólo aparecían "B"s y "_"s tenía que notar algo, ya que de los dos carácteres que nos proporcionaban esos 4 bits de la 21 uno era mucho más probable que el otro. con lo cual el número de 1s respecto a 0s en el bit prófugo sería muy distinto. Eso tenía que provocar una polarización de los carácteres en la columna destino. Los 16 que tuvieran el bit prófugo con el valor más probable habían de aumentar su aparición respecto a los 16 que lo tuvieran con el valor más improbable (nótese que no sabemos si ese valor probable es 0 o 1, pero eso nos da igual, sólo nos interesa distinguir los grupo de 16 que lo tienen con el mismo valor).

Ahí obtuve el primer resultado relevante. La polarización se producía muy notablemente en la columna 10 separándose muy claramente 16 valores altos respecto de 16 bajos.

A       29	P       60
B       530	Q       24
C       390	R       59
D       68	S       222
E       368	T       38
F       650	U       39
G       606	V       375
H       399	W       32
I       474	X       544
J       438	Y       39
K       82	Z       707
L       296	_       832
M       489	.       33
N       64	,       35
Ñ       49	;       20
O       675	:       46

Esto me permitió crear el primer grupo

ADKNÑPQRTUWY.,;: <-> BCEFGHIJLMOSVXZ_

La importancia de estos grupos es que, como se verá más adelante, nos permitirán trabajar con un número muy reducido de alfabetos derivados (2^5 * 5! = 3840) respecto del total de posibles (32!= 2,63x10^35), pasando de ser un problema casi imposible a casi trivial.

Los demás grupos costaron ya un poco más de obtener, ya que la circunstancia de la columna 21 no parece repetirse en el resto del texto. Así seguíamos teniendo que trabajar con bits prófugos de columnas que retuvieran algunos bits originales. El siguiente caso más favorable sería tener 3 de ellos y que se hubieran dispersado los otros 2. Habiendo 2 prófugos lo más probable es que hubieran ido a parar a columnas distintas. Si por mala suerte huieran ido a la misma seguramente no podríamos explotarlo ya que no podríamos polarizarla lo suficiente al compensarse entre ellos.

Si esos dos prófugos están en columnas distintas también podemos buscar la polarización. No conseguiermos resultados tan evidentes como en la 10 pero si habrá afectaciones detectables.

Empezamos filtrando ahora por un único valor en la columna analizado. Dado que queremos seguir trabajando con el "_" original apostamos por el que sea el más frecuente en la misma. Puesto que pensamos que puede haber 3 bits ahora fijados tendremos 4 carácteres (L1,L2,L3 y L4) que los compartirán y que diferiran en los bits (b1,b2) prófugos. Si f(Li) es la frecuencia de Li sabemos que uno de ellos será más probable que el resto. Supongamos que es L1. El peor escenario para conseguir la polarización sería que f(L1)+f(L2)=f(L3)+f(L4) puesto que en la columna donde L1 y L2 tengan b1 con el mismo valor compensarán el de L3 y L4, pero eso forzsamente implicará que donde lo tengan distinto (b2) se diferencien mucho, puesto que f(L1) es máxima y por tanto f(L1)+f(L3)>f(L2)+f(L4).

Con estas premisas construí una hoja de cálculo donde ver visualmente estas afectaciones. En dicha hoja comparaba las alteraciones que implicaban en todas las columnas el hecho de filtrar una de ellas por un valor. Sabemos que si se dan las anteriores condiciones la columna afectada se polarizará como hacía la 10. 16 valores incrementarán su presencia relativa y otros 16 la disminuirán. Así fui probando candidatos tomando como base columnas donde hubiera variaciones grandes de valor entre el máximo y el mínimo (inidcando que retenían grupos de bits originales). Encontré con esté método dos grupos disntintos más

Col 20 ->  8 ABCDFHLMÑOTWY_;: <-> EGIJKNPQRSUVXZ.,
Col 15 -> 25 ADFGJKMNÑOPRXZ_: <-> BCEHILQSTUVWY.,;

Y me dio un vuelco el corazón al encontrar el grupo obtenido en la 21 repetido en otra columna. Esto confirmaba todas las teorias y validaba el grupo encontrado.

Col 12 ->  6 ADKNÑPQRTUWY.,;: <-> BCEFGHIJLMOSVXZ_

Ya lanzado encontré otras confirmaciones pero se me iban acabando las columnas óptimas y aún me faltaban 2 grupos. Las frecuencias cada vez estaban menos polarizadas con lo que me fui quedando con los candidatos más sólidos pero sin darlos por válidos hasta obtenerlos de nuevo en otra columna. Haciéndolo así acabé obteniendo los 5 grupos finales.

Col 20 ->  8 ABCDFHLMÑOTWY_;: <-> EGIJKNPQRSUVXZ.,
Col 21 -> 10 ADKNÑPQRTUWY.,;: <-> BCEFGHIJLMOSVXZ_
Col 15 -> 25 ADFGJKMNÑOPRXZ_: <-> BCEHILQSTUVWY.,;
Col 17 -> 11 BDEFGHIKNWYZ_.,: <-> ACJLMÑOPQRSTUVX;
Col 17 -> 10 AEFGHJLMNPQSW.;: <-> BCDIKÑORTUVXYZ,_

Antes de pasar al ataque del alfabeto derivado aún quise hacer una última comprobación. ¿Serían estos grupos capaces de generar un alfabeto coherente?. para ello asignando 0 o 1 según el carácter estuviera a la derecha o a la izquierda deberían proporcionar una única combinación para cada carácter. Comprobándolo resulto que si (afortunadamente).

A - 00010 (02) P - 10010 (18)
B - 01101 (13) Q - 10110 (22)
C - 01111 (15) R - 10011 (19)
D - 00001 (01) S - 11110 (30)
E - 11100 (28) T - 00111 (07)
F - 01000 (08) U - 10111 (23)
G - 11000 (24) V - 11111 (31)
H - 01100 (12) W - 00100 (04)
I - 11101 (29) X - 11011 (27)
J - 11010 (26) Y - 00101 (05)
K - 10001 (17) Z - 11001 (25)
L - 01110 (14) _ - 01001 (09)
M - 01010 (10) . - 10100 (20)
N - 10000 (16) , - 10101 (21)
Ñ - 00011 (03) ; - 00110 (06)
O - 01011 (11) : - 00000 (00)

Las combinaciones eran únicas y por tanto eran una base para generar el alfabeto. El siguiente paso era obtenerlos todos y determinar cual de ellos provenía de la clave. Para generar un alfabeto se asigna a cada pareja de grupos un orden dentro del carácter y se determina si estar a la derecha o a la izquierda equivale a 0 o 1. el número obtenido de convertir esos bits a decimal para cada letra serán la posición del carácter en el candidato a alfabeto derivado. En el caso de la comprobación el alfabeto sería:

:DAÑWY;TF_MOHBLCNKPR.,QUGZJXEISV

Aquí, conociendo al enemigo, sospeché que habría usado texto en claro como clave, con lo que simplifiqué el ataque para buscarlo específicamente. Yo ya tenía un método recursivo para analizar alfabetos derivados y obtener claves de longitud inferior a 32. Esté método venía a ser

funcion calcularClave(I,alfareducido,Pos){
  L=longitud(alfareducido)
  nuevaPos=posicionLetra(clave[I],alfareducido)
  K=(nuevaPos-Pos) mod L
  mientras(K<32)
    si (sumaMod32(clave[0..I])=alfacript[0] y
        alfabase[K]=clave[0]) mostrar candidato 
    si no {
      clave[I]=alfabase[K]
      calcularClave(I+1,alfareducido-alfacript[I],nuevaPos)
    }
    K=K+L
 }
}
calcularClave(0,alfacript,clave[0])

El problema es que ese análisis, aunque habíamos reducido enormemente el número de alfabetos derivados, seguía siendo muy costoso al multiplicarlo por casi 4000 casos. Así pues, me encomendé a los dioses de la aritmética modular y obvié la comprobación de las subramas buscando acertar a la primera (cosa probable en los primeros pasos) en la búsqueda del texto claro de Agustín. Así visualmente encontré en la posición 2024

ZIXVK,RUGEJSN.PQ_BOCDYÑTFHML:WA;>>NO_PORCMUCHOIMADDHGAHHAEABECBBA

Y desde ahí Omelette, ya herido de muerte, empezó a desangrarse. Aunque aún le quedaban fuerzas para un último coletazo. Aunque quedaba claro que la clave estaba inspirada en el refranero no acababa de descifrarla. tenía un método semimanual buscando palabras probables para el caso en que la clave fuera mayor de 32 letras y no conseguía resultados... hasta que cambié el método y me puse a buscar "_". Una de las soluciones, la del refrán puro y duro, me daba una cantidad enorme de ellos pero el texto no tenía sentido hasta que (autocolleja por lento) vi que estaba escrito de derecha a izquierda.

Tras unas carcajadas solitarias que me convirtieron en foco de atención de los presentes, buscar la fuente del texto original y comunicar la caída del monstruo a la comunidad.

Los resultados.

Clave: 
NO_POR_MUCHO_MADRUGAR_AMANECE_MAS_TEMPRANO
 
Clave expandida: 
NO_POR_MUCHO_MADRUGAR_AMANECE_MA
S_TEMPRANOÑP.QPS.NVDIP.NBESVHBS.
BNBÑFDF.NBT.UFNQSBÑPOQ,RQT,ÑWEJQ
,ÑCFTWICT,CÑCOGEG,ÑCU,VGÑRTCOQPR
;SRU;OXFKR;ODGUXJDU;DODPHFH;ODV;
 
Alfabeto derivado: 
ZIXVK,RUGEJSN.PQ_BOCDYÑTFHML:WA;
 
Primeros bloques en claro:
.ZUL_ARODAUGICAPA_,ELBICNEVNI_,A
RERTSOP_AL_ED_Y_SOURTSNOM_SOREDA
DREV_SOL_ED_EUQSOB_LE_AICAH_,ETS
IRT_ERBMOH_ERBOP_,AIROLG_ED_Y_RO
MA_ED_OSOISNA_,OÑEUQEP_OURTSNOM_
ERBOP_,OZRAMOB_ED_OURTSNOM_ERBOP
_,ESARTSARRA_EM_Y_ARAGEC_SOL_ELB
ACALPMI_EHCON_AL_EUQ_ED_SETNA_,N
OREIV_SOJO_SIM_EUQ_,ODAPSIRC_EUQ
IÑEM_IM_NE_,OMITLU_OL_,ORUP_OREC
 
Texto original:
Bomarzo de Manuel Mujica Láinez
http://es.wikipedia.org/wiki/Bomarzo_(novela)

Y una vez más mi aprecio y reconocimiento a Sqrmatrix sin cuya aportación esto no habría sido posible.