Guía de Retos de
Criptografía

Abrimos Reto 1_Cervantes.bmp con un editor hexadecimal y comparamos el tamaño indicado en la cabecera con el tamaño real del archivo:

Los tamaños no coinciden: según la cabecera debería tener 8.200.530 bytes, pero realmente tiene 8.303.389 bytes — es decir, tiene 102.859 bytes de más. Esto indica que el método empleado es EOF (End Of File): se ha añadido información al final del archivo sin modificar la cabecera.

Vamos al final del fichero con el editor hexadecimal y encontramos los caracteres IEND, que marcan el final de una imagen PNG.

Vamos a la posición 7D2151 (decimal 8.200.529), donde debería terminar el archivo BMP según su cabecera. Justo a continuación (posición 7D2152) reconocemos la cabecera de una imagen PNG: los bytes 89 50 4E 47, donde 50 4E 47 corresponden en ASCII a los caracteres PNG.

Buscamos más cabeceras PNG en el resto del archivo. Solo hay una, confirmando que únicamente se oculta una imagen PNG al final del BMP.

Extraemos todo el contenido del archivo BMP desde la posición 7D2152 hasta el final y generamos un nuevo archivo: mensaje.png. Su tamaño es 102.859 bytes, que sumados a los 8.200.530 de la cabecera dan exactamente 8.303.389 (el tamaño real). Esto confirma que solo hay una imagen PNG oculta.

Abrimos mensaje.png con cualquier visor de imágenes y obtenemos la imagen que estaba oculta:

El título y el enunciado apuntan directamente al cifrado César: cada carácter del texto en claro se sustituye por el que se encuentra un número fijo de posiciones por delante en el alfabeto (p. ej., «A» → «D», «B» → «E» con desplazamiento 3).

El desplazamiento más habitual es 3, pero puede ser cualquiera de los n−1 posibles. Con el alfabeto español (n = 27) hay 26 desplazamientos posibles — un espacio de claves ridículamente pequeño.

Probamos todos los desplazamientos posibles. En el peor caso son 26 intentos. Colocamos el criptograma en la primera fila y, debajo de cada carácter, el anterior del alfabeto. Si no obtenemos texto legible, añadimos otra fila y repetimos:

En pocos intentos el texto en claro queda perfectamente visible.

Descargamos los dos archivos. El primero (posición de ajedrez) se abre con el editor hexadecimal y no revela nada sospechoso.

El segundo archivo (código QR) no es reconocido por el lector de QR. Analizándolo, se observa que los patrones de sincronización tienen los colores invertidos respecto a los patrones de posición, alineamiento y zona tranquila:

Usando Paint, seleccionamos todo el QR excepto la zona tranquila e invertimos los colores:

A continuación invertimos individualmente los colores de cada patrón de posición y del patrón de alineamiento, obteniendo el QR corregido:

Ahora el lector sí reconoce el código. Es un QR de geolocalización que muestra esta ubicación:

Abrimos el archivo del QR con el editor hexadecimal:

Entre los metadatos aparece la fecha y hora 19/12/2017 19:00. Esto también es visible en las propiedades del archivo (campo «Comentarios»):

Como el correo fue enviado el 16/12/2017, la fecha 19/12/2017 es claramente la de la cita futura.

Calculamos la frecuencia de aparición de cada símbolo en el criptograma y la comparamos con las frecuencias de las letras en español:

Hipótesis inicial: los dos símbolos más frecuentes del criptograma corresponden a «E» y «A». El segundo símbolo (8,33% de frecuencia) es muy probable que sea «S» (la consonante más frecuente en español):

Primera aproximación al texto en claro con estas hipótesis:

El tercer símbolo podría ser «T» (el texto empezaría por «ESTE»), y los dos símbolos consecutivos repetidos podrían ser «L» (se leería «ELLOS»). Las frecuencias de aparición en el criptograma son coherentes con las de «T» (4,63%) y «L» (4,97%) en español.

Segunda aproximación al texto en claro:

Analizamos los 12 bigramas que se repiten 3 o más veces: «OS», «LO», «TE», «ES», «EL»... y varios terminados en «E»:

El símbolo que precede a «E» con más frecuencia (4 veces, enmarcado en rojo) es candidato a ser «D» — «DE» es posiblemente el bigrama más frecuente en español terminado en «E». También se identifican «U» y «N» gracias al bigrama «UN»:

Recapitulamos todas las correspondencias halladas hasta el momento:

Tercera aproximación al texto en claro:

A simple vista ya se leen palabras como «ATAQUE», «TEXTO», «ANALISIS»... Con los candidatos para «I», «R» y «C» determinados por eliminación y frecuencia, descifrado completo:

