2000 << Back To criptograma nº 21

_______________________________________________________________ C R I P T O G R A M A _______________________________________________________________ N·mero 21 15 de Enero del 2000 http://www.kriptopolis.com/criptograma/cg0021.html ________________________________________________________________ SUMARIO: 1. Ataques de "B·squeda de Clave" y Ataques Publicitarios 2. Counterpane: investigaci≤n documentada 3. Noticias 4. Nuevas regulaciones sobre cifrado en EE.UU. 5. Noticias desde Counterpane Internet Security 6. En la ratonera: Netscape 7. Algoritmos de cifrado de bloques y de flujo 8. Comentarios de los lectores -- Ejemplar gratuito distribuido a mßs de 16.000 suscriptores -- ________________________________________________________________ * Versi≤n Web de este ejemplar: http://www.kriptopolis.com/criptograma/cg0021.html * Suscripci≤n gratuita: http://www.kriptopolis.com/subs.html * N·meros anteriores: http://www.kriptopolis.com/criptograma/cg.html _______________________________________________________________ 1. Ataques de "B·squeda de Clave" y Ataques Publicitarios --------------------------------------------------------- Por Bruce Schneier Traducci≤n: Juan Cruz Ruiz de Gauna Hace un par de semanas el New York Times inform≤ sobre un nuevo ataque de "b·squeda de clave". Esto fue una continuaci≤n sobre algunas investigaciones discutidas aquφ hace algunos meses, mostrando c≤mo buscar, y localizar, claves criptogrßficas p·blicas y privadas en el software debido a sus patrones de bits aleatorios. La compa±φa nCipher demostr≤ que alguien que tenga acceso a un servidor Web que utilice SSL puede encontrar la clave privada SSL usando estas tΘcnicas y, potencialmente, puede robar dicha clave. La informaci≤n hecha p·blica por nCipher habla de "Una vulnerabilidad significativa a la economφa de Internet de hoy dφa.". ┐Humm? ┐Por quΘ es esto noticia?. No se trata del hecho de que las claves privadas SSL estΘn en el servidor Web. Esto es obvio; tienen que estar allφ. No se trata del hecho de que alguien que tenga acceso al servidor Web pueda, potencialmente, robar las claves privadas. Esto tambiΘn es obvio. La noticia no es que un ataque CGI pueda comprometer los datos del servidor Web. Hemos presenciado docenas de estos ataques durante 1999. Incluso la nota de prensa admite que "no se sabe de ninguna informaci≤n que haya sido comprometida usando un ataque de 'b·squeda de clave'". Ni nCipher ni el New York Times han encontrado a alguien que sea vulnerable. Pero, un momento... nCipher vende una soluci≤n a este "problema". Bien, ahora entiendo. Yo a este tipo de acci≤n lo llamo un ataque publicitario. Es un intento descarado por parte de nCipher para obtener publicidad gratuita para los aceleradores de cifrado por hardware, y para atemorizar a los vendedores de comercio electr≤nico y hacer que compren dichos aceleradores. Y la gente cae en esta trampa una y otra vez. Este tipo de cosas estßn sucediendo cada vez mßs y mßs, y yo estoy empezando a cansarme de esto. Aquφ tenemos algunos ejemplos mßs: * Un empleado de Cryptonomin, empresa vendedora de PKI (Infraestructura de Clave P·blica), anunci≤ que habφa encontrado una variable con el prefijo "NSA" dentro de la API criptogrßfica de Microsoft. Basßndose en una evidencia absolutamente nula, esto fue presentado como un ejemplo de la manipulaci≤n del c≤digo de Microsoft por parte de la NSA. * Alguna gente de eEye descubri≤ un error en IIS el a±o pasado que comprometφa totalmente el producto. Contactaron con Microsoft, y tras esperar tan s≤lo una semana a que se reconociese el problema, hicieron p·blica una nota de prensa y una herramienta hacker. Microsoft sac≤ rßpidamente un parche, pero no tan rßpido como los hackers saltaron sobre el fallo. eEye, por cierto, vende herramientas de comprobaci≤n de vulnerabilidades y consultorφas de seguridad. Soy un fan de las revelaciones totales -y, definitivamente, no soy un fan de la seguridad de Microsoft- y creo que las vulnerabilidades de seguridad deben ser publicadas antes de que sean corregidas. (Si no se hacen p·blicas, los vendedores a menudo no se preocuparφan en corregirlas). Pero esta prßctica de anunciar "vulnerabilidades" con el ·nico prop≤sito de hacer promoci≤n de tus propias soluciones debe detenerse. He aquφ unos ejemplos de c≤mo hacer las cosas bien: * Los investigadores de la Universidad de California Berkeley han roto casi todos los algoritmos de seguridad de telefonφa celular. Ellos no se benefician de estas roturas. No publican paquetes de software que puedan escuchar llamadas de telΘfonos celulares. Esto es investigaci≤n, y de la buena. * Georgi Guninski ha encontrado un gigantesco n·mero de agujeros JavaScript durante el pasado a±o. En lugar de difundir sus temibles haza±as y sacar herramientas de cracking de las que puedan aprovecharse los chicos de los scripts, y en vez de intentar aprovechar la atenci≤n del p·blico, se ha dedicado silenciosamente a publicar los problemas y los estudios disponibles. Por supuesto, el inconveniente es que estos errores han recibido menos atenci≤n por parte de Microsoft y Netscape, incluso sabiendo que son tan serios como muchos otros que han recibido mßs atenci≤n por parte de la prensa y, por tanto, han sido corregidos mßs rßpidamente por parte de los desarrolladores de navegadores. Sin embargo, esto es buena investigaci≤n. * El L0pht ha proporcionado un gran beneficio mostrando problemas de seguridad de Windows NT, y no intentaban vender productos de seguridad que corrigiesen estos problemas. (Aunque ahora que han creado una compa±φa de consultorφa de seguridad financiada con capital de riesgo, @Stake, habrß que andar con mßs cuidado). * "Perfecto" comercializa seguridad contra ataques CGI. Aunque intentan aumentar la concienciaci≤n sobre los riesgos, no se dedican a escribir nuevos ataques CGI y hacerlos p·blicos. Ellos se dirigen a otros ataques CGI, realizados por hackers sin relaci≤n con la compa±φa, como ejemplos del problema. * Steve Bellovin en los laboratorios AT&T encontr≤ un importante agujero en el sistema DNS de Internet. Retras≤ durante a±os la publicaci≤n de esta vulnerabilidad porque a·n no estaba disponible la correcci≤n. ┐C≤mo notar la diferencia? fijßndose en el mensajero. ┐QuiΘn ha encontrado la vulnerabilidad? ┐Cußl ha sido el motivo para hacerla p·blica?. El anuncio de nCipher vino junto con una noticia de negocios de cable, y un agente de relaciones p·blicas vendi≤ la historia a los reporteros. Estas cosas no son gratuitas -la nota de prensa cost≤ unos mil d≤lares- y debiera ser una pista evidente de que hay otros intereses en juego. TambiΘn debemos examinar crφticamente el fallo. ┐Es realmente algo nuevo o se trata de un viejo asunto? ┐Expone una vulnerabilidad importante o una sin importancia? ┐es realmente interesante?. Si es viejo, no tiene importancia y no es interesante, probablemente se trata de un intento de conseguir cobertura publicitaria. Y observemos c≤mo se hace p·blica. La publicaci≤n de nCipher incluφa una herramienta hacker. Tal y como indic≤ el New York Times "De este modo los sitios de e-commerce son mßs vulnerables al ataque y mßs partidarios de comprar los productos de nCipher". Los anuncios que incluyen como parte del paquete herramientas de hacker son mßs parte del problema que parte de la soluci≤n. Soy un firme creyente de la seguridad de c≤digo abierto y de publicar las vulnerabilidades de seguridad. No quiero que la industria de telefonφa celular, o la industria del DVD, coloquen mala seguridad a los consumidores. Creo que la calidad de los productos de seguridad deberφa ser chequeada tanto como la calidad de los autom≤viles. Pero recordemos que la comprobaci≤n de la seguridad es difφcil y lleva mucho tiempo, y que muchos de los "testeadores" tienen otros motivos ocultos. Estos motivos son a menudo tan noticia como la vulnerabilidad en sφ misma y algunas veces los anuncios son debidamente ignorados como publicidad descaradamente auto-servida. Las direcciones URL del NY Times usando su funci≤n de b·squeda cambian diariamente, pero podeis ir a http://search.nytimes.com/plweb-cgi/ y usar la b·squeda extendida; el tφtulo del artφculo es "Los ataques al c≤digo de cifrado aumentan las dudas sobre la vulnerabilidad de los ordenadores". Nota de prensa de NCipher's: http://www.ncipher.com/news/files/press/2000/vulnerable.html Documento oficial de NCipher's (en formato Acrobat): http://www.ncipher.com/products/files/papers/pcsws/pcsws.pdf 2. Counterpane: investigaci≤n documentada ----------------------------------------- Por Bruce Schneier Traducci≤n: Oscar Esteban "Evaluaci≤n criptogrßfica de IPsec" N. Ferguson y B. Schneier, pr≤xima publicaci≤n Realizamos una revisi≤n criptogrßfica del protocolo IPsec, seg·n estß descrito en los RFC de noviembre de 1998. Incluso aunque el protocolo es una decepci≤n -nuestra principal queja es por su complejidad- es el mejor protocolo de seguridad IP disponible por el momento. http://www.counterpane.com/ipsec.html 3. Noticias ------------------------- Por Bruce Schneier Traducci≤n: Oscar Esteban * Es posible votar a travΘs de Internet en las primarias dem≤cratas de Arizona. ┐Alguien mßs que yo opina que esto es escalofriante? http://dailynews.yahoo.com/h/nm/19991217/wr/arizona_election_1.html * Un experto en la central de seguridad informßtica del gobierno britßnico ha empleado soluciones de c≤digo abierto en la arquitectura informßtica mßs segura disponible: http://212.187.198.142/news/1999/50/ns-12266.html * La Asociaci≤n de Control de Copia de DVD ha hecho el ridφculo, y ahora estßn demandando a cualquiera que se ponga a tiro: http://www.cnn.com/1999/TECH/ptech/12/28/dvd.crack/ * La ley de Moore y sus efectos en la criptografφa: http://www.newscientist.com/ns/20000108/newsstory2.html * Guerras informativas en la Era de la Informaci≤n: http://www.cnn.com/1999/TECH/computing/12/30/info.war.idg/index.html http://www.it.fairfax.com.au/industry/19991227/A59706-1999Dec27.html * Piratas en la radio: en el Reino Unido, algunas radios pueden recibir una se±al digital que les hace cambiar automßticamente a emisoras que estΘn emitiendo informes de trßfico. Unos hackers han descubierto c≤mo generar esa se±al, forzando a la radio a sintonizar siempre una emisora determinada. Buena ilustraci≤n de las vulnerabilidades ocultas en los sistemas digitales. http://news.bbc.co.uk/hi/english/sci/tech/newsid_592000/592972.stm http://uk.news.yahoo.com/000106/18/d6jt.html * Bien, esto seguro que no es muy exacto: http://www.lancrypto.com/algorithms_e.htm * Hace ya meses mencionΘ el aviso sobre el a±o 2000 de Hart Scientific. Ahora tienen una continuaci≤n: http://www.hartscientific.com/y2k-2.htm * Software de "cßmara acorazada digital" RSA: http://news.excite.com/news/pr/000111/ma-rsa-keon-software * Fallo de cifrado en comercio electr≤nico; un buen ejemplo de por quΘ la gente es el peor problema de seguridad. Un programador simplemente olvid≤ reactivar el cifrado. http://news.excite.com/news/r/000107/17/news-news-airlines-northwest * Consiga al instante un portal criptogrßfico. Encryption.com, encryption2000.com, y 1-800-ENCRYPT estßn en venta. http://news.excite.com/news/bw/000111/wa-azalea-software http://www.encryption.com * Utilidad de cifrado de correo que le permite recuperar mensajes que se arrepienta de haber enviado. ┐Alguien piensa que esto es seguro? http://www.zdnet.com:80/anchordesk/story/story_4323.html *Implantes humanos de GPS: http://www.newscientist.com/ns/20000108/newsstory8.html * Becas para hackers de Clinton: http://chronicle.com/free/2000/01/2000011001t.htm * Microsoft estß incluyendo una VPN (red privada virtual) en Windows 2000. ┐QuΘ t·nel quieres hackear hoy? http://www.networkworld.com/news/2000/0110vpn.html * Alguien rob≤ un pu±ado de n·meros de tarjeta de crΘdito de CD Universe, intent≤ el chantaje, e hizo p·blicos algunos: http://www.wired.com/news/technology/0,1282,33563,00.html http://www.msnbc.com/news/355593.asp y la reacci≤n de Cybercash (con una simpßtica menci≤n acerca de hasta quΘ punto es invulnerable la seguridad de su producto; una forma de mover el trapo rojo para atraer hackers): http://www.internetnews.com/ec-news/article/0,1087,4_279541,00.html * Un interesante artφculo de tres partes sobre la videovigilancia y su efecto en la sociedad: http://www.villagevoice.com/issues/9840/boal.shtml * El sistema empleado para financiar una serie de anuncios contra Bush se parece ligeramente a mi "protocolo del artista callejero", empleando la compa±φa de tarjetas de crΘdito en lugar de un editor como tercero de confianza. Validan tu tarjeta cuando haces la oferta, pero s≤lo efect·an cargo si consiguen suficiente para un anuncio: http://www.gwbush.com/ Protocolo del artista callejero: http://www.counterpane.com/street_performer.html * Se puede montar gratis en metro en la ciudad de Nueva York doblando la Metrocard exactamente en el lugar adecuado. The Village Voice y NY Times han publicado historias al respecto, pero ya no estßn disponibles, al menos gratuitamente. Aquφ hay una copia de la historia del NY Times: http://www.monkey.org/geeks/archive/9801/msg00052.html El fichero RealAudio de 2600 "Off the Hook" del 3 de febrero de 1998 habla sobre ello, empezando alrededor de 54:35. Hay un enlace al RealAudio desde aquφ: http://www.2600.com/offthehook/1998/0298.html * La Casa Blanca lanza un plan nacional para proteger los sistemas informßticos norteamericanos de intrusiones no autorizadas. Este plan incluye el establecimiento de la controvertida Red Federal de Detecci≤n de intrusiones (FIDNET : Federal Intrusion Detection Network), que monitorizarφa la actividad en los sistemas informßticos del gobierno (hasta ahora no hay planes para monitorizar sistemas comerciales, pero esto podrφa cambiar. El gobierno quiere implicar a la industria en esto). El plan tambiΘn habla del establecimiento de un "Instituto para la Protecci≤n de la Infraestructura de la Informaci≤n" y un nuevo programa que ofrecerß becas a estudiantes en el campo de seguridad informßtica a cambio de compromisos de servicio p·blico. El programa de becas parece una buena idea; necesitamos mßs expertos en seguridad informßtica. http://www.thestandard.com/article/display/0,1151,8661,00.html http://dailynews.yahoo.com/h/ap/20000107/ts/clinton_cyber_terrorism_4.html http://news.excite.com/news/ap/000107/01/tech-clinton-cyber-terrorism http://www.msnbc.com/news/355783.asp http://www.computerworld.com/home/print.nsf/all/000107DB3A Anßlisis EPIC: http://www.epic.org/security/CIP/ Plan de la Casa Blanca (PDF): http://www.whitehouse.gov/WH/EOP/NSC/html/documents/npisp-execsummary-000105.pdf Nota de prensa de la Casa Blanca: http://www.epic.org/security/CIP/WH_pr_1_7_00.html Resumen de prensa de la Casa Blanca: http://www.epic.org/security/CIP/WH_briefing_1_7_00.html 4. Nuevas regulaciones sobre cifrado en EE.UU. ---------------------------------------------- Por Bruce Schneier Traducci≤n: David G≤mez Tenemos unas cuantas, y son una gran mejora. En el lado positivo, los productos de cifrado a la venta -como navegadores, programas de e-mail, o PGP- serßn ampliamente exportables a casi todos los paises "sin importar la longitud de la clave o el algoritmo". En el lado negativo, las nuevas regulaciones son complejas (una inacabable fuente de trabajo para los abogados) y todavφa harß difφcil para mucha gente el intercambio libre de productos de cifrado. Tampoco mencionan los asuntos constitucionales sobre la libre expresi≤n planteados los controles de exportaci≤n al cifrado. Principales detalles de las nuevas regulaciones: * Los productos de cifrado a la venta van a ser exportables, sin importar la longitud de la clave o el algoritmo, a todos menos a los paises terroristas "T-7". Para poder exportar es necesario rellenar cierto papeleo. Se necesitarß una clasificaci≤n de vendedor, enviar el producto a una revisi≤n tecnica ·nica, y entregar informes peri≤dicos sobre quΘ productos son entregados y a quiΘn (pero no necesariamente informar de los usuarios finales). * La exportaci≤n de productos de cifrado con claves de hasta 64 bits de longitud estß completamente liberalizada. * Los productos que no estΘn a la venta requerirßn una licencia para muchas exportaciones, como aquellos para gobiernos extranjeros o ISPs extranjeros y compa±φas de telecomunicaciones bajo ciertas circustancias. * El c≤digo fuente que "no estß sujeto a un acuerdo expreso para el pago de una licencia o derechos de autor para la producci≤n comercial o venta de cualquier producto desarrollado con el c≤digo fuente" es libremente exportable a todos, excepto a los paises terroristas T-7. Los exportadores del c≤digo fuente deben enviar al Departamento de Comercio una copia del c≤digo, o una URL, a la vez que se publique. Destacar que el envφo de c≤digo a un sitio web para bajßrselo de forma an≤nima esta permitido; no se requiere la comprobaci≤n de que uno de los que se bajan el c≤digo pueda ser de uno de los paises prohibidos. Una pregunta obvia es: "┐c≤mo afecta esto al caso Bernstein y Karn que estß en los tribunales?. No lo sΘ todavφa. No se hace referencia al tema de la libertad de expresi≤n, pero lo que Bernstein y Karn querφan hacer no estß permitido. Tendremos que ver que piensan los fiscales. Una pregunta mas personal es: "┐c≤mo afecta esto a los discos del c≤digo fuente de "Applied Cryptography"?" Tal como lo entiendo, todo lo que tengo que hacer es avisar a la gente adecuada y podrΘ exportarlos. Lo harΘ tan pronto como pueda. Permaneced en sintonφa. Las regulaciones actuales (lenguaje legal): http://www.eff.com/pub/Privacy/ITAR_export/ 2000_export_policy/20000112_cryptoexport_regs.html Articulo de prensa de EFF: http://www.eff.com/11300_crypto_release.html Historia de Reuters con las reacciones de la BSA y Sun: http://news.excite.com/news/r/000112/19/tech-tech-encryption Historia de Reuters con la reacci≤n de EFF: http://news.excite.com/news/r/000113/13/tech-tech-encryption Articulo de prensa de la reacci≤n de AEA: http://news.excite.com/news/pr/000112/dc-aea-encryption-reg Reacciones de ACLU y EPIC : http://news.excite.com/news/zd/000113/18/crypto-compromise-a 5. Noticias desde Counterpane Internet Security ----------------------------------------------- Por Bruce Schneier Traducci≤n: David G≤mez Bruce Schneier retratado en Business Week: http://businessweek.com/cgi-bin/ebiz/ebiz_frame.pl?url=/ebiz/9912/em1229.htm Bruce Schneier hablarß en BlackHat en Singapur, 3-4 de Abril del 2000. TambiΘn estarß en BlackHat y DefCon en Las Vegas. http://www.blackhat.org http://www.defcon.org Bruce Schneier hablarß en la Conferencia de RSA en San Jose: Martes, 18 de Enero, 2:00 PM, sobre el Camino del Analista. No se si estß incluido en el programa, pero Bruce estarß en el escenario con Matt Blaze, Steve Bellovin, y varias otras personas realmente inteligentes. 6. En la ratonera: Netscape --------------------------- Por Bruce Schneier Traducci≤n: David G≤mez Netscape cifra las contrase±as de correo electr≤nico de los usuarios con un pΘsimo algoritmo. Por si esto no fuera suficiente, sus comentarios a la prensa garantizan su inclusi≤n en la ratonera: "Chris Saito, el director general para la gesti≤n del producto en Netscape, dijo que la opci≤n de almacenar una contrase±a localmente fue incluida por comodidad. Saito a±adi≤ que Netscape no us≤ un algoritmo de cifrado mßs fuerte para proteger contrase±as para que 'los expertos en ordenadores pudieran todavφa acceder a la informaci≤n, en el caso de que alguien olvidase su contrase±a.'" En otras palabras, implementaron una pΘsima seguridad a prop≤sito. "Saito de Netscape dijo que la compa±φa no estaba al tanto de la vulnerabilidad y a±adi≤ que una 'reparaci≤n de seguridad' estarφa lista si se prueba la existencia de esa vulnerabilidad. Si la vulnerabilidad de Javascript no existe, un ladr≤n de contrase±as tendrφa que tener acceso fφsico al ordenador del usuario para averiguar el algoritmo." ObservΘse la total ignorancia de virus como Melissa, o troyanos como Back Orifice. "Saito destac≤ que Netscape ya tiene numerosas caracterφsticas de seguridad, incluyendo la capa de sockets seguros (SSL), que permite a los usuarios la comunicaci≤n segura con los servidores Web, y un protocolo para cifrar los mensajes de e-mail enviados." Nada de esto importa si la contrase±a es robada. http://www.zdnet.com/zdnn/stories/news/0,4586,2409537,00.html Informaci≤n de RST: http://www.rstcorp.com/news/bad-crypto.html http://www.rstcorp.com/news/bad-crypto-tech.html 7. Algoritmos de cifrado de bloques y de flujo ---------------------------------------------- Por Bruce Schneier Traducci≤n: JosΘ Manuel G≤mez Los algoritmos de cifrado de bloque y de flujo tansforman un mensaje de texto en claro a texto cifrado un trozo cada vez. Los de bloque aplican idΘntica transformaci≤n a cada trozo del mensaje y generalmente trabajan sobre trozos de mensaje bastante grandes (8 bytes, 16 bytes) de una vez. Los de flujo aplican una transformaci≤n distinta a cada trozo del mensaje, y generalmente trabajan sobre trozos peque±os (1 bit, 1 byte) cada vez. Tradicionalmente han constituido ßreas separadas de investigaci≤n, pero hoy en dφa estßn convergiendo. Y si uno se fija un poco, se verß que no son distintos en absoluto. Vamos con el cifrado de flujo primero. Los algoritmos de flujo tradicionales consisten en tres partes estßndar: un estado interno, una funci≤n avanzar-estado y una funci≤n de transformaci≤n de texto en claro a texto cifrado. El estado interno es generalmente peque±o (sobre unos cientos de bits) y puede ser imaginado como una clave. La funci≤n avanzar-estado actualiza el estado. La funci≤n de transformaci≤n toma un trozo de texto en claro, lo mezcla con el estado actual y produce texto cifrado de igual tama±o. A continuaci≤n, el algoritmo de flujo pasa al siguiente trozo. La seguridad de este esquema esta basada en lo engorrosas que resultan -criptogrßficamente- ambas funciones. A veces s≤lo una es engorrosa. En los algoritmos electr≤nicos de flujo, una complicada funci≤n avanzar-estado se combina habitualmente con una transformaci≤n sencilla, que toma el bit de orden mßs bajo del estado y lo somete a un XOR con el texto en claro. En las mßquinas de rotor, como la alemana Enigma, la funci≤n avanzar-estado era un simple paso por varios rotores y la funci≤n de transformaci≤n era muy complicada. A veces ambos son criptogrßficamente complicadas. Estos algoritmos de cifrado generalmente trabajan en dos modos, dependiendo de la entrada de la funci≤n avanzar-estado. Si la ·nica entrada era el estado actual, se les llamaba algoritmos OFB (output-feedback). Si exisitφa una entrada adicional del bit de texto cifrado anterior, se les llamaba CFB (cipher-feebback). (Los militares de EE.UU. los conocφan como KAK (key-auto-key) y CTAK (ciphertext-auto-key) respectivamente). Se prefiere un modo al otro en funci≤n de la propagaci≤n de errores y las propiedades de resincronizaci≤n. ("Applied Cryptography" explica todo esto con detalle). Tradicionalmente, los algoritmos de flujo eran tan simples como resultaba posible. Se implementaban en hardware y necesitaban el menor n·mero posible de puertas. Tenφan que ser rßpidos. El resultado eran muchos dise±os basados en funciones matemßticas sencillas: por ejemplo, LFSRs (linear feedback shift registers). Se analizaban en base a medidas como la complejidad lineal y la inmunidad de correlaciones. Los analistas observaban las longitudes de ciclo y ajustaban las aproximaciones, La mayorφa de los algoritmos de cifrado militares de los EE.UU., al menos los utilizados hasta los a±os 80, son algoritmos de flujo de este tipo. Los algoritmos de bloque son diferentes. Consisten en una funci≤n sencilla que toma un bloque de texto en claro (un tama±o de 64-bit es lo habitual) y una clave, y produce un bloque de texto cifrado. La NSA los denomina libros de c≤digo (codebooks), lo que constituye una excelente forma de pensar en ellos. Por cada clave puede imaginarse que se contruye una tabla. En la columna de la izquierda se coloca cualquier posible bloque de texto en claro; en la columna de la derecha, cualquier posible bloque de texto cifrado. Eso constituye el libro de c≤digos. Serφa un libro grande (18 mil millones de entradas para los algoritmos mßs peque±os habitualmente usados) por lo que es mßs sencillo implementar el algoritmo matemßticamente, sobre todo porque se necesita un nuevo libro para cada clave. Pero en teorφa, podrφa implementarse como una simple tabla en un libro de c≤digos bastante grande. Los cifrados en bloque pieden ser utilizados simplemente como libros de c≤digos, cifrando por separado cada bloque de 64 bit y, de hecho, esto se denomina ECB (electronic codebook), pero existen un mont≤n de problemas de seguridad. Una atacante puede reordenar los bloques, construir una porci≤n del libro de c≤digos si dispone de alg·n texto en claro conocido, etc. Por tanto, los algoritmos en bloque son implementados encadenados de alguna forma. Antes de enumerar los modos de encadenar algoritmos de bloques, merece la pena destacar que un algoritmo de bloques puede servir como alguna de las funciones necesarias para construir un algoritmo de flujo: la funci≤n avanzar-estado o la funci≤n de salida. Y, de hecho, en eso consisten los modos de cifrado en bloques: cifrados de flujo construidos utilizando algoritmos de bloques como primitiva. Un algoritmo de bloques en modo OFB es lo mismo, con la adici≤n del texto cifrado que se suministra a la funci≤n avanzar-estado. Un cifrado en bloques en modo contador utiliza el cifrado en bloques como la funci≤n de salida y un simple contador como la funci≤n avanzar-estado. El CBC (cipher block chaining) es otro modo de cifrado en bloque; he visto que la NSa lo denomina modo "libro de c≤digo dirigido por cifrado". Aquφ el cifrado de bloque forma parte de la funci≤n que transforma el texto en claro en texto cifrado, y la funci≤n avanzar-estado es sencilla. Por alguna raz≤n que no puedo explicar, durante muchos a±os la investigaci≤n acadΘmica sobre cifrado de bloques fue mßs prßctica que la de cifrados de flujo. Habφa mßs propuestas de algoritmos concretos, mßs anßlisis y mßs implementaciones. Mientras la investigaci≤n en algoritmos de flujo permanecφa en un plano mßs te≤rico, los algoritmos de bloque se empleaban en productos de seguridad (Asumo que era lo contrario que en el campo militar, donde los algoritmos de flujo eran utilizados en productos y constituφan el objetivo de recursos de criptoanßlisis operacional). El refrendo oficial de DES como un estßndar ayud≤ a esto, pero antes de DES estaba Lucifer. Y despuΘs de DES estaban FEAL, Khufu y Khafre, IDEA, Blowfish, CAST y muchos mßs. Recientemente, los algoritmos de flujo han experimentado una especie de renacimiento. Estos nuevos algoritmos de flujo fueron dise±ados para computadores y no para hardware discreto. En lugar de producir la salida de bit en bit, la salida era de byte en byte (como RC4), o 32 bits cada vez (como SEAL o WAKE). Y ya no fueron restringidos nunca mßs por un estado interno peque±o (RC4 toma una clave y la convierte en un estado interno de 256 bytes; el estado interno de SEAL es incluso mayor) o estrechas restricciones de complejidad debidas al hardware. Los algoritmos de flujo, que solφan ser matemßticos y ligeros, comenzaron a parecer tan pesados como los de bloques. Y empezaron a aparecer en productos tambiΘn. Por tanto, los algoritmos de bloques y de flujo son bßsicamente lo mismo; la diferencia radica mßs bien en un accidente hist≤rico. Se puede usar un algoritmo de bloques como algoritmo de flujo, y cualquier algoritmo de flujo puede convertirse en uno de bloques. El modo de utilizaci≤n depende mucho del medio de comunicaci≤n (OFB o CBC tienen mßs sentido para comunicaciones ntre ordenadores con detecci≤n de errores separada, mientras CFB funcionaba francamente bien para transmisiones por radio) y el algoritmo que se elija depende principalmente de rendimiento, estandarizaci≤n y popularidad. Hay incluso algo de confusi≤n en torno a los modernos algoritmos. SEAL, un algoritmo de flujo, se parece mucho a un algoritmo de bloque en modo OFB. Skipjack, un algorirmo de bloques dise±ado por la NSA, se parece mucho a un algoritmo de flujo. Algunos algoritmos nuevos pueden ser utilizados tanto en bloques como en flujo. Pero los algoritmos de flujo deberφan ser mßs rßpidos que los de bloques. Actualmente los algoritmos de bloques mßs rßpidos cifran datos a 18 ciclos de reloj por byte (me refiero a Twofish, el candidato AES mßs rßpido). Los algoritmos de flujo mßs rßpidos son a·n mßs veloces: RC4 a 9 ciclos de reloj por byte y SEAL a 4. (estoy usando una arquitectura de 32 bits a efectos de comparaci≤n; el rendimiento real podrφa variar algo). No creo que esto sea casualidad. Los algoritmos de flujo pueden tener un estado interno grande que varφe para cada salida, pero los de bloque tienen que permanecer fijos. RC4 tiene una gran tabla (puede pensarse en ella como una caja-S) que cambia cada vez que se produce una salida. La mayorφa de los cifrados de bloques tienen tambiΘn alg·n tipo de caja-S, pero permanece constante para cada cifrado con la misma clave. No hay raz≤n por la que no se pueda tomar un algoritmo de bloques (Blowfish, por ejemplo) y modificarlo para que las cajas-S se modifiquen a sφ mismas con cada salida. Si se estß empleando el algoritmo en modo OFB, a·n cifrarß y descifrarß adecuadamente. Pero serß mucho mßs difφcil de romper por dos razones. Una, el estado interno es un objetivo cambiante y es mßs difφcil para un atacante construir un modelo que imite lo que estß pasando dentro del estado. Dos, si la transformaci≤n de texto en claro a texto cifrado estß bien construida, los ataques basados en texto en claro escogido o texto cifrado escogido son imposibles. Y si es mucho mßs difφcil romper un cifrado que se automodifica, entonces podrßn emplearse menos vueltas o menos complejidad o algo. Considero que hay un factor de 10 en cuanto a la diferencia de velocidad de un buen algoritmo de bloques y un buen algorirmo de flujo. Dise±ar algoritmos es muy difφcil y no sugiero a nadie salir por ahφ y modificar cada algoritmo de bloques que se encuentren. Seguramente vamos a seguir utilizando algoritmos de bloque en modos de flujo porque es lo que hemos venido haciendo y el AES nos darß un nuevo estßndar en ese sentido. Pero mayor investigaci≤n en los algoritmos de flujo y formas de sacar partido a sus propiedades intrφnsecas seguramente producirßn familias de algoritmos con incluso mejores prestaciones. 8. Comentarios de los lectores ------------------------------ Por Bruce Schneier Traducci≤n: Isidre Marques Serret, Miguel Camacho y JosΘ Manuel G≤mez. De: Markus Kuhn Tema: Rotura de la Tarjeta inteligente alemana. ________________________________________________ La nota titulada "Hackers alemanes consiguen romper el chip de firma digital de Siemens" en el CRIPTOGRAMA del 15-12-1999 estß equivocada. He estado en contacto con el hacker alemßn (Christian Kahlo) que esta detrßs de esta historia. ╔l descubri≤ que un usuario de la serie de chips SLE44 de Siemens habφa incluido en su ROM de software una rutina que le permitφa cargar en el chip y ejecutar no tan s≤lo c≤digo del interprete interno, sino tambiΘn instrucciones de c≤digo mßquina 8052. Usando esta facilidad indocumentada, Christian carg≤ un diminuto programa en c≤digo mßquina que descarg≤ la ROM completa de la tarjeta. La ROM fue investigada, publicada en USENET como un listado documentado de c≤digo mßquina en formato TeX y no se encontr≤ ninguna vulnerabilidad. Christian tambiΘn descubri≤ en la ROM que los chips de la serie SLE muestran el tipo del chip y su n·mero de serie cuando la lφnea de I/O se mantiene a bajo nivel durante un flanco de reset positivo y los siguiente 600-700 ciclos de reloj, cosa que es absolutamente normal (comparable al mensaje de arranque de la BIOS de un PC) y estß totalmente documentado en las hojas de los datos de la serie SLE44 y no tiene ninguna importancia en cuanto a seguridad se refiere. Ni se rompi≤ de esta manera ninguna aplicaci≤n de la tarjeta inteligente, ni se encontr≤ ninguna vulnerabilidad en ninguna aplicaci≤n de la tarjeta inteligente, y definitivamente no se comprometi≤ ninguna clave privada. Todo esto tampoco tiene nada que ver con firmas digitales. Cualquier noticia en sentido contrario es el resultado de equivocaciones por parte de periodistas que como de costumbre rellenan los huecos de la historia con su limitado conocimiento del trasfondo tΘcnico e intentan escribir la noticia de forma que sea mßs espectacular que la realidad que hay detrßs de ella. La ·nica polφtica que se ha violado aquφ es la de Siemens, que como la mayorφa de los otros fabricantes de chips de la tarjetas inteligentes, intenta asegurarse de que nadie excepto los grandes clientes puede acceder fßcilmente a herramientas de desarrollo para las tarjetas inteligentes que permitan la carga directa de c≤digo mßquina, cosa quΘ podrφa, por otra parte, acortar ligeramente la curva de aprendizaje para un asaltante del chip. Al parecer se exige a los usuarios del chips de Siemens que necesiten cargar c≤digo mßquina que usen un intΘrprete de c≤digo interno en su lugar. Esta polφtica parece haber sido ignorada en secreto por un cliente de Siemens que coloc≤ en su c≤digo en intΘrprete una puerta trasera para habilitar la carga posterior de rutinas criptogrßficas de gran velocidad que no pueden programarse de una forma suficientemente eficaz en el c≤digo interno. Christian descubri≤ esto, aunque decidi≤ *NO* hacer p·blicos los detalles de c≤mo lo hizo ni el nombre del cliente de Siemens en cuyas tarjetas lo habφa descubierto. Todos lo que Θl public≤ era un volcado del c≤digo de la ROM estßndar de los chips de la serie SLE44 de Siemens (CMS = Chip Management Sistem, Sistema de Control del Chip, comparable a la BIOS de un PC), un fragmento de c≤digo que ya era conocido semi-p·blicamente desde hace muchos a±os en la comunidad hacker de la televisi≤n de pago, a travΘs de ataques con Θxito contra los chips de la serie SLE44. La principal contribuci≤n de Christian es que Θl ha descubierto un buen equipo de desarrollo a nivel de c≤digo mßquina muy bueno para algunas de las tarjetas inteligentes de la serie SLE, que costaba una fortuna y exigφa firmar un NDA (Non Disclosure Agreement, Acuerdo de No Publicaci≤n). Esta no es la primera vez que ha pasado esto: las tarjetas inteligentes de la televisi≤n de pago se han distribuido antes con software que permite la carga de parches en su EEPROM mediante tΘcnicas de autenticaci≤n muy dΘbiles, lo cual era conocido y usado entre la gente que ômodificaö tarjetas inteligentes de la televisi≤n de pago desde hace muchos a±os. De: an≤nimo Tema: Re: Nuevas Regulaciones U.S.A. para la Exportaci≤n de Criptografφa. __________________________________________ En el CRIPTOGRAMA del 15 de diciembre de 1999 usted escribi≤ sobre la nueva propuesta americana de regulaciones de exportaci≤n de criptografφa, y yo estoy de acuerdo con todo lo que usted dijo. Sin embargo, yo creo que usted se olvid≤ de algo importante: el punto de vista DESDE el resto del mundo. Trabajo en el sector financiero en Europa ûen Zurich, para ser preciso-- y tengo una cierta relaci≤n con el tema de la seguridad. Este sector a) NUNCA USAR┴ los productos criptogrßficos americanos, y b) NO harß ning·n plan a largo plazo ni ciertamente se asociarß para promover los productos americanos a nivel del consumidor, porque a) estos productos hasta la fecha estaban forzados por la ley a ser dΘbiles, pero mßs importante, b) no puede confiarse en el gobierno americano. Aun cuando aprob≤ hoy la exportaci≤n de ciertos productos de criptografφa fuerte, todos sabemos que este permiso puede revocarse ma±ana para estos mismos u otros productos. Y tambiΘn sospechamos fuertemente que el gobierno americano obligarß en todo caso a los proveedores a incluir puertas traseras en sus productos. Bajo estas condiciones, las empresas financieras y de comercio electr≤nico de Europa tendrφan que estar locas para usar los productos basados en criptografφa americana. Y no estßn locos. Para importar en este negocio en el resto del mundo, los Estados Unidos tendrφan que mantener una polφtica clara, consistente, y favorable, y las compa±φas americanas tendrφan que presentar productos que pudieran demostrar que son fuertes y sin puertas traseras. (Yo le invito a especular si esto pasarß antes de que se hiele el Infierno.) Entretanto hay suficientes productos no americanos para escoger, y bancos como UBS, Credit Suisse, Grupo Intesa, Societe General, Deutsche Bank, Bank Austria, y Barclays no se han quedado sentados esperando ansiosamente a que los productos americanos estuvieran disponibles. Han estado haciendo negocios con productos no americanos que simplemente son buenos, gracias. De: Grawrock, David Tema: La Votaci≤n Electr≤nica. ________________________________ Todos estos comentarios sobre la votaci≤n electr≤nica y por correo estßn errando su objetivo. En el estado de Oreg≤n todas las elecciones (excepto las presidenciales) se hacen por correo. Es como si todo el estado estuviera ausente. El proceso es realmente bastante simple. Se recibe la tarjeta de votante, y posteriormente la papeleta de voto. La papeleta tiene que entregarse antes del dφa de la votaci≤n. Si se echa de menos la excitaci≤n de ir al centro de votaci≤n hay centros de recepci≤n de votos donde puede entregarse la papeleta. Realmente no es tan difφcil. Aquφ el punto importante es que el estado ha determinado que es mßs fßcil (y mßs barato) simplemente realizar todo el proceso de las elecciones vφa votaci≤n por correo. Ahora hay un paso muy simple para cambiar de la votaci≤n por correo a la votaci≤n electr≤nica. Todos los argumentos con respecto a la coacci≤n ya deben haberse contestado (el gobierno siempre estudia completamente cualquier proceso). Nosotros hemos elegido toda clase de cargos polφticos sin que apareciera nadie informando de problemas con coacci≤n. De: Gerry Brown Tema: Re: Votos por correo ___________________________ He comprobado algunas cifras con un amigo que dispone de datos sobre los votos por correo en el condado de San Mateo (california) y que ha comparado con las eleccciones de San Francisco de esta semana. El porcentaje de votantes censados que han utilizado voto por correo es del 13-15%. Pero lo mßs chocante es que el 35-50% de los que realmente votan lo hacen por correo. La cifra mßs baja se refiere a las elecciones nacionales y la mßs alta a las locales. De: Hillis, Brad Tema: Artφculo sobre PKI: acuerdo y desacuerdo _______________________________________________ No puedo comenzar diciΘndole cußnto he disfrutado su artφculo con Carl Ellison "Diez riesgos de PKI: lo que no le han contado sobre claves p·blicas". Soy el principal abogado en comercio electr≤nico de Washington y estamos actualmente buscando un vendedor privado de PKI que proporcione firmas digitales para el gobierno estatal y local, similar al ACES del gobierno federal. Lo que usted dice acerca de que no se necesita PKI para que el comercio electr≤nico florezca es cierto. Es algo que sostengo en todas las charlas legales sobre firmas digitales a las que asisto y el tema que he pensado someter a discusi≤n en mi charla sobre PKI en Boston el 7 de Marzo. Uno tiene que seguir preguntßndose: ┐por quΘ necesito una firma digital? ┐cußl es el coste de establecer una PKI? (es decir: ┐quΘ mejoras de seguridad voy a obtener si gastase dinero en algo mßs que PKI? Sin embargo, discrepo con esta afirmaci≤n de su artφculo: "En otras palabras, bajo ciertas leyes de firma digital (por ejemplo, Utah y Washington), si su clave de firma ha sido certificada por una CA reconocida, entonces usted es responsable de todo lo que haga su clave privada. No importa quiΘn estaba sentado al teclado o quΘ virus realiz≤ la firma; usted es legalmente responsable." Una primera lectura de la ley parece decir eso, pero mi opini≤n es que la ley establece una "presunci≤n refutable" de no repudio. Es la misma ley que se aplica a las firmas con tinta y bolφgrafo. Su afirmaci≤n refleja el punto de vista de algunos opositores a PKI que exageran la fuerza legal de una "firma digital autorizada" bajo la ley de Washington. Pero si, de hecho, yo nunca aplicase mi firma digital a un documento y puedo demostrarlo (por ejemplo, tengo una coartada), entonces no serφa legalmente responsable. Creo que es la misma situaci≤n que en los esquemas de firma electr≤nica no-PKI, donde un (documento firmado manualmente) acuerdo de intercambio electr≤nico de datos (EDI) o un acuerdo de colaboraci≤n comercial, establece que todos los datos intercambiados entre las partes tienen la misma fuerza legal que si hubieran sido firmados a mano. Habiendo hallado fallos en las leyes relativas a PKI de Washington, Utah y Minnesota, sin embargo no encuentro un mejor nivel de inteligencia prßctica en las mßs populares leyes de firma electr≤nica. Las leyes de firma electr≤nica no han demostrado ser mßs importantes para el comercio electr≤nico que las leyes de firma digital PKI, asφ que ┐por quΘ tanta prisa por aprobar UETA (Acta de transacciones electr≤nicas uniformes)? De: Carl Ellison Tema: Artφculo sobre PKI: acuerdo y desacuerdo ______________________________________________ Usted estß en lo cierto. Sin embargo, creo que a·n necesitamos alertar sobre la presunci≤n refutable de no repudio. El propietario de la clave pudiera no tener ninguna coartada e incluso no ser consciente de que su clave ha sido utilizada de forma indebida (por ejemplo, por un atacante que ha tenido acceso fφsico o por la red a su ordenador). El asunto es similar a la posici≤n de la gente que aquφ en Gran Breta±a estaba desafiando las operaciones con tarjeta en los cajeros. Expertos como Ross Anderson defendieron algunas de sus afirmaciones y a·n asφ no sirvi≤. En ese caso, tambiΘn, se presumφa que el propietario de la tarjeta habrφa realizado cualquier operaci≤n que figurase en el registro del cajero, fuese o no asφ. Recaφa en el titular demostrar lo contrario. El tema es a·n peor cuando el titular lleva su clave privada en una tarjeta inteligente. Entonces es a·n mßs difφcil convencer a un tribunal de que no se firm≤, si el comerciante o el banco pueden afirmar que la clave de firmado nunca dej≤ de pertenecerle. Cuando un atacante logra acceso a su ordenador por la red no deja ninguna pista. No hay un registro mostrando el ataque. Es su palabra contra la del comerciante y usted no dispone de pruebas a su favor que presentar. Ni siquiera puede acusar a otro. No tiene ni idea de a quiΘn acusar. Mientras tanto, a su cuenta le han hecho un cargo hasta que usted se las ingenie para demostrar su afirmaci≤n (contra la presunci≤n de que usted miente). Cuando se compara esto con las compras con tarjeta de crΘdito, resulta radicalmente diferente. Con la tarjeta de crΘdito, usted no ha gastado nada hasta que escribe en el recibo para la compa±φa de tarjetas. Mientras usted no escriba ese recibo, usted puede rechazar un artφculo y obligar al comerciante a demostrar que usted fue realmente el comprador. Al menos con mi cuenta de AMEX, el resultado inmediato es que AMEX borra el artφculo de mi recibo, a la espera de que me sea de nuevo cargado si el comerciante es capaz de probar que yo lo comprΘ. Alguna vez ha ocurrido asφ y el resto me he olvidado del tema. En un caso pensΘ que me estaban cargando dos veces por el mismo artφculo, pero result≤ que nunca me habφan cargado la primera compra (muchos meses antes). De: Alfred John Menezes Tema: Sistemas Criptograficos basados en Curva Eliptica. ________________________________________________________ He leido con interΘs su reciente artφculo sobre ECC en el CriptoGrama de Noviembre. Estoy de acuerdo con la mayor parte de sus afirmaciones y comentarios. Sus recomendaciones fueron: 1) Si trabaja en un entorno restringido donde las claves mßs largas sencillamente no cabrßn, considere las curvas elipticas. 2) Si la elecci≤n son curvas elipticas o ning·n algoritmo de clave p·blica en absoluto, use curvas elipticas. 3) Si no tiene restricciones de rendimiento, use RSA. 4) Si esta preocupado acerca de la seguridad a largo plazo (y apenas sobre el sistema), use RSA. Estoy absolutamente de acuerdo con las recomendaciones 1) y 2) ECC desde luego no puede ser peor que ninguna seguridad en modo alguno!! Respecto a la recomendaci≤n 3), creo que la mayorφa de los entornos cuya demanda de soluciones se base en llave p·blica tendrßn alguna restricci≤n de rendimiento. El factor limitativo puede ser una sobrecarga del servidor web que necesite firmar miles de mensajes salientes por minuto, un instrumento portßtil que estΘ comunicando con un PC, etc. En tales escenarios, se deberφa seleccionar el mΘtodo de clave p·blica que rindiera lo mejor posible en el entorno mßs restrictivo. Si las limitaciones se refieren a tama±os de clave, ancho de banda, consumo elΘctrico, o velocidad (para las operaciones de clave privada), entonces ECC es probablemente el mΘtodo de elecci≤n, por delante de RSA. Finalmente, considero que su recomendacion respecto a que RSA deberφa ser usada (en vez de ECC) en situaciones donde se estΘ preocupado de la seguridad a largo plazo es poco justa. DespuΘs de todo, como sus anotaciones finales en su artφculo decφan, todo el anßlisis que us≤ en el problema del logaritmo discreto de curva eliptica tambiΘn se aplica al problema de la factorizaci≤n de enteros. Propongo que aquellas aplicaciones que requieran seguridad a largo plazo deberian considerar el usar tanto RSA como ECC, cifrando un mensaje doblemente con RSA y ECC, o firmando un mensaje dos veces con RSA y ECC. Lo siguiente son mis reflexiones resumidas sobre la seguridad y eficacia de ECC comparada con RSA. Deberian ser consideradas un suplemento a su artφculo de CriptoGrama, y no como un sustituto de Θl. http://www.cacr.math.uwaterloo.ca/~ajmeneze/misc/cryptogram-article.html (Es un buen ensayo, pero refleja la parcialidad del autor. Trabaja para Certicom, y ahφ entra su interes econ≤mico para hacerle creer en las curvas elφpticas. Bruce- ) _____________________________________________________________________ CriptoGRAMA es la versi≤n espa±ola de Crypto-GRAM, elaborada por el equipo de traductores de Kript≤polis, con autorizaci≤n expresa de Bruce Schneier. Este ejemplar nunca hubiera sido posible sin la colaboraci≤n desinteresada de las siguientes personas: * Isidre Marques Serret * Miguel Camacho * Juan Cruz Ruiz de Gauna * David G≤mez * Oscar Esteban Si usted tambiΘn desea colaborar en la traducci≤n de pr≤ximos ejemplares, dirφjase a colab@kriptopolis.com. _____________________________________________________________________ -- AVISO IMPORTANTE -- Kript≤polis dispone de la pertinente autorizaci≤n de Bruce Schneier para traducir, elaborar y publicar la versi≤n espa±ola de su boletφn Crypto-GRAM. La informaci≤n contenida en CriptoGRAMA s≤lo puede ser redistribuida siempre que se haga de forma completa y con expresa menci≤n de Bruce Schneier como autor de Crypto-GRAM y de Kript≤polis como responsable de CriptoGRAMA. Crypto-GRAM es un boletφn mensual gratuito dedicado a res·menes, anßlisis, comentarios e ideas sobre criptografφa y seguridad informßtica. Crypto-GRAM es elaborado por Bruce Schneier, presidente de Counterpane Systems, autor de "Applied Cryptography" y creador de los algoritmos Blowfish, Twofish y Yarrow. Schneier ha pertenecido a la direcci≤n de la International Association for Cryptologic Research, EPIC y VTW, y es asiduo escritor y conferenciante sobre criptografφa. _____________________________________________________________________ Versi≤n Web de este ejemplar: http://www.kriptopolis.com/criptograma/cg0021.html Este ejemplar se ha distribuido gratuitamente a mßs de 16.000 personas. Si desea recibir la edici≤n mensual de CriptoGrama y la edici≤n semanal del Boletφn de Kript≤polis, inscrφbase gratis en: http://www.kriptopolis.com/subs.html ⌐ Bruce Schneier ⌐ Kriptopolis (versi≤n en Espa±ol). _____________________________________________________________________