-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 _____________________________________________________________________ | | | ======= == === === ==== == == === | | = == = = = = == == = | | = = = = = = = = = = = = | | xxxxx x x x x xxxxxx x x x x x | | x x x x x x x x x xxxxxxx | | x x xx x x x x x x x | | xxxxxxx xxx xx xxx xxxxx xxx xxx xxx xxx | |_____________________________________________________________________| Boletín del Taller de Criptografía de Arturo Quirantes http://www.cripto.es Número 79 1 de Noviembre de 2010 ======================================================================== EDITORIAL CRIPTOGRAFÍA IMPRESENTABLE - Seguridad Blackberry CRIPTO 101 - Destripando un sintetizador musical - El caso de la Virgen de la Candelaria ======================================================================== <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><> EDITORIAL <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><> !Truco o trato! Espero que ya estéis preparando los caramelos para los enanos, que este año están asolando España en la noche de Halloween. No creo que os bombardeen con huevos podridos si no soltáis las chuches, pero mejor no arriesgarse. Este Boletín es "trato" al 100%, y espero que os chupéis los dedos con él. He de agradeceros a todos las cartas que me enviáis, en la que incluís retos, curiosidades y referencias de todo tipo. Tanto es así, que he aprovechado la oportunidad para crear una sección nueva. "Cripto 101" es, a partir de ahora, el apartado donde vamos a diseccionar problemas de criptografía aplicada. No es necesario ser un profesional del ramo (y yo no lo soy, no me canso de repetirlo) para poder extraer algo de información sobre un sistema de seguridad. En Cripto 101 nos divertiremos intentando hacer de criptoanalistas. No siempre podremos llegar hasta el final, pero el mero hecho de intentarlo resulta muy divertido. Doy fe de ello. Por otro lado, el próximo 2 de noviembre hay elecciones en Estados Unidos, cruciales para el éxito o no de las reformas Obama. No tiene nada que ver con los temas que nos ocupa, pero aprovecharemos que el Pisuerga pasa por Valladolid para examinar la seguridad de sus queridas Blackberry. Por último, una adquisición reciente nos permitirá visualizar a Antonio Camazón, nuestro héroe particular, gracias a una fotografía cedida por uno de sus descendientes. Aprovecho este editorial para felicitar a los ganadores de los premios Bitácoras 2010, que acaban de ser fallados. El vencedor de este año, en la modalidad de "Mejor blog de seguridad informática" ha recaído en el equipo de Security by Default. Puesto que los Bitácoras se conceden por votación popular, sus ganadores combinan necesariamente una alta calidad en sus respectivos ámbitos como un amplio reconocimiento por parte de sus lectores. Mis más sinceras felicitaciones a Yago y su equipo por el éxito de este año, y espero que no vayan por ahí diciendo eso de "no, si no me lo merezco", porque sí que se lo merecen. El segundo clasificado fue un viejo conocido de todos nosotros: Kriptópolis, todo un veterano en la brecha digital que recientemente ha anunciado la continuación de la serie de artículos "Enigma", de Román Ceano, disponibles en http://www.kriptopolis.org/la-maquina-enigma y que os recomiendo muy vivamente. Y, en tercer lugar, aparece Un Informático en el Lado del Mal (http://www.elladodelmal.com/). Reconozco no haber oído hablar antes de este BOFH, pero tras leer la historia sobre cómo tumbaron la web de David Bisbal (accidentalmente, debo añadir), creo que este va a ir también a mi sala de honor de mis marcadores. Y ahora, paso al Boletín propiamente dicho. Mientras tanto, voy a ver si hay algún Premio Boletines Pesados 2011, y me apunto a hacer méritos. Feliz puente a todos. <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><> CRIPTOGRAFÍA IMPRESENTABLE <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><> =----------------------------------------------------------------------= Seguridad Blackberry =----------------------------------------------------------------------= La elección de Barack Hussein Obama como presidente de los Estados Unidos fue un hito histórico. Supuso un fin a la era Bush, y un soplo de aire fresco tras la férrea política del terror de sus predecesores. Su famoso eslógan "yes, we can" (sí, podemos) le llevó a la Casa Blanca ... donde aprendió que en algunos casos "no, he can´t" Uno de los problemas que tuvo se refería a su aparato de comunicación favorito: una Blackberry. Cuando quiso seguir utilizándola, los servicios secretos se opusieron de plano. Considerando que esos tipos saben mejor que nadie cómo irrumpir en las comunicaciones ajenas, podría concluirse que las Blackberry no son seguras. No parece que la Blackberry sea un aparato poco seguro. Diseñado como complemento para el hombre de negocios globalizado del Siglo XXI (lo siento, estoy sonando como un anuncio), está basado en un esquema que guarda la información, en forma segura, en servidores de empresa. Dicha información pasa al terminal en forma cifrada. De esa forma, nunca tenemos información no cifrada en tránsito. Un estudio exhaustivo de la seguridad de la Blackberry resultaría fascinante pero largo, y no lo haremos hoy. Pero lo guardamos como deberes para otro día. A no ser, claro, que los chicos de Security By Default se me adelanten y me pongan en ridículo con su buen hacer. De una gente que acaba de ganar el Premio Bitácoras 2010 no podemos esperar más que lo mejor. Digamos tan sólo que los algoritmos que usan incluyen AES para el cifrado de la información (tanto la que circula por redes como la que se puede almacenar en el terminal), SSL/TLS, autenticación RSA de dos factores, criptografía de curva elíptica ... y la versión con "seguridad avanzada para uso gubernamental" !incluye PGP! De hecho, la extrema seguridad del sistema Blackberry ha sido el origen de muchos quebraderos de cabeza para la empresa. El motivo es que los estados nacionales no digieren bien eso de tener un canal de comunicaciones que no puedan pinchar. En los dos últimos años, países como India, Arabia Saudí y los Emiratos Árabes amenazaron con prohibir los dispositivos Blackberry a menos que pudiesen tener acceso a sus comunicaciones. Otros países, como China o Rusia, solamente los permitieron después de "negociar" algún tipo de solución con RIM (Research in Motion, propietaria de las Blackberry). Se ignora en que consistió la solución; dado que los servidores de Blackberry, donde se almacenan los datos, se encuentra fuera de esos países, solamente podemos especular con algún tipo de acceso legal restringido: el juez emite una orden, se procesa y se envían los datos solicitados. En el caso de Arabia Saudí, parece que RIM accedió a ubicar allí uno de sus servidores, poniéndoselo así más fácil a los amigos de la interceptación. Sea por dichos motivos, o sea porque saben algo más, los responsables de seguridad de Estados Unidos desaconsejaron al presidente Obama que continuase usando su Blackberry. Parece que su "yes, I can" prevaleció, y finalmente se le permitió seguir usándola. Ni que decir tiene que se trataba de un modelo especialmente "securizado", y que no podrá usarlo más que de forma limitada. La presión ejercida por esos países tan poco respetuosos con los derechos humanos es indicación clara de que, a la primera ocasión, a RIM le van a hacer la cama. Por no mencionar a gobiernos más o menos amigos, que siguen teniendo una amplia capacidad de interceptación y descifrado. El problema es que el diablo está en los detalles. Por mucho AES y PGP con que sazonemos nuestro producto, un sistema tan complejo forzosamente acaba teniendo fugas por alguna parte. Algunas de ellas solamente son conocidas por la NSA y sus análogas de otros países. Otras ya son públicas. En Septiembre de este año, la empresa Elcomsoft, conocida por sus soluciones para reventar contraseñas, presentó su "Elcomsoft Phone Password Breaker", diseñado para recuperar información protegida por teléfonos Blackberry e iPhone. La cosa, dicha así, da miedo. Se supone que las comunicaciones entre el servidor (llamado Enterprise Server) y el smartphone están protegidas por el algoritmo AES, que también permite almacenar de forma segura diversa información en la Blackberry, como números PIN o contraseñas de banca online. Bien, desvelemos la trampa. El producto de Elcomsoft no revienta AES, ni permite desbloquear una Blackberry, obtener su número SIM o liberarlo ("jailbreaking"). Lo que hace es actuar sobre un elemento muy necesario: las copias de seguridad. En efecto, obtener seguridad en las comunicaciones es algo muy útil, pero a un hombre de a pie (empresario o no) le resulta al menos tan importante protegerse contra las pérdidas de información. Quien no haya perdido datos por borrados accidentales, cuelgues del ordenador, fallos del disco o del lápiz USB, CDs rayados, etc, que levante la mano. Yo, varias veces. Los medios digitales, sean hardware o software, son vulnerables en ese sentido, y tener una sola copia de un documento es apostar por el desastre. Por ese motivo, las Blackberry tienen una opción de copia de seguridad. Por defecto, suelen crearse en los siguientes directorios: Mac: ~/Library/Application Support/MobileSync/Backup/ Windows XP: \Documents and Settings\(nombre de usuario)\Application Data \Apple Computer\MobileSync\Backup\ Windows Vista/7: \Users\(nombre de usuario)\AppData\Roaming\Apple Comput er\MobileSync\Backup\ Allí se almacena prácticamente todo, desde agendas a cuentas de correo. La información se guarda en texto llano, pero el usuario tiene la opción de cifrarla (algo especialmente útil si el backup contiene contraseñasu otra información sensible). Por supuesto, el usuario tiene que recordar bien la contraseña con la que cifra el backup, o de otro modo no podrá recuperar sus datos cuando los necesite. El problema de siempre. Elcomsoft se basa en la utilización de diversas técnicas de reventado de contraseñas. Las principales son: el uso de diccionarios (con muchos términos usados frecuentemente como contraseñas), y la aplicación de técnicas de "fuerza bruta", es decir: probar toda contraseña posible. Con las capacidades de los microprocesadores CPU actuales, y el aprovechamiento de los ultrarrápidos chips para pantallas gráficas (GPU), la fuerza bruta es realmente bruta. Las contraseñas para el backup de las Blackberry pueden probarse a razón de casi seis millones por segundo (usando dos procesadores Intel Xeon ES430). Eso significa que cualquier contraseña que utilizase seis caracteres alfanuméricos (letras minúsculas, mayúsculas y números) caería en menos de tres horas. Los diccionarios permiten aprovechar cadenas con más caracteres, así que si usted utiliza "Paris Hilton" como contraseña, cámbiela. Y no me refiero a sustituirla por Shakira o Lady Gaga. Tampoco intente hacerse el listo y usar "Par1s H1lt0n" o similares, que los reventadores de contraseñas ya vuelven cuando usted va. Obviamente, no podemos recordar un número binario de 256 dígitos (salvo que seamos Sheldon Cooper), así que lo habitual es introducir una contraseña alfanumérica y, por medio de una función adecuada, convertirlo en una contraseña binaria de la longitud requerida. Para aumentar la dificultad de un ataque por fuerza bruta o por diccionario, esta función incluye complicaciones criptográficas. Básicamente, toma la contraseña alfanumérica, le añade "sal" (es decir, un conjunto de bits aleatorios) y produce la clave que se necesita. En el caso de las Blackberry y los iPhone, la función utilizada es la PBKDF2 (Password-Based Key Derivation Function). Para fastidiar más al atacante, la función puede iterarse más de una vez. El sistema operativo de su iPhone3 usaba 2.000 iteraciones; el del iPhone 4 usa diez mil. ¿Cuántas veces repite la Blackberry el proceso? Pues una sola. No es de extrañar, por tanto, que los programas de Elcomsoft funcionen con tanta rapidez en el sistema de backup de las Blackberry. Para empeorar las cosas, resulta que el cifrado no lo hace la Blackberry propiamente dicha, sino el software que se instala en el ordenador a tal efecto. Eso significa que cuando los datos del backup pasan del terminal Blackberry al ordenador, lo hacen en forma de texto llano (los iPhone de Apple cifran desde el mismo terminal). Así que volvemos a encontrarnos con principio sagrado de la criptografía: la seguridad del sistema es la del eslabón más débil. De poco sirve usar AES si la contraseña que usted utiliza es débil; o si su Blackberry usa la PBKDF2 con una sola iteración; o si alguien le introduce un sniffer cuando su terminal hace backups. Obama puede usar su Blackberry porque se la han acondicionado especialmente. Si usted piensa que puede estar tan seguro como él, no you can´t. <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><> NUESTRA HISTORIA <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><> =----------------------------------------------------------------------= El rostro de Antonio Camazón =----------------------------------------------------------------------= Antonio Camazón, personaje muy querido en este Boletín, sigue desvelando su vida, aunque lo hace muy despacio. La presentación oficial de la "Biblioteca del Espía" en la Universidad de Zaragoza (ver Boletín Enigma nº 69 y nº 73) fue un acontecimiento que por desgracia me perdí. Al acto acudieron dos sobrinos y una sobrina nieta de Camazón, lo que me obligará a darme de patadas en las espinillas en estéreo. Otra sobrina nieta no pudo aparecer, pero proporcionó a los organizadores dos fotografías de su famoso tío. He conseguido permiso para reproducir una de las dos fotografías. Muestra a un Camazón ya en la cincuentena, posando de cuerpo entero frente a un río o canal. La fotografía fue tomada el 30 de Noviembre de 1953 en Hendaya. Mi agradecimiento a su sobrina nieta (no incluyo aquí su nombre por si desea seguir en el anonimato), así como a Matilde Cantín, de la Universidad de Zaragoza, por gestionar la autorización y mantenerme bien informado de lo que ocurre por la capital aragonesa. La fotografía, por supuesto, va a la sala de honor del Museo Camazón. Pueden verla en http://www.cripto.es/museo/camazon_1953.jpg Lamento la tardanza, ya que tengo la fotografía y la autorización desde hace casi un año, pero es que cuando no tengo arreglo, no tengo arreglo. <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><> CRIPTO 101 <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><> =----------------------------------------------------------------------= Destripando un sintetizador musical =----------------------------------------------------------------------= Un lector del Boletín, al que llamaré X, me propone el siguiente reto. Me cuenta que trabaja con un sintetizador musical. Digamos que es un Alesis Fusion; eso no me lo cuenta él, pero para eso está Google. El caso es que hay personas que piensa que su cacharro debería poder usarse de forma distinta a como lo impone el fabricante: cambiar la forma en que trabaja, incluir funcionalidades nuevas, quizá adaptarlo a Linux. Por desgracia, el fabricante protege la ROM, así que esto requiere hacking puro y duro. El reto que X propone a este humilde servidor vuestro, y que yo os hago extensivo a vosotros es: ¿qué cifrado utiliza la protección ROM del Alesis Fusion? Comienza la tarea para el CSI Cripto. Lo primero que tenemos que considerar es que, según comenta X (cito): "el sistema lleva un pequeño software de arranque y actualización del firmware que desencripta el fichero en tiempo real en el momento de grabarlo en el dispositivo (en el cuál se graba ya desencriptado)." El fichero original, encriptado, está disponible en http://www.alesis.com/extras/product/fusion/Fusion_Image_v124.zip Lo siguiente sería visualizar el fichero por medio de un archivo hexadecimal, y hacer como que sabemos qué hacemos. Por desgracia, no soy criptólogo ni analista de software, no entiendo ni papa de lenguaje máquina ... es decir, disto mucho de ser un Grissom digital. Pero así y todo, vamos a ver qué averiguamos. Estas son las primeras líneas del archivo cifrado, en código hexadecimal: 8F93D96C814BF5CC 27E7952EBF01836E DC438375624D8D92 DC438375624D8D92 DC438375624D8D92 5D4D1B09B8A90311 53D6747677133ED7 43F7E98879C0660C BC4B7CDBE627F073 2D0B857E0ED86FD9 14566FCB25526D24 94405DA8AEC30EAD D40ACF85083C19ED B43B4B17E992A6B0 3D6A183654C082EC DC438375624D8D92 DC438375624D8D92 DC438375624D8D92 DC438375624D8D92 DC438375624D8D92 Permítaseme que llame en adelante "cadena" a cada grupo de 16 caracteres hexadecimales (cada cadena tiene un tamaño de 8 bytes, o de 64 bits). Lo primero que nos salta a la vista es que una cadena se repiten: DC438375624D8D92. Esta cadena, a la que llamaremos "cadena DC", se repiten en las siguientes posiciones: 3-5; 16-70; 72-135. También se repite en muchas otras posiciones, a veces formando grandes paquetes. Hay una segunda cadena que se repite muchas veces a lo largo del archivo: 33FCB3CED93FDD ("cadena 33"). De hecho, el final del archivo está plagado de copias y más copias de esta cadena. ¿Es estadísticamente posible? Veamos. El archivo en cuestión tiene unos ocho millones de cadenas. Existen un total de 16^16=2^64 cadenas, un número enorme (18 trillones, aproximadamente. Según eso, la probabilidad de que apareciese una cadena determinada es de uno entre veintrés billones. Sin embargo, la cadena DC aparece nada menos que 357.752 veces, y la cadena 33 se repite en 244.587. Que ambas cadenas, con probabilidades ínfimas, aparezcan casi el 15% de las veces, indica que son de todo menos casuales. Pero en ese caso, ¿qué significan? ¿Qué tienen de especial? ¿Serán como los "números chungos" de Perdidos? Algo de eso puede haber. En los archivos de texto llano (sin cifrar) aparecen con cierta frecuencia cadenas con ceros o con unos. Las ristras con ceros pueden representar regiones con "padding", esto es, números añadidos para completar un paquete de datos. Es como en el viejo chiste. Una persona quiere enviar un telegrama que diga "Pepe ha muerto." Cuando la operadora le dice que por el mismo precio puede poner tres palabras más, el emisor se lo piensa, hace un "padding" y añade: "vendo Opel Corsa." La técnica del "padding" se usa mucho en criptografía. El problema es que, si el "padding" consiste en siempre lo mismo, puede desvelar información al criptoanalista (para un ejemplo de justo lo contrario, véase "¿Donde está la Fuerza 34?", Boletín ENIGMA 46). Por otro lado, el propio X nos informa de que, Normalmente, las partes de una ROM que no han sido grabadas, permanecen todos los bits a 1, lo que visto en hexadecimal es FF FF FF FF. Y resulta que el final del archivo está plagado de copias de la que hemos llamado cadena 33. Las posiciones de las "cadenas chungas" (lo siento, no he podido resistirme), y el hecho de que se encuentren en grupos grandes, sugieren que pueden representar el texto cifrado correspondiente a cadenas de ceros, y de unos (0 y F en representación hexadecimal, respectivamente): Cadena texto llano Cadena cifrada 00 00 00 00 00 00 00 00 DC 43 83 75 62 4D 8D 92 FF FF FF FF FF FF FF FF 33 FC B3 CE D9 3F DD 31 Llegados a este punto, hay que echarle un poco de imaginación para determinar qué tipo de cifrado puede o no ser. En principio, descartemos el cifrado en flujo. Dicho tipo de cifrado suele sumar (XOR) un flujo de bits pseudoaleatorios al texto llano. Si fuese así, cada vez que introdujésemos 00 aparecería un byte (una pareja de caracteres hexadecimales) distintos. Pero resulta que lo que creemos es un bloque de ocho bytes 00 se convierte siempre en la misma cadena de ocho bytes. Eso huele más bien a cifrado en bloque. Tomo un bloque de Y bits, lo someto al algoritmo, y obtengo un bloque cifrado del mismo números de bits. Sin embargo, hay un problema. Para que eso suceda de forma tan sencilla, el resultado de cifrar un bloque ha de ser independiente de los demás bloques; es el denominado encadenamiento ECB. Sin embargo, y precisamente para complicar las cosas a los criptoanalistas, se recomiendan diversos tipos de encadenamiento, de forma que cada vez que introduzcamos 0000000000000000 en el cifrador obtengamos un resultado diferente (para ampliar información, recomiendo "Encadenando bloques", Boletín ENIGMA 64). Eso significaría que, en caso de ser realmente un cifrado en bloque, el fabricante ha sido tan tonto como para usar el sistema más vulnerable de encadenamiento de bloques. Bueno, en honor a la verdad, a lo mejor no era tonto, sino que sencillamente ha optado por una solución simple. El modo de encadenamiento ECB es fácil y rápido, cumple su función, y supondremos que el fabricante imaginaría que con ponerle las cosas difícil a los atacantes ya le valía. Barruntando algo más, no creo que un fabricante de sintetizadores musicales llegase hasta el extremo de inventar su propio sistema de cifra. Así que, probablemente, tomó un sistema de cifrado conocido. De acuerdo. Vamos a ir acotando posibilidades. Nuestras hipótesis nos han llevado a un cifrado en bloque, usado en modo ECB. Toma bloques de 16 caracteres hexadecimales, o lo que es lo mismo, de 64 bits, y los convierte en bloques cifrados de 64 bits. ¿Qué algoritmo de cifrado usa bloques de 64 bits? AES no puede ser, ya que usa bloques de 128 bits. Si echamos un vistazo a la Wikipedia, aparecen algunos sospechosos habituales: Blowfish, TripleDES, CAST, IDEA, RC5, la lista es larga. Pero el que tiene más papeletas es un algoritmo de cifrado, en bloques de 64 bits, hasta hace poco usado casi universalmente: DES, un paso al frente. Que DES sea el sistema de cifrado es verosímil: cumple las condiciones técnicas que hemos deducido y es un estándar ampliamente usado durante décadas. Pero no podemos condenar a alguien sin pruebas. Quizá pudiésemos deducir algo más conociendo el tipo de chip con el que funciona el sintetizador. O tal vez en alguna parte del software de arranque que nos menciona X se esconda la clave, o algo relacionado con la clave (no puede ser en el fichero que os indiqué antes, porque entonces todos los sintetizadores tendrían la misma clave). Creo que hemos llegado hasta donde podamos. O quizá no. DES es uno de los algoritmos más usado y atacados. Una forma de conocer la clave sería probarlas todas y ver cuál de ellas nos da DC 43 83 75 62 4D 8D 92 cuando introducimos una ristra de ceros. Si esa misma clave, al cifrar unos, nos diese como resultado la cadena 33, tendríamos no solamente al sospechoso, sino al arma de crimen. Seguro que la NSA tiene una lista enorme, con la clave que, aplicada a una ristra de ceros, nos da el resultado que queremos. Pero nosotros no somos la NSA, así que nos quedamos aquí. =----------------------------------------------------------------------= El caso de la Virgen de la Candelaria =----------------------------------------------------------------------= Fernando Herráiz Sánchez, tinerfeño de pro, me propone (y yo a vosotros) un peculiar reto criptográfico. Ahora nos vamos a remontar varios siglos en el pasado, para encontrar insignias cifradas relacionadas con la religión. Pero en este caso no se trata de códigos secretos del Vaticano o cifras medievales. El lugar donde encontraremos nuestro reto no puede ser más diferente: los ropajes de una virgen. La imagen de la Virgen de la Candelaria apareció oficialmente en Tenerife en 1496. Oficiosamente, un siglo antes, es decir, antes de la conquista de la isla. Cómo una talla de una virgen cristiana llegó al archipiélago un siglo antes de su conquista es algo que me resulta cuando menos extraño, pero parece que hubo diversas visitas de expediciones europeas de reconocimiento. En una de ellas, proviniente de Mallorca, un grupo de frailes pudo hipotéticamente llevar allí la imagen. Wikipedia dixit, y no puedo hablar en favor de la veracidad de esa posibilidad. Que lo diriman los historiadores. Bástenos saber que la imagen que nos ocupa comenzó siendo misteriosa incluso en su nacimiento. En cualquier caso, los colonizadores castellanos le construyeron iglesia y luego basílica, y la situación estratégica de Canarias como lugar de paso llevó la devoción de la Candelaria al Nuevo Mundo. Según la Wikipedia, el propio Hernán Cortés llevaba al cuello una imagen suya. En 1825 o 1826, la imagen original se perdió, víctima de una inundación. A pesar de los esfuerzos de los isleños, nunca volvió a aparecer, motivo por el cual se encargó al tallista Fernando Estévez que hiciese una nueva imagen. Hoy día, los canarios pueden disfrutar de su protección: es la patrona de Canarias; y también de otros lugares de Iberoamérica (Medellín, Cartagena de Indias y Mayagüez, por citar algunos). Este pequeño fragmento de historia resulta de por sí interesante, pero fuera del alcance de un boletín sobre criptografía. O lo sería, de no ser por la siguiente descripción que de la imagen original da Fray Alonso de Espinosa, dominico del siglo XVI: "...La Imagen esta adornada en el cuello del vestido, cinturón en los extremos de las mangas y al pie de la túnica con unas letras, que aún en la actualidad, no ha podido entenderse su significado" ¿Letras sin significado? Ahí entramos nosotros. Según la descripción de Fray Alonso, que me incluye Fernando en su consulta, las letras desconocidas se encuentran en diferentes lugares de su ropaje: Collar: TIEPFSEPMERI Cinturón: NARMPRLMOTARE Bocamanga izq. LPVRINENIPEPNEIFANT Bocamanga dcha OLM INRANFR IAEBNPFM RFVEN NVINAPIMLIFINVIPI NIPIAN Orla izq.: FVPMIRNA ENVPMTI EPNMPIR VRVIVINRN APVIMFRI PIVNIAN NTRHN Orla derecha: EAFM IRENINI FMEAREI Bajos: NBIMEI ANNEIPERFMIVIFVF El ojo más perezoso podrá ver enseguida patrones y repeticiones. Demasiados, quizá. Como nos dice Fernando, "a primera vista, desalentador; y a segunda, también". Bien, apliquemos un par de neuronas al asunto. ¿Qué podemos obtener acerca del texto? Lo primero es obtener información sobre su contexto histórico. Si nos atenemos a la fecha oficial de descubrimiento, veremos que ya en 1496 existía el cifrado de sustitución polialfabética, cortesía de Leon Battista Alberti. Ahora bien, ¿y si la hipótesis que data la imagen a comienzos del siglo XV fuese cierta? Vamos a imaginarlo, aunque fuese tan sólo como ejercicio mental. En aquella época, ya existían las cifras de sustitución monoalfabética simple: la compilación de Gabriel de Lavinde, secretario del antipapa Clemente VII, incluye 28 cifra de ese tipo, y está fechado hacia 1379. Es, pues, históricamente posible que los códigos de la virgen de la Candelaria representasen un mensaje cifrado, por más que me resulta difícil imaginar a un fraile de comienzos del siglo XV pintando mensajes cifrados en una imagen destinada a tierras donde la escritura latina brillaba por su ausencia. Sin embargo, incluso la más generosa interpretación histórica choca con las realidades de la criptografía. Lo primero que podemos preguntarnos es: si se tratase de un mensaje cifrado, ¿no se habría descifrado hace ya tiempo? En este caso, podríamos imaginar que la ausencia de pruebas constituye una prueba de ausencia. Pero tal línea de "razonamiento" haría que Carl Sagan se revolviese en su tumba, así que vamos a trabajárnoslo un poquito. Suponiendo que las letras de la imagen original fuesen una cifra de sustitución monoalfabética, lo primero sería hacer un análisis de frecuencias. En la web http://www.characterfrequencyanalyzer.com nos lo ponen fácil, así que intruducimos todos los textos, y nos sale el siguiente análisis (redondeado): Letra A B E F H I L M N O P R S T V Frec (%) 7 1 10 7 0,6 18 2 8 15 1 9 9 0,6 3 7 Lo primero que encontramos es una falta de letras: C, D, G, Q, X, Y, Z. Podríamos pensar que representan letras de muy baja frecuencia, que no aparezcan en el texto; pero que de 22 falten 7, a mí me parece algo raro. En el extremo opuesto, vemos que hay letras demasiado frecuentes. Para verlo mejor, comparemos las letras más frecuentes de nuestro texto cifrado con las del alfabeto español: Imagen Actual I 18% E 13% N 15% A 13% E 10% O 9% P 9% S 8% R 9% N 7% M 8% I 6% A 7% R 6% F 7% L 6% La diferencia entre ambas frecuencias es notable, pero quizá no significativa. Volvamos a hacer de abogados de la Virgen (!no del diablo!). Tal vez el texto llano se refiera a oraciones, invocaciones y "latinajos" tipo "ora pro nobis", que podría alterar la frecuencia de las letras que aparecen, haciendo que algunas sean más frecuentes de lo normal, y otras lo sean menos. Por otro lado, las letras "actuales" que he tomado son las compiladas por Helen Fouché Gaines a comienzos del siglo XX, y el idioma cambia con los siglos. Pero ni así parecen cuadrar las cosas. Analizando la frecuencia de las sílabas, la cosa se pondría peor. Por ejemplo, el término IRENINI que aparece en la orla derecha. Si las letras cifradas I,N correspondieran a las letras en texto llano E,A, entonces IRENINI se traduciría como A**EAEA, o bien como A**AEAE. Usemos aquí el índice de coincidencia (IC). Los lectores más interesados en saber cómo se calcula pueden repasar el Boletín ENIGMA nº 32 ("Frecuencias y coincidencias"). Aquí solamente diré que es un número que nos indican cómo de frecuentes son, no ya las letras, sino su disposición en el lenguaje. El ejemplo del párrafo anterior nos vale aquí: por muy frecuentes que sean las letras A y E, es prácticamente imposible encontrar AEAE en un texto en español. En la página web http://multimatter.com/tools/frequency.php obtenemos un análisis de frecuencias con gráfica de barras, y que ya de paso nos calcula el índice de coincidencia. Un IC igual a uno indica que el texto es completamente aleatorio. Los idiomas tienen valores de IC mayores, en torno a dos. Por ejemplo, el IC del idioma inglés es de 1,73; el del español, 1,94; el del alemán llega a 2,05. Nuestro texto cifrado tiene da un valor del IC de 2'67. Demasiado alto. Una de las misiones de un sistema de cifrado es reducir el IC hasta dejarlo lo más próximo a la unidad. Una sustitución monoalfabética tendría el mismo IC que el idioma original, y un cifrado más sofisticado (digamos, una sustitución polialfabética de finales del XV) daría un IC más bajo. Puesto todo junto (la frecuencia demasiado alta de unas letras, demasiado baja de otras, el problema con el IC), el veredicto parece claro: no hay cifrado. Gana el abogado del diablo. Reconozco, sin embargo, que queda un punto poco claro: ¿por qué el IC es tan alto? Si el "cifrador" hubiese tomado letras al azar, para crear un batiburrillo sin más valor que el meramente estético, tendríamos un IC muy bajo. ¿Hay aquí una intencionalidad oculta? Es muy posible. Pero en mi opinión (y cuando digo esto tengo en cuenta lo que decía Harry Callahan sobre las opiniones), no se trataría de ocultar información, sino de lo contrario. Tal vez el artista no sabía de latín, en cuyo caso se limitó a imitar latinajos. Eso podría explicar el IC tan alto, y al mismo tiempo el por qué no se limitaron a pintar oraciones en latín, que hubiera resultado más lógico. Ahí está mi conclusión. Quien quiera recurrirla, no tiene más que comenzar. Pero antes de preparar su alegato, señores, tengan muy en cuenta este detalle: si se van a Tenerife a ver los textos que adornan la imagen de la virgen, descubrirán que NO SON LOS MISMOS que hemos estudiado aquí. Recordarán que dije que la imagen original desapareció a comienzos del siglo XIX. Las inscripciones que hemos visto aquí son las originales, tal como las transcribió Fray Alonso de Espinosa. La que se venera en la actualidad es una copia que fue encargada por los Marqueses de Adeje a finales del siglo XVII. Debería, por tanto, ser igual a la original. !Pero no lo es! Al menos, los textos que le adornan son diferentes. Por qué el copiador no se limitó a transcribir lo que vio es algo que no puedo imaginarme. En cualquier caso, esto es lo que podemos leer en la imagen actual (llamaremos A a la imagen original, y B a la copia): Collar: A - TIEPFSEPMERI B - MARMPRTMOLALEI Cinturón: A - NARMPRLMOTARE B - MARMPRTMOLALEAII Bocamanga izq. A - LPVRINENIPEPNEIFANT B - IMPRTMOLALEIIMARMPRTMOLALE Bocamanga dcha A - OLM INRANFR IAEBNPFM RFVEN NVINAPIMLIFINVIPI NIPIAN B - ARMPRTMOLATMPRTMOLALEI Orla izq.: A - FVPMIRNA ENVPMTI EPNMPIR VRVIVINRN APVIMFRI PIVNIAN NTRHN B - RIANNBIMEMNINKNVINAIMTIFINRIANNBI7NKNVINAIMTIFIN Orla derecha: A - EAFM IRENINI FMEAREI B - RIANNBI7NKNVINAIMTIFIN EMNI Bajos: A - NBIMEI ANNEIPERFMIVIFVF B - IFINRIANNBIMEMNI7NKNVINAIMTIFIN IKNVINAIMRIAMNBIMEMNINKNVINAIMTIFIN Les daría los datos de frecuencias y de IC, pero me remito a las páginas web anteriores. Inténtenlo, a ver qué sale. O, sencillamente, vean los textos y apliquen un poquito de sentido común, como hemos hecho en este sencillo experimento que nos ha brindado Fernando Herráiz desde Tenerife. Por mi parte, caso cerrado. Se levanta la sesión. ======================================================================== El boletín ENIGMA es una publicación gratuita del Taller de Criptografía, y se rige por las normas de la licencia de Creative Commons "Reconocimiento-NoComercial-CompartirIgual". Se permite su libre copia, distribución y comunicación para fines no lucrativos, citando nombre y referencia. Para más información, véase la licencia Creative Commons en sus formas reducida y completa: http://creativecommons.org/licenses/by-nc-sa/2.5/es/deed.es http://creativecommons.org/licenses/by-nc-sa/2.5/es/legalcode.es PARA DARSE DE ALTA: envíe un mensaje a la dirección altasybajas arroba cripto.es añadiendo las palabras alta_enigma en el asunto (subject). PARA DARSE DE BAJA, envíe un mensaje a la dirección altasybajas arroba cripto.es añadiendo las palabras baja_enigma en el asunto (subject) Para comentarios a este boletín (dudas, preguntas, consultas, críticas, noticias, colaboraciones, etc.), estoy a su disposición en la dirección noticias arroba cripto.es Página del Boletín Enigma (incluyendo números atrasados): http://www.cripto.es/enigma.htm (c) Arturo Quirantes 2010. ======================================================================== -----BEGIN PGP SIGNATURE----- Version: PGP 6.5i iQA/AwUBTM6G+g7Y43Xkw2u9EQLt7ACg/gyTQ5UfE4kFXihgVb+j1uqNdSwAn1Go v8JdVVHSvr05nfhRUpfzw2S+ =tJPd -----END PGP SIGNATURE-----