«Jeova Sanctus Unus» (algo así como «Jehová único santo») era el seudónimo alquimista de Isaac Newton. Reordenando las letras del anagrama obtenemos su nombre latinizado:

Resultado: «ISAACUS NEUUTONUS». Esta será la clave del cifrado.

El enunciado indica que el inventor del criptosistema fue Charles Wheatstone, quien inventó el cifrado de Playfair (aunque lleve el nombre de Lyon Playfair, quien lo popularizó).

Se disponen en la matriz los caracteres de la clave sin repetidos (ISACUNETO) y se completa con el resto del alfabeto, excluyendo «J» y «Ñ»:

Agrupamos en pares: QL · TA · SA.

Par QL — misma fila: cada letra se sustituye por la anterior de su fila → P y R:

Par TA — misma columna: cada letra se sustituye por la de encima → A y X:

Par SA — misma fila: cada letra se sustituye por la anterior → I y S:

Texto en claro: PRAXIS.

El primer paso es encajar la crib en el criptograma y construir el menú de enlaces entre caracteres que se usará para configurar la bomba:

Se asigna a cada enlace un codificador de doble extremo, eligiendo el camino más largo posible a través de los enlaces:

K → A → E → K → R → V → T → W → H → E → Q → W

Finalmente se ajusta la posición inicial de los tambores de cada codificador según su posición relativa en la crib (ZZA, ZZB, ZZC…):

En el simulador, montamos los tambores del orden I-II-III en los 12 codificadores de la batería superior y ajustamos las posiciones iniciales según el menú:

Establecemos las conexiones del menú en el panel posterior, «puenteando» la salida de cada codificador con la entrada del siguiente:

Añadimos el resto de cables del menú y aplicamos tensión a la letra «E» (la más involucrada en bucles), con hipótesis de conexión «E»↔«A»:

Activamos los interruptores CHAIN 1, el de la batería y CARRY:

Ponemos en marcha la bomba. Se detiene mostrando el ajuste de anillos: X, W, V:

El lateral derecho indica que «E» estaría conectada con la letra «T» en el tablero de clavijas:

Pasamos a la checking machine del simulador. Ajustamos anillos a X-W-V y pulsamos las letras del menú para descubrir todas las conexiones:

Conexiones obtenidas: E/T · Q/G · W/W · H/M · A/D · K/I · R/R · V/N · B/O · X/X · F/U · S/S. No hay contradicciones.

En la réplica Enigma (Enigma 3) del simulador, ajustamos los anillos de los rotores I, II y III a X, W y V:

Ponemos posición inicial Y-Y-Y (no Z-Z-Z, para compensar un error conocido del simulador de la bomba en los tambores I, II y III):

Introducimos las conexiones del tablero de clavijas conocidas:

Desciframos el criptograma de la crib y obtenemos el texto en claro correcto, confirmando que la clave es válida:

El título («Fuerza») y el enunciado apuntan al cifrado César. El espacio de claves es de solo 26 desplazamientos — perfectamente atacable por fuerza bruta, incluso a mano.

Probamos sistemáticamente todos los desplazamientos. Colocamos el criptograma en la primera fila y, en cada fila sucesiva, el carácter anterior del alfabeto, hasta obtener texto legible:

El primer criptograma está formado solo por caracteres alfabéticos en mayúsculas, lo que sugiere un método clásico. Calculamos el Índice de Coincidencia (IC) para determinar si es transposición/sustitución monoalfabética o polialfabética.

IC obtenido: 0,0441. Muy alejado del español (0,0775), por lo que descartamos transposición y sustitución monoalfabética simple. Apunta a cifrado polialfabético.

Aplicamos el método Kasiski usando el software CriptoclasicosV2.1 para detectar secuencias repetidas y estimar la longitud de la clave:

El software detecta secuencias repetidas y propone longitud de clave = 6 (mcd de las separaciones 6, 30, 66, 78). Probamos con Vigenère de clave longitud 6:

El software propone la clave DECPDA, pero el texto parcialmente descifrado muestra que la cuarta posición no es correcta. La clave correcta es DECADA:

Texto en claro obtenido: «NACI EN LA DECADA DE LOS AÑOS SETENTA DEL PASADO SIGLO. SNEFRU FUE UN FARAON DEL ANTIGUO EGIPTO Y EL TIENE LA CLAVE PARA DESCIFRAR EL SIGUIENTE CRIPTOGRAMA»

→ El amigo nació entre 1970 y 1979.

La cadena 8735f04f7d38955fa9a11e6265f11b16 tiene 32 caracteres hexadecimales = 128 bits. El texto anterior menciona a Snefru, que además del faraón es el nombre de una función hash criptográfica de 128 bits creada por Ralph Merkle.

