-----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 61 1 de Junio de 2008 ======================================================================== EDITORIAL TEMAS DE ACTUALIDAD - Reto criptográfico en Fermilab - Bletchley Park te necesita - HAHSBuilder, otro paquete hash CRIPTOGRAFÍA IMPRESENTABLE - Inseguridad por defecto: los certificados digitales CRIPTO 101 - Shannon y la teoría de la codificación (II) - CORRECCIÓN - Shannon y la teoría de la codificación (III) LIBERTAD VIGILADA - España autoriza el uso de Rota "caso por caso" ======================================================================== <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><> EDITORIAL <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><> Si hay algo que estoy dándome cuenta al hacer el Boletín ENIGMA, es la falta de uniformidad en su longitud, contenido y temática. Lo que resulta inevitable, pues además de los típicos problemas de tiempo me veo limitado por el atractivo informativo del mes, criptográficamente hablando. Es decir, un mes viene prácticamente árido, y al siguiente las noticias se agolpan, y por supuesto se esperan a última hora para llamar a la puerta. El boletín del mes pasado, sin ir más lejos, no tenía ni editorial. Este mes, la verdad, hemos tenido bastante movida. Y algunos asuntos ni siquieran han podido entrar en el Boletín de este mes. Permítanme dar ejemplos. ¿Recuerdan aquella incursión del Ejército colombiano en busca de guerrilleros de las FARC en Colombia, que casi provoca una guerra? Pues por lo visto, la información capturada en los ordenadores de los guerrilleros ha revelado información sobre futuros planes de las FARC, incluyendo los de encargar a la ETA española atentar contra altos cargos colombianos. Dicha información fue recuperada por la Interpol, y estaba originalmente cifrada. No se sabe nada acerca de qué sistemas o programas de cifrado utilizaron, ni siquiera cómo lograron recuperar la información (Bruce Schneier, en correo privado, me apunta a la posibilidad de que adivinasen la contraseña). Resulta cuando menos extraño que nadie haya aprovechado la ocasión para vendernos la moto de "los terroristas usan criptografía, así que hay que regularla". Quizá interese más acallar el hecho de que se puede acceder a la información y saltarse las protecciones. Aquí vamos con un recordatorio de por qué necesitamos protegernos con criptografía. Blackberry ofrece, entre otras cosas, un servicio de correo electrónico protegido con un cifrado que utiliza nada menos que el estándar AES, de 256 bits. El gobierno indio quiere husmear dichos mensajes, así que le exigió a RIM, la empresa canadiense que comercializa Blackberry, que le diese una copia de las claves usadas por todas las Blackberry que se usasen en India. El motivo es el que se usa siempre en estos casos "por defecto" (y nunca mejor dicho): luchar contra el terrorismo. RIM, como podemos imaginar, se negó, ya que una cosa es una orden judicial para descifrar una comunicación en concreto, y otra muy distintar darle a nadie opciones de caza libre. Afirmaron que la infraestructura de su red no les permitía acceder a los mensajes descifrados ni siquiera a ellos. Más aún, si debilitaban las claves para permitir al gobierno indio leer las comunicaciones de las Blackberry, ¿qué impediría a otros países hacer lo mismo cuando los datos viajan de las Blackberry indias a los servidores centrales canadienses? La respuesta del gobierno indio fue: muy bien, entonces vamos a prohibir las Blackberry en nuestro país. El pasado 15 de Mayo, The Economic Times afirmó que RIM cedería y permitiría al gobierno indio acceder a las claves de los usuarios no comerciales. Hace cuatro días, el India Times afirmó que, por el contrario, RIM se lo ha pensado mejor y ha decidido que no suelta las claves. Sin embargo, ¿cómo creerles ahora? ¿No es posible que hayan cedido ocultamente para salvar su negocio en la India, y al mismo tiempo pretendan mantener la confianza de sus clientes? Cuando el gobierno se mete a buscar nuestras claves, la única conclusión segura es que no será para nada bueno. A no ser que nos queramos creer que un gobierno jamás abusaría de su poder, faltaría más. Y esto en lo que respecta a noticias serias. La tontería que dijo el fundador de Atari recientemente sobre un chip llamado TPM que acabaría con la piratería de una vez por todas, mejor que la lean ustedes directamente, que a mí me da la risa tonta: http://www.schneier.com/blog/archives/2008/05/tpm_to_end_pira.html Suma y sigue, así que mejor nos centramos en el Boletín de este mes. Hoy cerramos el -creo- interesante artículo sobre Claude Shannon y sus aplicaciones de la Teoría de la Codificación a la criptografía. Incluyo también una corrección al artículo del mes pasado, que quien tiene boca, se equivoca. Para compensaros, os recuerdo que ya tenemos los dos artículos de Shannon en el Taller de Criptografía, a disposición de todos vosotros. Tenemos también dos retos muy distintos: por un lado, veremos cómo se descifra un mensaje recibido por el Fermilab norteamericano, y por otro, asistiremos al "reto" de salvar Bletchley Park, la "cámara negra" de Churchill. También tenemos el habitual capítulo de "Libertad Vigilada" (insisto, estamos a punto de terminárnoslo, así que a ver qué libro fusilamos, er, digo, comentamos ahora). En el apartado de colaboraciones, tenemos un nuevo programa para calcular funciones hash, cortesía de su autor LordHASH, que espero sea de vuestro interés. Y, por último, un artículo sobre la criptografía de clave pública, su uso diario, y la forma en que pequeños detalles pueden echar por tierra la seguridad de un sistema complejo. Lo he redactado a partir del artículo de una nueva web sobre seguridad informática y criptografía que aprovecho para presentaros y recomendaros. Se llama "Security By Default" http://www.securitybydefault.com/, y acaba de ser inaugurado por tres lumbreras del ramo: Alejandro Ramos, José A. Guasch y Yago Jesús (quien creo que se dejó los apellidos en casa :-). Según la presentación hecha por este último, parece que el trío son de lo más rompedor desde Rivest, Shamir y Adleman, o no tienen abuela, o ambas cosas. Apuntad su dirección en vuestros marcadores, porque vale la pena. Mi única queja es que hayan convocado a unirse al equipo Kriptópolis en el reto SHA-1, en lugar de fichar por el Taller. Vale, sí, envidia cochina. Y ahora, a seguir leyendo se ha dicho. Saludos. <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><> TEMAS DE ACTUALIDAD <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><> =----------------------------------------------------------------------= Reto criptográfico en Fermilab =----------------------------------------------------------------------= El Laboratorio Nacional del Acelerador de Fermi (Fermilab para los amigos) es uno de los centros de investigación más excepcionales del mundo. Presume de tener el acelerador de partículas más potente del mundo (con permiso del CERN europeo), y también puede estar orgulloso de su plantel de científicos. Resulta, por tanto curioso, que los descubridores del quark top sean incapaces de descifrar un criptograma. Efectivamente, Fermilab no tiene nada que ver con la creación o ruptura de códigos. Pero el año pasado, su oficina de relaciones públicas recibió una carta en clave. Incapaces de descifrarla, decidieron publicar el caso en la revista de Fermilab, "Symmetry Breaking". Se trata de un criptograma en tres partes. La primera y la tercera son una ristra de barras verticales espaciadas. Vean por ejemplo, el comienzo de la primera parte: ||| || ||| || ||| ||| ||| ... El lector interesado puede ver el mensaje completo aquí: http://www.symm etrymagazine.org/breaking/wp-content/uploads/2008/05/fnalcodeletter.jpg. La noticia llegó a diversos foros como Slashdot, y pronto aparecieron soluciones. Vamos a ver cómo lo resolvió Geoff, un estudiante del Real Colegio Militar de Canadá. Para él, y para nosotros, es obvio que el mensaje es una sucesión de tres elementos: |, || y ||| (| no aparece en la sección que he reproducido arriba, pero sí más adelante). Haciendo la transformación |=1, ||=2, |||=0 tendríamos el siguiente mensaje: 020 200 001 112 102 000 201 ... ¿Por qué agrupar los números en ternas? Pues porque así tenemos un total de 27 posibles ternas (desde 000 hasta 222), lo que nos permitiría codificar las letras del alfabeto (incluyendo el espacio), algo muy conveniente. Por supuesto, podemos hacer otras transformaciones (por ejemplo, |=1, ||=2, |||=0). Pero Geoff escogió esta posibilidad (tras probarlas todas, imagino) porque así el mensaje tiene sentido. Haciendo la siguiente correspondencia: 000=Espacio, 001=A, 002=B, 010=C, 011=D, 012=E, 020=F, ... el mensaje de la primera parte del criptograma adopta una forma legible en inglés: "FRANK SHOEMAKER WOULD CALL THIS NOISE" (Fank Shoemaker llamaría a esto ruido). Por lo visto un tal Frank Shoemaker trabajó en los anillos del acelerador Fermilab. Según un colega, era un tipo genial y muy divertido. Construyó diversas cámaras de detección de partículas, en las una detección de partícula puede deberse a una coincidencia aleatoria, y quizá de ahí venga la referencia al "ruido" Ahora está retirado, y por lo visto no tiene nada que ver con el criptograma. Claro que eso es lo que él dice, y como somos tan desconfiados ¿por qué deberíamos creerle? La tercera parte es parecida, pero parece diferente en forma. He aquí algunos caracteres: | | | || | || | | || ... La hipótesis de Geoff es que sigue siendo un código ternario. En este caso, |=1, | |=2, | | |=0, y || actúa como elemento separador. De esta forma obtendríamos: 012 111 121 110 120 ... Sometido a una transformación igual a la que hemos visto antes, obtendríamos el siguiente resultado: "EMPLOYEE NUMBER BASSE SIXTEEN" (Número de Empleado Basse Dieciséis). No parece tener mucho sentido. Pero quizá ayude echarle un vistazo a la segunda parte del criptograma. Se trata de lo que aparentemente es un sistema de sustitución monoalfabética simple. Algunas letras y números se transforman en símbolos. Justo debajo aparecen tres símbolos: una letra s, un triángulo y lo que parece ser una letra griega lambda. Según la sustitución monoalfabética, el triángulo es la letra F, la letra lambda es la letra C ... y la letra s no aparece. Podríamos, por tanto, "traducir" la segunda parte del criptograma como "sFC" Aquí entramos en el terreno de las conjeturas. FC, en notación hexadecimal (es decir, en base 16) es igual al número decimal 262. Aplicando la "recomendación" de la tercera parte del criptograma, obtenemos el número de empleado S-252. ¿Tiene este sentido este galimatías? Sorprendentemente, parece que sí. Desde 1967, todos los empleados de Fermilab tienen un número de identificación. Así que el identificador S-00252 nos lleva a ... un tal Pierre Piroue. Él ya ha sido contactado, y niega ser el autor del criptograma. Pero tanto Piroue como Shoemaker se conocían, pues ambos eran miembros del departamento de Física de Princeton. También hay quien se ha fijado en la palabra "Basse" en lugar de "Base". Parece un sencillo error, aunque podría argumentarse que la "s" extra es precisamente "lo que Frank Shoemaker llamaría ruido". Sería, por tanto, una forma sutil de decirnos "enhorabuena, habéis descifrado bien la primera parte". O podría ser algo más profundo. Basse, en francés, significa "baja". Hay quien dice que el tercer criptograma lo que dice es "Número de empleada bajo 16". ¿Hay alguna trabajadora francesa de Fermilab con un número de identificación menor que 16? No lo sé; pero ¿es casualidad que Pierre Piroue sea un nombre francés? Puestoa a rizar el rizo, "Basse" es el nombre en francés de un instrumento musical, y resulta que Piroue !es también profesor de música! Puestos a echarle imaginación, hay quien apunta a que Shoemaker trabajaba en un edificio de Fermilab cuyo estilo arquitectónico recibe el nombre de "Basse oeuvre". Vale, a lo mejor sí sea casualidad, y "sFC" significa "signed FC", es decir, "Firmado: FC" Puede que incluso signifique "Shoemaker, F.C." Podríamos estar dándole vueltas durante mucho tiempo ... y probablemente lo haremos. Porque, como veis, eso de tomar lápiz y papel, menear un poco las neuronas y obtener la solución única y correcta es la excepción más que la regla. Para llegar a la solución de un criptograma hay mil y un caminos que hay que explorar, y no siempre se atina a la primera. Ni siquiera a la décima. =----------------------------------------------------------------------= Bletchley Park te necesita =----------------------------------------------------------------------= Hemos hablado largo y tendido en este boletín de Bletchley Park, el centro británico de desciframiento durante la Segunda Guerra Mundial. Probablemente sea la "cámara negra" más famosa de la historia. Hace unos años, tuve la oportunidad de caminar por entre sus calles, ya que "BP" sigue abierto, aunque ya no como centro de criptoanálisis sino como museo. En el Boletín ENIGMA 7 incluí una breve reseña de mi visita, en un artículo llamado "De vuelta a Bletchley Park, primera parte". En realidad, nunca hubo una segunda parte. Y la verdad es que lo merece. En estos años ha habido diversas mejoras y novedades del museo BP, incluyendo un museo de computación y la reconstrucción de Colossus, el primer ordenador del mundo ("Colossus, el proyecto redivivo", Boletín ENIGMA nº 56). En sus instalaciones se ha inaugurado un restaurante, la tienda de recuerdos vende libros y folletos muy interesantes, se hacen conferencias e incluso puede usted celebrar su boda allí. Según todos los indicios, BP nunca ha tenido mejor aspecto desde el final de la Gran Guerra. Y sin embargo, no es así. Bletchley Park se muere. El motivo es el mismo de siempre: el dinero, el maldito dinero. Los ingresos (en forma de entradas, principalmente) no son suficientes para mantener el museo funcionando. Bueno, quizá sí para eso, pero para poco más. Algunos de los famosos barracones ("Huts") donde los criptoanalistas aliados derrotaron a la Enigma permanecen en un estado próximo a la ruina, y el tejado de la mansión necesita reparaciones al toque de ya. En realidad, sin consideramos el reto a que ha tenido que enfrentarse Bletchley, ya es difícil que sigan abiertos. Se salvaron por los pelos de la especulación urbanística, carecen de subvenciones estatales y casi de patrocinadores privados, y cuando pidieron ayuda a la fundación Bill y Melinda Gates, se les respondió que no podía ser ... porque no se trata de un proyecto basado en Internet. Casi nada. Allí se inventó el ordenador, se pusieron los cimientos de la actual GCHQ (que, ahora sabemos, inventó la criptografía de clave pública antes que los norteamericanos), pero no parece ser suficiente para entrar en el pastel de 40.000 millones de dólares del tito Bill. Cosas veredes. El problema recibió atención informativa a mediados de Mayo en ZDNet, y ayer mismo nos lo recordó una nota de prensa del Bletchley Park Trust (http://www.bletchleypark.org.uk/news/docview.rhtm/516816). Aunque este humilde Boletín no tiene tanta audiencia como el blog de Bruce Schneier (todavía), no por ello vamos a inhibirnos y mirar hacia otro lado. !Hemos de salvar Bletchley Park! Si las negociaciones que están teniendo con la Lotería Nacional inglesa dan fruto, obtendrán una buena inyección económica, pero no pongamos nuestras esperanzas en ello. Así que os sugiero dos formas de ayudarles. Una de ellas es mandándoles dinero. Lo curioso es que en su web ni siquiera nos dicen cómo podemos enviarles pasta: ni paypal, ni tarjetas, ni nada por el estilo. Así que ¿por qué no meterles unas libras en el bolsillo pasando por su tienda virtual? Tienen libros estupendos (algunos de los cuales hemos revisado aquí), tazas, polos, y hasta una Enigma electrónica. Puede ser una buena oportunidad de comprar un regalo especial a alguien (y me refiero a algo que no encontrarás en Harrods ni en el Duty Free del aeropuerto). Y si no, ¿por qué no plantarse allí? Está a tiro de piedra de Londres, y para los aficionados a la cripto es un destino que no podéis perderos. Total, ya tenemos muy visto el British Museum, y eso del cambio de la guardia tampoco es para tanto. Así que la próxima vez que os plantéis en Inglaterra -que para eso están los vuelos baratos-, no dejéis pasar la oportunidad. Yo, si todo va bien, espero volver en Septiembre de este año. Tengo allí una reunión científica (nada relacionado con cripto), y me agradó ver que ponían a Bletchley Park como uno de los destinos recomendados. Por supuesto, espero que los que os paséis por allí tengáis el detalle de compartirlo con nosotros. Enviadme un e-mail con vuestra experiencia, y también fotos. Las mejores irán a nuestro Museo para solaz y deleite de todos. Corred la voz, y a ver hasta dónde podemos llegar. Tengo la impresión de que BP sobrevivirá una vez más. Pero necesitará apoyo. Ya está corriendo la voz en los foros, y esperemos tener buenas noticias que contaros en el futuro. De lo contrario, Colossus volverá a desaparecer y una parte de nuestra criptohistoria desaparecerá de forma irreversible. =----------------------------------------------------------------------= HAHSBuilder, otro paquete hash =----------------------------------------------------------------------= Si en el boletín 59 Antonio Villena nos regaló un paquete para calcular función hash MD5, hoy es el turno de otro amigo del Taller: LordHASH. Con ese apodo, no podemos menos que esperarnos una aplicación de funciones resumen (hash). Y así es. HASHBuider, su última creación, calcula códigos hash tanto para ficheros como para texto llano. El programa, en Java, está disponible en la web del Taller de Criptografía: http://www.cripto.es/herramientas/HASHBuilder.jar y listo para ser usado. En un ejercicio de coherencia, se ha aplicado su propia medicina y nos incluye los resultados de aplicar funciones hash a su propio fichero (lo que viene muy bien como comprobación de integridad): MD2: D01F88142A80D0DBBB1A3DBE229286D7 MD5: C7EC1484F76AAD3A66034C87F3DE210B SHA-1: 9795B2B4FA822F7441E1FD78852D3A5CC040C908 El autor os espera en su web http://lordhash.blogspot.com/ Esperemos que siga en la misma línea, y que nos asombre con lo que venga en el futuro. De alguien cuyo apodo parece robado al primo de Darth Vader, nos esperamos lo mejor. <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><> CRIPTOGRAFÍA IMPRESENTABLE <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><> =----------------------------------------------------------------------= Inseguridad por defecto: los certificados digitales =----------------------------------------------------------------------= Hace mucho, pero que mucho tiempo, cuando Internet llegaba a todos los sectores de la población, se planteó el problema de dotar de seguridad las transacciones electrónicas. Apareció entonces el protocolo SSL que utilizan los navegadores. De hecho, uno de mis primeros escritos sobre criptografía trataba el tema de los servidores seguros. Todavía podéis acceder a ellos (www.cripto.es/informes.htm, Informes 1, 4 y 5). Son "los viejos tiempos", nada menos que 1997. El problema a resolver es el siguiente. Dos partes, el usuario (U) y el banco (B) tienen que comunicarse de forma segura. Vale, marchando una de cifrado simétrico. Pero además han de asegurarse que nadie usa la clave común. Entra entonces la criptografía simétrica. El procedimiento es prácticamente idéntico al de PGP (programa para correo electrónico), y viene a consistir en los siguientes pasos: 1) El navegador de U solicita al servidor de B una clave 2) B envía un certificado electrónico (es decir, la clave pública del banco firmada por un "tercero de confianza" llamado Autoridad de Certificación o AC) 3) El navegador de U comprueba el certificado de B. Para ello, rebusca en su interior, saca la clave pública de la AC correspondiente y la usa para comprobar que la firma que ha hecho la AC en el certificado de B es correcta 4) Una vez U ha quedado satisfecho con la comprobación de identidad de B, genera una "clave de sesión" simétrica y la cifra con la clave pública de B. 5) B, usando su clave privada, descifra el mensaje de U y recupera la clave de sesión. Ahora tanto U como B tienen la misma clave de sesión, que utilizarán para comunicarse de forma segura. 6) Una vez finalizada la transacción, B y U borran la clave de sesión, se dan las buenas tardes y a otra cosa, mariposa. Este esquema se ha venido usando desde hace más de una década. ya en 1999 este que firma lo utilizó para pagar sus impuestos ante la Agencia Tributaria ("Pague sus impuestos ... digitalmente", Informe nº 10, http://cripto.es/informes/info010.htm). Por supuesto, no es un sistema impenetrable, sino tan sólo lo mejor que tenemos. Uno de los problemas subyacentes consiste en que la autenticación ha sido imcompleta. Es decir, U se queda tranquilo porque ha comprobado que B es B, pero ¿cómo sabe B que U es realmente U? ¿Y si es otro usuario el que está intentando acceder a la cuenta de U? Para ello, los bancos y comercios electrónicos hacen introducir al usuario información adicional: números de tarjeta, de DNI, claves de acceso, tarjetas de coordenadas, etc. Claro que un PIN de ocho cifras no es lo mismo que una clave simétrica de 128 bits, pero lo que hay es lo que hay. Una segunda solución, impulsada por el gobierno, consiste en dotar a todos los ciudadanos de un conjunto de claves criptográficas, insertas en una tarjeta, que les permite demostrar quiénes son en Internet: son los DNI electrónicos. El gobierno está deseando que la gente lo use con profusión en Internet, ya que eso permitiría, según ellos, que el comercio electrónico despegase, la gente respirase tranquila frente a fraudes, etc, etc (también podrían rastrear eficazmente los movimientos de todo el mundo si consiguen que vayamos por la Red con el DNI electrónico en la boca, pero obviemos esa nimiedad). Sin embargo, estamos hablando de millones de DNIs, por no hablar de convencer a todo el mundo para que se compren lectores de tarjetas, así que la solución SSL sigue siendo muy utilizada. Una forma relativamente sencilla de autenticar al usuario es hacer lo mismo que en su momento hizo el banco con su clave pública. Para ello, U crea un par de claves (pública y privada), envía la clave privada a una AC, ésta la firma y se la devuelve al usuario. Esto sería el "certificado digital" para el usuario. Ahora el usuario tiene una clave pública firmada por una AC de confianza, igual que un documento autenticado ante notario. A partir de aquí, si el banco o cualquier entidad electrónica desea comprobar que la clave que le ha llegado es la del usuario U, actuaría de la misma forma que hemos descrito anteriormente. Por supuesto, esto significa que el usuario ha de custodiar muy bien su clave privada, ya que es la "clave" para hacer todo tipo de compras o trámites electrónicos. Si alguien se la roba, sería lo mismo que si le robase el DNI; peor, en realidad, puesto que el DNI tiene foro y la clave privada, no. El problema es que, en el mundo real, y por mucho protocolo criptográfico que metamos por medio, tales transacciones se llevarían a cabo en ordenadores reales, esto es, lugares electrónicos infestados de virus, troyanos, vulnerabilidades, agujeros de seguridad y todo tipo de entes hostiles. Los ingenieros electrónico trabajan duro para minimizar estos problemas (sí, incluso los de Windows), pero dada la complejidad del software actual y el ingenio de los hackers (bienintencionados o no) convierten el proceso en una interminable batalla de ingenio. Veamos, como ejemplo, la estocada que nos plantea Yago Jesús, de www.securitybydefault.com. En el segundo artículo de esta interesante web, se dedica a darle vueltas al modo en que Windows almacena la clave privada del usuario. Vamos a hacerlo paso a paso. Como autoridad de certificación, escogeremos el de la Fábrica Nacional de Moneda y Timbre (FNMT), a través de su organismo Ceres. Abrimos el navegador, tecleamos http://www.cert.fnmt.es/index.php?cha=cit&sec=obtain_cert&lang=es, y al turrón. El primer paso, por supuesto, es solicitar el certificado, el paso 1. Para ello, introducimos nuestro número de DNI, escogemos la longitud de la clave asimétrica de 1024 bits (podemos hacernos una de 2048 bits, pero nos advierten que no todos los servicios telemáticos la admiten), y pulsamos "Enviar petición". El navegador genera el par de claves, envía la clave pública a Ceres, y se acabó el primer paso. En un segundo paso, tenemos que acreditar que nosotros somos nosotros. ¿Cómo? Pues con tecnología antigua: nos plantamos en una oficina del FNMT con el DNI en la mano. Finalmente, una vez los hayamos dejado satisfechos, ellos crearán el certificado (vamos, que firmarán nuestra clave pública), y no tendremos más que volver a la web de la FNMT para descargárnoslo. Ahora tenemos nuestra clave pública certificada por la FNMT. Puesto que la clave pública es, por definición, pública, no hay problema en diseminarla a los cuatro vientos, si así lo deseamos. Pero con la clave privada ... ah, amigo, esa es otra cuestión. Debemos protegerla con uñas y dientes. Los usuarios de PGP saben que sus claves privadas están protegidas con una frase de contraseña, lo que puede plantear problemas si tenemos un keylogger metido en el ordenador. Lo que hace el navegador es guardar la clave privada internamente. Las claves está protegidas mediante una contraseña que está derivada a partir de la contraseña que introducimos al iniciar la sesión en Windows. Sí, ya sé, también existen Linux, Mac y tu sistema operativo favorito, pero vamos a seguir con Windows. Porque el problema está precisamente en Windows. Verán ustedes. Por lo visto, Windows almacena los certificados mediante un sistema que tiene tres niveles de seguridad: bajo, medio y alto. Los rasgos fundamentales de dichos niveles son los siguientes: NIVEL BAJO. La clave privada se usará en cualquier momento en el que cualquier función de cualquier programa así lo solicite (una especie de "pase y sírvase"). NIVEL MEDIO. Antes de usar la clave, aparecerá una pantalla "pup-up" que informa del hecho (el típico "vamos a usar la clave, ¿desea continuar' si/no/cancelar") NIVEL ALTO. Para usar la clave, es necesario introducir una contraseña. Ahora imaginen que son ustedes los técnicos de Ceres y han de determinar el nivel de seguridad con el que se guardará la clave privada del usuario. ¿Qué decisión tomarían? Bien, todos los que hayan pensado "nivel bajo" que levanten la mano. Quedan expulsados del Boletín ENIGMA ignominiosa y fulminantemente. Los demás, espero que os hayáis ido al nivel alto, que sería lo lógico para algo tan sensible como una clave privada que se va a usar en transacciones bancarias, pagos de impuestos y cosas así. Entre medias de los dos grupos, situaremos a la gente de Ceres. En efecto, lo que Yago descubrió (con la boca abierta, imagino) es que, cuando su copia de Internet Explorer pedía el certificado digital, apareció un pop-up con el aviso siguiente: "Creando una nueva clave de intercambio RSA. Una aplicación está creando un elemento Protegido. El nivel de seguridad es Medio" ¿Como? ¿Nivel de seguridad medio? Pues sí. Por supuesto, al lado aparecía el típico botón "ajuste el nivel de seguridad", por si queremos subirlo o bajarlo. Pero ¿cuántos usuarios no lectores de boletines como éste se molestarán en hacerlo? El sistema ha escogido nivel medio, bueno, sabrá lo que se hace, pulso Enter y adelante. Peor todavía: si, durante la generación del par de claves, deseamos hacer una copia de seguridad, tanto el certificado (clave pública formada por la AC) como LA CLAVE PRIVADA son marcadas como exportables. De no ser así, claro, no podríamos copiarlas. Pero imaginen un programa spyware que quisiera extraer la copia privada. Como está marcada como exportable, podría acceder a ella. Con un nivel de seguridad medio, aparecería la ventana pop-up, sí, pero de nuevo nos encontraremos con usuario que solamente quiere que las cosas funcionen. ¿Que haría frente a un pop-up con algo escrito como "realizando copia de seguridad compatible con estándar HRLTT12, pulse continuar"? Eso mismo. No contento con la "prueba de concepto", Yago ha escrito un programa (CertDump) que actúa como lo haría un atacante exterior. Dicho programa permite exportar las claves pública y privada sin que el usuario intervenga para nada. Respecto al pop-up, CertDump lo "puentea" y envía una señal Enter por su cuenta. Yago propone, para protegernos, el siguiente proceso. Primero, pedir los certificados tal como lo hemos descrito antes. Acto seguido, exporten el certificado y la clave privada (a un CD-ROM o un pendrive) y borren el certificado del navegador. Después, vuelvan a re-importarlo (a partir de la copia exportada), teniendo mucho cuidado de a) no marcar ya la opción de "clave exportable" y b) escoger el nivel de seguridad máximo. Y es que, como de costumbre, las cosas pequeñas son las que nos llevan a la ruina. Sin un reino se perdió por un caballo, una identidad puede perderse por un pop-up; o por una elección de nivel de seguridad poco acertada. <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><> CRIPTO 101 <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><> =----------------------------------------------------------------------= Shannon y la teoría de la codificación (II) - corrección =----------------------------------------------------------------------= Por un error humano (estaba ya de números hasta la coronilla), la última columna de una de las tablas estaba equivocada. Decía: a b P(ai) P(bj) P(ai,bj) P(bj|ai) 0 0 0.75 0.75 0.5625 0.75 0 1 0.75 0.25 0.1875 0.25 1 0 0.25 0.75 0.1875 0.25 1 1 0.25 0.25 0.0625 0.75 cuando debía ser: a b P(ai) P(bj) P(ai,bj) P(bj|ai) 0 0 0.75 0.75 0.5625 0.75 0 1 0.75 0.25 0.1875 0.75 1 0 0.25 0.75 0.1875 0.25 1 1 0.25 0.25 0.0625 0.25 Y encima lo arreglé diciendo que las columnas 4 y 6 eran idénticas. Lo más curioso es que ni uno de los lectores me apercibió sobre el fallo. Una de dos: o no me lee ni mi madre, o tenéis tanta fé en mí que os creéis todo lo que digo sin pensar. Por supuesto, escojo la opción dos. =----------------------------------------------------------------------= Shannon y la teoría de la codificación (III) =----------------------------------------------------------------------= El uso de la probabilidad condicional nos da una forma de establecer hasta qué punto sabemos algo de una variable cuando ésta está relacionada con otra variable. Como vimos en la parte II de esta serie, al aplicarlo a las variables "texto llano" y "texto cifrado", obteníamos un curioso resultado: para que un sistema de cifra nos proporcione un secreto perfecto, el número de claves ha de ser tan alto como el de posibles mensajes. Por eso las cifras simétricas se consideran tanto más seguras cuantos más bits tengan. Como se vio anteriormente, podemos usar la entropía como medida de la incertidumbre, esto es, de la información que tenemos sobre el sistema. Bien, sigamos usándola para cuantificar. Si hacemos la suma H(A)=-Suma [P(ai)*Log(P(ai))] tenemos la entropía correspondiente a la variable A. También se llama "entropía a priori", y nos cuantifica la incertidumbre que tenemos acerca del valor de ai. También podríamos hacer lo mismo con la variable B y obtener su entropía H(B). Si tenemos dos variables (a,b), podemos extender el concepto y hablar de la entropía de las dos variables: H(A,B)=-Suma [P(ai,bj)*Log(P(ai,bj))] donde aquí p(ai,bj) es la probabilidad de que A tome el valor ai y B tome el valor bj. Esta entropía nos indica la incertidumbre que tenemos tanto en A como en B, suponiendo que ambas variables sean independientes. Puede demostrarse que la entropía H(A,B) cumple esta relación: H(A,B)<=H(A)+H(B) es decir, la entropía de dos variables es menor o igual que la suma de ambas entropías por separado. La igualdad sólo se da cuando X,Y son variables independientes. ¿Pero qué pasa si ai, bj guardan alguna relación? Pues en ese caso, nos interesa obtener la "entropía a posteriori", en la que la probabilidad de obtener ai depende de lo que valga la otra variable bj. Recordemos el concepto de "probabilidad condicional" P(ai|bj), que no es sino la probabilidad de que obtengamos ai cuando ha salido bj. Usando la probabilidad condicional P(ai|bj) obtenemos la entropía a posteriori, o ENTROPÍA CONDICIONAL: H(A|B)=-Suma [P(ai,bj)*Log(P(ai|bj))] -Suma [P(bj)*P(ai|bj)*Log(P(ai|bj))] donde sumamos para todos los valores de i,j. H(A|B) nos viene a dar idea de cuán incierta es la información que tenemos sobre A cuando conocemos B. En el caso que hemos puesto como ejemplo, A,B son respectivamente la entrada y la salida de información por un canal de comunicaciones. Esto tiene, evidentemente, mucha importancia para los expertos en teleco, donde han de bregar con problemas de ancho de banda, ruido, corrección de errores, etc. Pero por apasionante que pudiera ser el tema (y que nos daría para muchos boletines), volvamos a nuestro interés criptográfico. Podemos interpretar A como el texto llano, B como el texto cifrado y el "canal" como el sistema de cifra. Es decir, ai serían los posibles textos llanos y bj los textos cifrados. Si el sistema de cifrado fuese perfecto, no habría forma de "ordeñar" información del mensaje cifrado. No es que no podamos descifrarlo, es que ni siquiera podríamos determinar si algunos mensajes en llano son más probables que otros. Conocer el texto cifrado hasta el último bit no nos daría la menor pista sobre el texto llano. Pero si el sistema es imperfecto, habrá alguna información oculta en el texto cifrado, como que (por ejemplo) los mensajes en llano que comiencen por vocal son más probables que correspondan con el texto cifrado. Que quede bien claro que aquí no estamos hablando de obtener el texto llano, ya que la cifra no suele ser tan mala, sino de obtener cualquier pista sobre lo que el mensaje puede o no ser. Si podemos concluir que el mensaje no puede tener un número impar de consonantes, eso ya nos sirve. Cualquier bit de información vale. Matemáticamente, usamos la entropía condicional para cuantificar esta información. Recordemos una vez más (y perdonen si sueno demasiado repetido) que la entropía condicional nos mide el conocimiento que tenemos de A cuando conocemos B, esto es, hasta qué punto ver los mensajes cifrados nos da alguna pista acerca de los mensajes llanos. A esta entropía condicional Shannon le dio el descriptivo nombre de EQUIVOCACIÓN. Recordemos la expresión: H(A,B)<=H(A)+H(B) Puede demostrarse que la entropía H(A,B) también puede ponerse de la siguiente forma: H(A,B)=H(B)+H(A|B) Lo que significa que podemos obtener esto: H(A)>=H(A|B) Es decir, la incertidumbre que tenemos de conocer A disminuirá si conocemos B, y dicho conocimiento pasa de H(A) (la entropía de los mensajes en llano) a H(A|B) (la entropía de los mensajes en llano condicionado por lo que conocemos de los mensajes cifrados B). O dicho en román paladino: conocer textos cifrados B nos aumenta la información que tenemos de los mensajes en llano A. Esto no sucedería si el cifrado fuese perfecto. Pero si no lo es, si el mensaje en llano está condicionado por el mensaje cifrado, la equivocación H(A|B) nos cuantifica cuánto hemos ganado en información. La idea general es que un símbolo ai de un mensaje en texto llano requiere en promedio H(A) bits para definirlo. Si supiésemos qué símbolo cifrado bj corresponde a dicho símbolo ai, solamente necesitaríamos H(A|B) bits para definirlo. Así que, como media, la observación de un símbolo de salida proporciona H(A)-H(A|B) bits de información. A esta información se le llama INFORMACIÓN MUTUA del sistema: I(A,B)=H(A)-H(A|B) Por supuesto, si el sistema es impenetrable no ganamos nada con conocer B, por lo que H(A|B)=H(A) y la información mutua es nula. Si el sistema es imperfecto, H(A|B)0. Algunos autores, como Manuel Lucena, usan una definición opuesta a la nuestra: I(A,B)=H(B)-H(B|A) pero ambas son válidas, ya que la información mutua es simétrica, esto es, I(A,b)=I(B,A). En cualquier caso, una información cero indica que todas las "traducciones" posibles a texto llano sin igualmente probables, el criptoanalista no gana absolutamente nada si conoce un mensaje cifrado, o un millón, y el cifrador de mensajes puede dormir tranquilo. Muy bien, vayamos un paso más allá. Por lo que hemos visto hasta ahora, cuantos más mensajes cifrados obtengamos, más nos acercaremos al objetivo de "reventar" el mensaje y obtener el texto llano. La pregunta ahora es ¿llegaremos el algún momento al punto en que podemos descifrar el mensaje? Y si es así, ¿cuántos mensajes cifrados necesitaremos husmear? Para eso tendremos que definir más cantidades. Pero si hemos sobrevivido a la entropía condicionada, la equivocación y todo lo demás, esto será pan comido. En primer lugar, definamos la entropía de un sistema de cifra. Es, sencillamente, una medida binaria del tamaño del "espacio de claves". Si un sistema de cifra tiene K posibles claves, su entropía es el logaritmo en base 2 del número de claves: H(K)=Log2(K) lo que nos da un número de posibles claves igual a 2^H(K) Por ejemplo, el sistema de cifra de César tiene 27 posibles claves, de modo que si entropía será de 4.09. Esto significa que hay 2^4.09 posibles claves. Muchas veces, la entropía es igual al número de bits que tienen las claves, pero eso no es siempre así. Por ejemplo, el sistema de cifra DES usa claves de 64 bits, pero ocho de dichos bits están determinados por los otros 56 (son los llamados bits de paridad), de forma que el "espacio de claves" es 2^56 y la entropía del sistema es de 56 bits. Cuanto mayor la entropía, tanto más difícil es reventar el sistema. En un sistema perfecto necesitaríamos probar las 2^H(K) posibles claves. Pero si el texto llano es un mensaje en español, dicho texto será redundante. ¿Recuerdan eso de la redundancia? Pues podemos aprovecharlo, tanto si el idioma del texto llano es español, inglés, ASCII o lo que sea. Podemos, de hecho definir la REDUNDANCIA D como D=R-r, donde R es el número de bits máximo por letra y r es el número real de bits de información que no da un carácter. Como vimos en el ejemplo de la parte II de esta serie, el idioma inglés usa 26 letras, lo que nos da R=Log2(26)=4.7 bits por letra de promedio; la cantidad de información real de una letra en el lenguaje inglés es, según diversas estimaciones, de entre 1 y 1.5 bits de información. Tomando un valor razonable de r=1.3, esto nos da una redundancia D=3.4. Es decir, de cada 100 bits de información en un texto inglés, el 72% es redundante. Asociado al concepto de redundancia está el de DISTANCIA DE UNICIDAD (U). Este bicho es la cantidad de texto cifrado tal que la suma de la entropía real del texto llano, más la entropía de la clave de cifrado, es igual al número de bits de texto cifrado usado. Vale, no os asustéis. Lo diré de otro modo. Si la entropía del criptosistema es H(K) y la redundancia del lenguaje es D, la distancia de unicidad es: U=H(K)/D En realidad, sólo sería válido para lo que Shannon denomina "cifra aleatoria", pero obviaremos ese pequeño detalle ya que incluso para cifras no aleatorias la ecuación anterior nos da una cota inferior. En general, cuanto más texto cifrado tenemos, tanto más nos acercamos al objetivo de descifrar del mensaje. El problema es que, para un mensaje corto, hay muchas posibles soluciones. Si yo las pruebo todas, usando todas las claves posibles, ¿cómo sé cuál es el descifrado correcto? Bien, se puede demostrar que cuando el mensaje es de longitud menor que la distancia de unicidad, hay múltiples soluciones posibles. Por el contrario, si tenemos un cantidad de texto cifrado igual o superior a la distancia de unicidad, tenemos la garantía de un descifrado único. Eso no significa, ojo, que la cifra es atacable por métodos criptoanalíticos; pero si lo es, necesitaremos al menos una cantidad de texto cifrado igual a U. Es decir, U es un límite teórico para un criptoanalista al que supondremos con una provisión prácticamente ilimitada de tiempo, ordenadores y paciencia. Cuanto mayor sea U, mejor el sistema de cifra. En el caso límite, un sistema con redundancia D cero tendría una distancia de unicidad infinita; es decir, un atacante no podría sacar nada en claro de un mensaje cifrado, sea cual fuese su longitud. Es curioso considerar que incluso un sistema de cifrado imperfecto, con claves cortas y al que no nos dignaríamos de saludar por la calle puede resultar indescifrable si la redundancia D es cero. Volvamos a nuestra clave de César. Si yo escribo un texto en español y lo cifro, no será difícil para un criptoanalista tomar todas las posibles claves y escoger de entre todos los textos descifrados el correcto. Pero supongamos que yo tomo un texto totalmente aleatorio, digamos AODTWNSSXYZ, y lo cifro con una cifra de César. Eso no es español, ni inglés, ni klingon, sino un batiburrillo totalmente aleatorio. La redundancia del "idioma" usado por el mensaje es cero, así que la distancia de unicidad es infinita. El criptoanalista podrá tomar mi mensaje, probar todos los descifrados posibles, y aún así no tendrá idee de cuál es el texto correcto. En general, comprimir el mensaje reduce ya redundancia. Por eso es mejor usar compresión (zip, rar, la que más nos guste) antes de cifrar el mensaje: no solamente el tamaño del texto será menor, sino que le damos menos información al enemigo. Y también hay otra cosa que podemos hacer: usar un sistema de cifra en el que la entropía sea igual al tamaño en bits de la clave. Si un criptosistema tiene claves de 1000 bits de longitud, pero su entropía es de tan sólo 100, es como si las otras 900 claves estuviesen de adorno. Demasiados sistemas de cifra se anuncian como estupendos y maravillosos porque tienen claves de gran longitud. Pero lo importante no es el número de claves teóricas, sino la longitud del "espacio de claves" real, es decir, la entropía del criptosistema. Veamos algunos ejemplos de distancias de unicidad. C.A. Deavours publicó algunos en Cryptologia (Enero 1977), suponiendo un idioma inglés con una redundancia D=1.11. Para una cifra Vigenère con una clave de longitud P, la distancia de unicidad es de 1.27P. Es decir, usando como clave "boletinenigma", bastan 1.27*5=17 letras para, al menos en teoría, montar un ataque criptoanalítico con éxito ... a no ser que la usemos para transmitir mensajes de longitud muy pequeña. Si en lugar de Vigenère (que no es más que una sucesión de P cifras de César) usásemos una sustitución polialfabética con N alfabetos diferentes usados en sucesión, obtendríamos U=23.97N+1.27P. Es decir, usar 10 alfabetos y la misma clave de antes requeriría interceptar al menos 23.97*10+1.27*5=246 caracteres cifrados. La clave es de igual longitud que antes, pero el sistema es mucho más difícil de resolver. No quiero aburrirles, pero ahí van otros ejemplos. La cifra Playfair (de la que hablaremos un día de estos) tiene una distancia de unicidad de U=22.69. Una sustitución digráfica aleatoria (es decir, cifrar letras en grupos de dos) tiene U=1461. Una cifra de sustitución homofónica con N posibles signos cifrados por letra nos da una distancia de unicidad de 33.14N. Como el lector ha podido ver a lo largo de esta serie de artículos, las contribuciones de Claude Shannon a la criptología matemática son profundas. Sus dos artículos más conocidos (y que hemos usado aquí para documentación fueron escritos en 1948 ("A mathematical theory of communication") y 1949 ("Communication theory of secrecy systems") en la revista "Bell System Technical Journal" El segundo de ellos, casualmente el que trata de aplicaciones criptográficas, ha estado ausente de la Red durante mucho tiempo, salvo en forma de imágenes jpg difíciles de manejar. Felizmente, Jiejun Kong decidió resolver esta injusticia, y ahora el segundo artículo está disponible en un cómodo pdf. Ni que decir quiere que los fieles del Taller de Criptografía podrán encontrarlos allí para su disfrute: http://www.cripto.es/museo/shannon1948.pdf http://www.cripto.es/museo/shannon1949.pdf <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><> LIBERTAD VIGILADA <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><> =----------------------------------------------------------------------= España autoriza el uso de Rota "caso por caso" - ----------------------------------------------------------------------= [Extraído del libro "Libertad Vigilada", de Nacho García Mostazo, con permiso del autor] Segunda parte, capítulo 8: Como hemos visto, no cabe duda de que el Grupo de Seguridad Naval de la base de Rota lleva a cabo operaciones de espionaje de las comunicaciones desde mediados de los años 60. En esa fecha, las bases militares estadounidenses en España eran aún de su entera propiedad, pero, tras la firma del Convenio hispano-norteamericano de "Amistad y Cooperación" de 1970, pasaron a ser del Estado español, que autorizaba a Estados Unidos el uso de ciertas facilidades en ellas. En 1982, con España ya en la OTAN, se firmó el nuevo Convenio, que regulaba el uso de las instalaciones y de las autorizaciones que se conceden a las Fuerzas Armadas de EE.UU. Así pues, toda actividad que lleve a cabo el Ejército norteamericano en las bases españolas ha de estar autorizada por el Estado español. De todo ello se desprende que España ha dado permiso a los estadounidenses para que utilicen sus instalaciones con fines de espionaje. El propio Gobierno español lo reconoció oficialmente el 10 de marzo de 1999, durante la comparecencia del entonces ministro de Defensa, Eduardo Serra Rexach, ante la Comisión de Defensa del Congreso de los Diputados. El ministro respondía a una serie de cuestiones sobre la petición del Gobierno estadounidense para iniciar unas obras de ampliación y mejora de las instalaciones de Rota, pero el Grupo Parlamentario de Izquierda Unida también hizo una pregunta sobre el papel que juega la base en relación a la guerra electrónica. Según el Diario de Sesiones del Congreso, Serra respondió a dicha cuestión afirmando que "entre las instalaciones de apoyo con que cuentan las fuerzas de Estados Unidos en la base naval de Rota [...] están una instalación naval de comunicaciones y uns instalación para información y vigilancia oceánica de la flota, tal y como viene recogido en el anejo 2 del Convenio de Cooperación para la Defensa. Estas instalaciones - -continuó el ministro- son de uso norteamericano y están bajo la responsabilidad del jefe de las fuerzas de Estados Unidos en la base naval de Rota". [1] Según dijo Serra, el citado Convenio también especifica que "las fuerzas de EE.UU. [...] utilizan y mantienen esas instalaciones de apoyo con el objeto de posibilitar las comunicaciones precisas para el funcionamiento operativo y administrativo de sus fuerzas navales, el enlace con la red de telecomunicaciones del Departamento de Defensa de Estados Unidos y el acopio y distribución de información en apoyo a la flota. Asimismo, las fuerzas de Ee.UU. están autorizadas a la utilización de códigos, sistemas criptográficos y otros medios de seguridad". Para concluir su intervención, el ministro afirmó que lo que se hace en Rota es "recopilar y distribuir la información que necesita la Marina de Estados Unidos para sus operaciones, algo que evidentemente no tiene nada que ver con la guerra electrónica. Pero es que, además, de acuerdo con el artículo 18 del Convenio, la información, que es de carácter puramente militar, que sea de interés para España y que se obtenga en las instalaciones de apoyo, es compartida entre ambos países, e incluso el personal español puede participar conjuntamente con el norteamericano en dichas instalaciones cuando las autoridades españolas lo consideren conveniente". En el turno de réplica, Willy Meyer, entonces diputado de Izquierda Unida y miembro de la Comisión de Defensa del Congreso, afirmó dirigiéndose al ministro que "a nadie se le escapa [...] que detrás de la expresión 'acopio de información', se esconde, lisa y llanamente, lo que significa el espionaje electrónico". Asimismo, Meyer dijo estar convencido de que la base de Rota está implicada en la red "Echelon" de espionaje global de las comunicaciones. En su respuesta, el ministro dijo que "en la base de Rota hay unas instalaciones de comunicación y, como Su Señoría sabe, cualquier instalación de comunicaciones permite hacer acopio de información a través de satélite, a través de antenas de radar o a través de teléfono móvil, y una vez evaluada y analizada esa información se puede hacer inteligencia". Eduardo Serra reconocía así que las instalaciones de comunicaciones de Rota sirven, en efecto, para fines de espionaje, contradiciéndose además a sí mismo. Seguidamente, siguió dirigiéndose a Willy Meyer para pedirle que "no polarice Su Señoría en Estados Unidos [...] porque hay no menos de media docena de países en el mundo que tienen capacidad de interceptación de comunicaciones vía satélite". El ministro finalizó su respuesta pidiéndole al diputado en Izquierda Unida que "no mezcle Rota en singular con la capacidad de comunicación de satélites. Cada seis semanas manda un satélite al espacio profundo la NASA, cada seis semanas. Hay miles de satélites en el mundo, hay miles de centrales en el mundo donde se está obteniendo esa información [...] digital, analógica, de datos, de voces, para conocer información de todo tipo, militar, política, económica. Ése es un problema que, cuando menos, me concederá Su Señoría que excede al tratamiento de la base de Rota". La controversia sobre la ampliación de la base hispanonorteamericana continuó dos años después, cuando el Gobierno español autorizó definitivamente las obras al Ejército estadounidense. La Comisión de Defensa del Congreso de los Diputados celebró una nueva reunión para discutir este asunto el 14 de marzo de 2001. Como titular de la cartera de Defensa y sucesor de Eduardo Serra, Federico Trillo-Figueroa contestó a las preguntas de los parlamentarios e, igual que le ocurrió a su antecesor, también se enzarzó en un intenso debate con otro diputado de Izquierda Unida, en este caso José Luis Centella, quien se oponía a las obras afirmando que los ciudadanos no quieren "vender su soberanía y su dignidad" a Estados Unidos. Trillo calificó de "antiguo" el discurso de Centella y le recordó que en Rota ondea la bandera española y que para la utilización de la base se requiere la autorización previa de España "caso por caso". En esta ocasión no se habló sobre el espionaje de las comunicaciones, pero las palabras del ministro sobre las autorizaciones que se dan al Ejército norteamericano, unidas a las que pronunció Eduardo Serra dos años antes, vendrían a confirmar que el Gobierno español está al tanto de las operaciones de espionaje que se llevan a cabo desde Rota. [2] [1]. Diario de Sesiones del Congreso de los Diputados. Comisión de Defensa. Sesión número 36, celebrada el miércoles, 10 de marzo de 1999. VI Legislatura. Número 640. [2]. Agencia EFE. "AMPLIACIÓN ROTA / Trillo defiende ampliación Rota y destaca fuerte inversión en la zona." Teletipo. Madrid, 14 de marzo de 2001. ======================================================================== 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 alta 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 baja 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 2008. ======================================================================== -----BEGIN PGP SIGNATURE----- Version: PGP 6.5i iQA/AwUBSELGtg7Y43Xkw2u9EQLWAACdFuzycdxF3RCgqEwOZA88ScD7pOEAnAle h/A9u5+IR49q9hheqxvv3GCV =NxEH -----END PGP SIGNATURE-----