Introduciendo el hash en una web especializada en Snefru-128, obtenemos el texto en claro:

«MI AÑO DE NACIMIENTO ES UNO DE LOS DE LA PRIMERA MITAD DE LOS AÑOS SETENTA. EL SIGUIENTE CRIPTOGRAMA ESTÁ CIFRADO CON RSA, EL PRODUCTO DE LOS DOS PRIMOS ES 52.841 Y LA CLAVE PÚBLICA ES 7»

→ El amigo nació entre 1970 y 1974.

Datos públicos RSA: módulo n = 52.841, clave pública e = 7. Para descifrar necesitamos la clave privada d. Factorizamos n con el software «Simulación de la Fortaleza de Cifrados»:

Los dos factores primos son p = 53 y q = 997. Ahora calculamos la clave privada con el software genRSA:

Resultado: clave privada d = 7399. Desciframos el criptograma 6AE3 (decimal 27.363):

El año obtenido es 1974.

Abrimos Reto 9_Navidad 2017.bmp con el editor hexadecimal. Lo primero que llama la atención son los caracteres alfanuméricos LyQW2FDMTlR4 a partir de la posición 36 hex (54 decimal):

La cabecera BMP indica que su tamaño es 00 00 00 42 hex = 66 bytes, cuando lo normal son 54. La diferencia es exactamente 12 bytes = los 12 caracteres alfanuméricos. Se ha ampliado la cabecera para ocultar datos sin afectar la visualización de la imagen.

El tamaño real del archivo no coincide con el esperado tras la ampliación:

Se espera 373.734 + 12 = 373.746 bytes, pero el archivo tiene 466.396 bytes. Vamos a la posición 05B3F1 (último byte esperado) y justo después (05B3F2) encontramos la cabecera de un archivo ZIP (50 4B = «PK» en ASCII):

El ZIP parece contener un archivo Navidad2017.jpg. Extraemos el contenido desde 05B3F2 hasta el final y guardamos como Reto 9_Navidad2017.zip:

El ZIP existe y contiene Navidad2017.jpg, pero está protegido con contraseña.

Los caracteres LyQW2FDMTlR4 son la contraseña cifrada. Probamos como contraseña directa y como Base64 — no funciona.

La imagen del archivo es un tablero de ajedrez, que recuerda a una rejilla. La hipótesis es que se usó un cifrado de rejilla, y que las posiciones de las piezas indican los huecos perforados.

La rejilla resultante:

Colocamos la rejilla sobre papel y rellenamos los huecos de la primera fila y mitad de la segunda con los primeros caracteres del criptograma:

Rotamos 90° y continuamos:

Rotamos otros 90° y continuamos:

Última rotación de 90°:

Quitamos la rejilla y leemos el texto resultante:

Texto obtenido: TWlLR2FyQDM4. Probamos como contraseña — no funciona. Pero decodificado en Base64:

La contraseña en claro es MiKGar@38. Abrimos el ZIP y obtenemos la felicitación:

Abrimos Reto 10_Imagen.bmp con el editor hexadecimal. El tamaño indicado en la cabecera coincide con el tamaño real:

Esto descarta los métodos EOF y ampliación de cabecera. Tenemos que buscar otro método.

En los archivos BMP, cada línea de píxeles tiene una longitud múltiplo de 4 bytes. Si no llega a ese múltiplo, se añaden bytes de relleno con valor 0. Estos bytes son ignorados al visualizar la imagen, por lo que son perfectos para ocultar información.

La imagen tiene 523 píxeles de ancho y usa 24 bits (3 bytes) por píxel:

523 píxeles × 3 bytes/píx = 1.569 bytes por línea. Como 1.569 no es múltiplo de 4, se añaden 3 bytes de relleno por línea hasta llegar a 1.572. Con 412 líneas en total: 412 × 3 = 1.236 bytes disponibles para ocultar información.

Vamos a la posición del primer byte de relleno de la primera línea (hex: 36 + 621 = 657):

Los 3 bytes de relleno contienen los valores hex 4B 65 79 → ASCII: Key. ¡Hay datos ocultos!

Segunda línea (posición 657 + 3 + 621 = C7B):

Valores 2F 30 38 → ASCII: /08

Tercera línea (posición C7B + 3 + 621 = 129F):

Valores 2D 30 33 → ASCII: -03

Cuarta línea (posición 129F + 3 + 621 = 18C3):

Valores 00 00 00 → fin de la contraseña.

Contraseña reconstruida: Key/08-03. La probamos en el archivo ZIP:

¡Correcto! El archivo Documento 1.txt se descomprime correctamente.