1999 << Back To criptograma nº 8

C R I P T O - G R A M A ⌐ Bruce Schneier ⌐ Kriptopolis (versi≤n en Espa±ol). ------------------------------------------------------ N·mero 8 15 de Diciembre de 1998 SUMARIO: El enga±o de los concursos de 'crackeado' C≤mo reconocer texto en claro Noticias En desgracia: los discos Iomega Zip Noticias desde Counterpane Systems Informe final del Consejo TΘcnico Asesor del Departamento de Comercio sobre Recuperaci≤n de claves Comentarios de lectores ---------------------------------------------------------------- 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. Nuevos ejemplares de CriptoGRAMA estarßn disponibles cada mes en: Cripto-GRAMA: http://www.kriptopolis.com/criptograma/cg.html 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. Crypto-GRAM: http://www.counterpane.com/crypto-gram.html ---------------------------------------------------------------- El enga±o de los concursos de 'crackeado' Por Bruce Schneier Traducci≤n: Isidre MarquΘs Serret, ismase@mx3.redestb.es Podemos verlos anunciados en cualquier momento: "La Compa±φa X ofrece 1.000.000 de d≤lares a quien puede atravesar su cortafuegos/reventar su algoritmo/hacer una transacci≤n fraudulenta usando su protocolo/hacer cualquier otra cosa." Estos son los Concursos de Crackeado, y se supone que son para mostrar lo fuerte y seguro que es el objetivo del concurso. La l≤gica sigue este camino: nosotros ofrecimos un premio para quien lo reventara, y nadie lo hizo. Esto significa que el blanco es seguro. No lo significa. Los concursos son un pΘsimo camino para demostrar la seguridad. Un producto/sistema/protocolo/algoritmo que ha sobrevivido a un concurso sin ser vencido no es, obviamente, de mßs confianza que uno que no ha sido el objetivo de un concurso. Los mejores productos/sistemas/protocolos/algoritmos disponibles hoy, no han sido el objetivo de ning·n concurso, y probablemente nunca lo sean. Los concursos, generalmente, no dan resultados ·tiles. Hay tres razones bßsicas para esto. 1. Los concursos son generalmente injustos. El criptoanßlisis supone que el atacante lo conoce todo excepto la clave. Conoce los algoritmos y protocolos, el c≤digo fuente, todo. Conoce el texto cifrado y el original. Incluso puede conocer algo sobre la clave de cifrado. Pero el resultado de un criptoanßlisis puede ser cualquier cosa. Puede ser un Θxito completo: se logra atravesar, completamente, el sistema de seguridad en un periodo razonable de tiempo. Puede ser un Θxito te≤rico: no se logra romper el sistema de seguridad de una manera ·til, pero se descubren agujeros que demuestran que no es tan seguro como se dice. Y cualquier otra cosa entre ambas posibilidades. La mayorφa de concursos de criptoanßlisis tiene reglas arbitrarias. Definen con quΘ tiene que trabajar el atacante, y quΘ se considera una rotura. Jaws Technologies proporcion≤ un archivo cifrado y, sin explicar nada acerca de su algoritmo de trabajo, ofreci≤ un premio a quien pudiera recuperar el texto original. Este no es el procedimiento correcto de trabajo del autΘntico criptoanßlisis; si nadie gana el concurso no significa nada. La mayorφa de los concursos no revelan el algoritmo. Y la mayorφa de los criptoanalistas no saben c≤mo realizar un procedimiento de ingenierφa inversa para averiguarlo (yo personalmente lo encuentro tedioso y aburrido); nunca se molestan en analizar el sistema. Este es el motivo por el cual COMP128, CMEA, ORYX, el sistema de cifrado Firewire, el sistema DVD, y el sistema PRNG de Netscape fueron todos ellos vencidos pocos meses despuΘs de su divulgaci≤n (a pesar de que algunos de ellos se han estado usando desde hace muchos a±os); una vez se da a conocer el algoritmo, es fßcil encontrarle los defectos, pero pueden pasar a±os antes de que alguien se moleste en realizar el procedimiento de ingenierφa inversa y publique el resultado. Los concursos no ayudan en nada. (Por supuesto, el pßrrafo anterior no tiene aplicaci≤n para el campo militar. Los Θxitos de la ingenierφa inversa --VENONA, PURPLE-- son innumerables en el mundo "real". Pero, por suerte o por desgracia el mundo acadΘmico no trabaja de esa manera.) Los concursos injustos no son nada nuevo. A mediados de los 80 los autores de un algoritmo de cifrado llamado FEAL lanzaron un concurso. El algoritmo ha sido repetidamente roto por cript≤grafos, mediante el criptoanßlisis diferencial y lineal y mediante otros sistemas de ataque estadφstico. Todo el mundo estß de acuerdo en que el algoritmo tiene graves errores. Pero nadie ha ganado todavφa el concurso. 2. El anßlisis no esta controlado. Los concursos son pruebas aleatorias. ┐Cuentan diez personas trabajando cada una 100 horas para ganar el concurso como 1000 horas de anßlisis? ┐O hicieron todos ellos las mismas cosas? ┐Son analistas competentes, o son gente sin conocimiento que oy≤ hablar del concurso y quiso probar suerte? Que nadie gan≤ el concurso no significa que el objetivo es seguro... simplemente significa que nadie gan≤. 3. Los premios del concurso rara vez son autΘnticos incentivos. El criptoanßlisis de un algoritmo, protocolo, o sistema puede ser un trabajo muy duro. La gente cualificada para hacer el trabajo lo puede hacer por una gran variedad de motivos --el dinero, el prestigio, el aburrimiento-- pero tratar de ganar un concurso raramente es uno de ellos. Los concursos se ven en la comunidad del criptoanßlisis con escepticismo: la mayorφa las compa±φas que los patrocinan no son conocidas, y la gente duda de si juzgarßn los resultados honradamente. Y tratar de ganar un concurso no es nada seguro: alguien se le puede adelantar, dejßndole sin nada que recompense sus esfuerzos. Los criptoanalistas son mucho mejores analizando sistemas cuando cobran por su trabajo, o pueden publicar artφculos explicando sus Θxitos. Simplemente analicemos las razones econ≤micas. Tomando (a un precio conservador de 125 d≤lares por hora) el trabajo de un criptoanalista competente, 10.000 d≤lares significan el sueldo de dos semanas de trabajo, tiempo insuficiente para, simplemente, comenzar a analizar el c≤digo. Un premio de 100.000 d≤lares podrφa valer la pena, pero la ingenierφa inversa es un procedimiento aburrido, y todavφa no compensa el tiempo necesario para hacer un trabajo completo. Un premio de 1.000.000 de d≤lares empieza a ser interesante, pero la mayorφa de las compa±φas no pueden permitirse este gasto. Y el criptoanalista no tiene ninguna garantφa de conseguir el premio: puede no encontrar nada, puede lograr tener Θxito, pero despuΘs de otra persona, o la compa±φa puede simplemente no pagar. ┐Por quΘ deberφa un criptoanalista donar su tiempo (y buen nombre) a la campa±a publicitaria de esa compa±φa? Los concursos de criptoanßlisis, generalmente, no son mßs que una herramienta de publicidad. Patrocinar un concurso, incluso uno justo, no es ninguna garantφa de que la gente analice el objetivo. Superar un concurso tampoco es ninguna garantφa de que no haya errores en el objetivo. La autΘntica medida de confianza es cußntos anßlisis se han hecho, no si habφa un concurso. Y el anßlisis es un proceso lento y pesado. La gente confφa en los algoritmos de cifrado (DS, RSA), en los protocolos (Kerberos), y los sistemas (PGP, IPSEC) no a causa de concursos, sino porque todos han sido sometidos a a±os (dΘcadas, incluso) de profundos anßlisis y revisiones. Y se han analizado no a causa de un premio escurridizo, sino porque eran interesantes o ampliamente extendidos. El anßlisis de los quince candidatos al AES va a durar varios a±os. No hay un premio en el mundo que pueda hacer que los mejores criptoanalistas dejen lo que estßn haciendo y se dediquen a examinar las ofertas de Meganet Corporation o RPK de Security Inc., dos de las compa±φas que recientemente ofrecieron premios para quien craquee sus productos. Es mucho mßs interesante encontrar defectos en Java, o Windows NT, o en la seguridad de los telΘfonos celulares. Las tres razones arriba expuestas son generalizaciones. Hay excepciones, pero son pocas y muy separadas en el tiempo. Los desafφos de RSA, tanto sus desafφos de factorizaci≤n como los de fuerza bruta simΘtrica, son justos y interesantes. Estos concursos tienen Θxito no porque el dinero de premio sea un incentivo para factorizar n·meros o construir mßquina de craquear por fuerza bruta, sino porque los investigadores se interesan ya en la factorizaci≤n y el craqueo mediante la fuerza bruta. Los concursos simplemente proporcionan un foco para lo que era ya un empe±o interesante. La disputa AES, aunque es mßs una competici≤n que un concurso de criptoanßlisis, tambiΘn es justa. Nuestro concurso de criptoanßlisis sobre Twofish ofrece un premio de 10.000 d≤lares para el mejor comentario negativo contra Twofish que no sea escrito por los autores del mismo. No hay las definiciones arbitrarias de que es un anßlisis ganador. No hay texto cifrado que romper o claves que recuperar. Nosotros simplemente premiamos el mejor resultado de la investigaci≤n criptoanalφtica, cualquiera que pueda ser y sin importar si tiene Θxito (o no). Ademßs, el concurso es justo porque 1) el algoritmo esta completamente especificado, 2) no hay definici≤n arbitraria de significa ganar, y 3) el algoritmo es de dominio p·blico. Los concursos, si se montan correctamente, pueden proporcionar informaci≤n ·til y premiar ßreas concretas de investigaci≤n. Pero no son una medida ·til para juzgar la seguridad. Yo puedo ofrecer 10.000 d≤lares a la primera persona que fuerce la entrada en mi casa y robe un libro de mi biblioteca. Si nadie lo hace antes de que el concurso termine, ello no significa que mi casa sea segura. Quizß nadie con suficiente habilidad para el robo ha oφdo hablar sobre mi concurso. Quizß estaban demasiado ocupados haciendo otras cosas. Quizß no eran capaces de forzar la entrada en mi casa, pero sabφan c≤mo falsificar el tφtulo de propiedad para ponerla a su nombre. Quizß forzaron la entrada en mi casa, pero echaron una mirada alrededor y decidieron volver cuando hubiera en juego algo de mßs valor que un premio de 10.000 d≤lares. El concurso no prob≤ nada. Gene Spafford escribi≤ contra los concursos de craqueo y su texto lo podΘis encontrar en la siguiente direcci≤n: http://www.itd.nrl.navy.mil/ITD/5540/ieee/cipher/old-issues/issue9602 Matt Blaze tambiΘn escribi≤ contra estos concursos, pero no hemos podido hallar ninguna buena direcci≤n. C≤mo reconocer texto en claro Por Bruce Schneier Traducci≤n: Juan Cruz Ruiz de Gauna Gorostiza, juancruz.ruiz@si.upna.es Una mßquina de ruptura de claves mediante fuerza bruta prueba todas las claves posibles hasta que encuentra la adecuada. Si la mßquina tiene una porci≤n de texto cifrado y lo descifra con una clave tras otra, ┐c≤mo sabe cußndo ha dado con con el texto en claro (es decir, el texto original legible y sin cifrar) correcto?. Para mφ la respuesta es obvia, pero me encuentro esta pregunta lo suficientemente a menudo como para tratarla en estas pßginas. La mßquina sabe que ha encontrado el texto en claro precisamente porque el resultado obtenido parece texto en claro. El texto en claro tiende a parecer texto en claro. Es un mensaje en lenguaje natural, o un fichero de datos de una aplicaci≤n informßtica (programas como Microsoft Word tienen largas cabeceras conocidas; incluso los ficheros PK-ZIP tienen cabeceras conocidas), o una base de datos con un formato aceptable. Cuando miramos un fichero desencriptado parece algo comprensible. Cuando miramos un fichero cifrado o descifrado con una clave err≤nea, parece un autΘntico galimatφas. En los a±os 40, Claude Shannon invent≤ un concepto denominado la "distancia de unicidad". Entre otras cosas, la distancia de unicidad mide la cantidad de texto cifrado que se requiere de tal forma que le corresponda un ·nico texto en claro razonable. Este n·mero depende tanto de las caracterφsticas del texto en claro como de la longitud de la clave del algoritmo de cifrado. Por ejemplo, RC4 cifra los datos en bytes. Imaginemos una carta con un ·nico carßcter ASCII como texto en claro. Hay 26 posibles textos en claro a partir de 256 posibles descifrados. Cualquier clave aleatoria, usada para desencriptar el texto cifrado, tiene una oportunidad de 26/256 para producir un texto en claro vßlido. El analista no tiene forma de distinguir el texto en claro incorrecto de aquΘl que sea el correcto. Ahora imagφnemos un mensaje de correo electr≤nico de 1 KB. El analista prueba claves aleatorias, y eventualmente aparece un texto en claro que parece un mensaje de correo electr≤nico: palabras, frases, sentencias, gramßtica. Las posibilidades de que este no sea el texto en claro correcto son infinitesimales. Cualquier otra cosa queda a medio camino. La distancia de unicidad determina cußndo podemos pensar como en el segundo ejemplo en lugar de como en el primero. Para un mensaje standard en inglΘs la distancia de unicidad es K/6.8, donde K es la longitud de la clave. (El 6.8 es una medida de la redundancia del idioma inglΘs en ASCII. Para otros textos en claro puede ser mßs o menos, pero no mucho mßs o menos). Para DES, la distancia de unicidad es 8.2 bytes. Para cifrados de 128 bits, la distancia de unicidad es alrededor de 19 bytes. Esto significa que si intentamos descifrar mediante fuerza bruta un texto DES necesitaremos dos bloques de texto cifrado (La longitud de un bloque DES es de 8 bytes). Descifraremos el primer bloque de texto con una clave tras otra. Si el texto en claro resultante parece ser inglΘs, entonces descifraremos el segundo bloque con la misma clave. Si el segundo bloque tambiΘn parece ser inglΘs entonces hemos localizado la clave correcta. La distancia de unicidad aumenta a medida que la redundancia del texto en claro disminuye. Para ficheros comprimidos, la redundancia puede ser 2.5, o tres bloques de texto cifrado con DES. Para un cifrado con clave de 256 bits, esto supondrφa un texto en claro de 105 bytes. Si el texto en claro es una clave aleatoria la redundancia es cero y la distancia de unicidad se va a infinito: es imposible distinguir el texto en claro correcto de uno cualquiera incorrecto. Pero este es un caso especial. Las mßs de las veces es fßcil reconocer texto en claro. Noticias Por Bruce Schneier Traducci≤n: JosΘ Luis Martφn Mas, jlmartin@lander.es Bien; por fin me he enterado de la verdad sobre Network Associates Inc. y la Key Recovery Alliance (Alianza por el Almacenamiento Centralizado de Claves). El mes pasado hablΘ de un artφculo de Wired News seg·n el cual se habφan reincorporado a la KRA. La historia es falsa. Nunca abandonaron la KRA. Desde su creaci≤n, Trusted Information Systems ha sido un gran promotor de la KRA. Cuando NAI compr≤ TIS en mayo de 1998, la vinculaci≤n de TIS a la KRA le fue transferida a NAI. NAI renunci≤ a la posici≤n de liderazgo que TIS habφa ostentado hasta entonces en la Alianza, y dej≤ de acudir a sus reuniones, pero nunca abandon≤ la KRA. Asφ pues, NAI es un miembro de la KRA desde que compr≤ TIS. http://www.wired.com/news/print_version/technology/story/16219.html Un juez federal ha emitido una orden temporal de suspensi≤n contra la entrada en vigor de la Acta para la Protecci≤n de la Infancia en Redes (la denominada CDA II). Esto es un asunto importante, y algo que celebrar. Se puede leer la decisi≤n del juez en: http://www.aclu.org/court/acluvrenoII_order.html El texto completo del informe del demandante estß en: http://www.epic.org/free_speech/copa/tro_brief.html Para mantenerse al dφa sobre este tema, suscrφbase a EPIC Alert: http://www.epic.org/alert/subscribe.html Informaci≤n sobre un fascinante agujero de seguridad en la Web: http://www.securexpert.com/framespoof/index.html Los abogados de Liquid Audio, una compa±φa que promueve la distribuci≤n segura de m·sica en la Red, presionaron a una persona para que retirara informaci≤n sobre c≤mo eliminar las protecciones anti-copia. Se supone que a·n se ense±a la Primera Enmienda en las clases de la Facultad de Derecho. http://www.mp3.com/news/122.html Una buena biblioteca para C++: NTL proporciona estructuras de datos y algoritmos para manipular enteros con signo de longitud arbitraria, vectores, matrices y polinomios en campos de enteros y campos finitos. Acaba de salir la versi≤n 3.1b. http://www.cs.wisc.edu/~shoup/ntl/ A la Administraci≤n Clinton no le basta con tratar de destruir los medios necesarios para proteger la privacidad personal en Estados Unidos; durante a±os han tratado de exportar sus principios a otros paφses. Ahora, cumpliendo con los principios defendidos por esta Administraci≤n, los 33 paφses firmantes del Tratado de Wassenaar se han puesto de acuerdo para poner en prßctica los mismos absurdos controles de exportaci≤n sobre software de uso general que existen en los Estados Unidos. No sΘ si esto es del todo cierto, -esta Administraci≤n ya ha mentido otras veces sobre c≤mo son aceptadas internacionalmente sus polφticas- pero si lo es, es un gran paso atrßs. No tengo muy claro por quΘ esta Administraci≤n cree que asegurarse de que cualquier informaci≤n delicada serß encriptada dΘbilmente, de tal manera que los delincuentes puedan leerla sin dificultades, ayudarß al mundo, pero estoy seguro de que tienen alguna idea. http://www.nytimes.com/library/tech/98/12/biztech/articles/04encrypt.html http://jya.com/wass-au.htm http://jya.com/wass-de2.htm http://biz.yahoo.com/rf/981203/3l.html Los firmantes del Tratado de Wassenaar son: Alemania, Argentina, Australia, Austria, BΘlgica, Bulgaria, Canadß, Corea del Sur, Dinamarca, Eslovaquia, Espa±a, Estados Unidos, Finlandia, Francia, Grecia, Holanda, Hungrφa, Irlanda, Italia, Jap≤n, Luxemburgo, Noruega, Nueva Zelanda, Polonia, Portugal, Reino Unido, Rep·blica Checa, Rumanφa, Rusia, Suecia, Suiza, Turquφa y Ucrania. http://www.wassenaar.org/ Visite el website de FreeCrypto y envφe un mensaje en contra del Tratado. http://www.freecrypto.org En desgracia: discos Iomega Zip Por Bruce Schneier Traducci≤n: Antonio Muntaner, mmg@balears.net Las instrucciones siguientes describen una forma de saltarse la protecci≤n de lectura/escritura en los discos ZIP-100 de Iomega. No se trata de un trabajo mφo: lo he recibido de forma an≤nima. Si alguien sabe quiΘn ha sido su autor, le ruego le diga que se ponga en contacto conmigo. La caracterφstica de protecci≤n por contrase±a supone tener una contrase±a y un indicador (flag) de seguridad almacenados en el disco ZIP (┐en el sector de arranque?). Esta clave e indicador de estado de seguridad son leφdos por el "firmware" de la unidad ZIP, no permitiendo el acceso a un disco que considera que estß protegido contra lectura/escritura. La unidad ZIP lleva un sistema de autoapagado que detiene literalmente el giro de la unidad (┐y aparca la cabeza de lectura/escritura?) tras quince minutos de inactividad. La unidad vuelve a arrancar automßticamente en cuanto se necesita. El "firmware" no se da cuenta (en el momento de escribir esto: 28 de Mayo de 1998), de un cambio en el disco a travΘs del dispositivo manual de expulsi≤n del disco que existe en la parte de atrßs del dispositivo. Si tras una parada, un disco que se sabe estß protegido es expulsado manualmente, y se inserta en su lugar otro disco tambiΘn protegido, la contrase±a del primer disco todavφa es considerada vßlida por el "firmware", y por lo tanto, sigue valiendo para el segundo disco. El segundo disco puede ser asφ "desprotegido", sin mßs que utilizar la misma clave que para el primer disco. Para ejecutar este truco, siga estas instrucciones: Se necesita un disco ZIP-100 virgen. LlamΘmosle disco "Conocido". Introduzca el disco conocido en la unidad ZIP. Proteja el disco conocido con una contrase±a contra lectura/escritura, usando las herramientas Iomega. Usando las preferencias de arranque de estas herramientas, fije el parßmetro "Sleep Time" de la unidad ZIP a 1 minuto. Deje que la unidad se apague, con el disco conocido todavφa dentro. (la diferencia en el ruido de salida es bastante obvia). Tome un "clip" sujetapapeles y desd≤blelo. Pinche con el clip en el peque±o orificio de la parte trasera de la unidad ZIP y extraiga de forma manual el disco conocido. (Este orificio estß situado en la parte trasera de la unidad, por encima de la toma para la impresora o del segundo conector SCSI). Inserte el disco desconocido. La unidad podrφa empezar a girar y tomar velocidad, o bien permanecer quieta. Usando las herramientas de Iomega, QUITE la protecci≤n del disco, usando la CLAVE CONOCIDA, seg·n la instrucci≤n 3 anterior. Utilizando el bot≤n normal de expulsi≤n, que estß en la parte delantera del aparato, extraiga el disco "DESCONOCIDO". Vuelva a insertar el disco "DESCONOCIDO" otra vez (para permitir el acceso a ficheros y directorios). Haga doble click en el icono de la unidad de disco en la ventana del Explorador de ficheros. íListo! Noticias desde Counterpane Systems Por Bruce Schneier Existe otro informe tΘcnico (el n·mero 3) sobre Twofish en nuestro web. Este se denomina "Implementaciones mejoradas de Twofish" y proporciona mejores cifras de rendimiento sobre ordenadores de 32 bits, tarjetas inteligentes y hardware: http://www.counterpane.com/twofish-speed.html TambiΘn hay una implementaci≤n de Twofish en Delphi: http://www.hertreg.ac.uk/ss/d_crypto.html Y por ·ltimo, hemos publicado un documento que compara el rendimiento de los 15 candidatos AES sobre procesadores de 32 bits, tarjetas inteligentes y hardware: http://www.counterpane.com/AES-performance.html Informe final del Consejo TΘcnico Asesor del Departamento de Comercio sobre Recuperaci≤n de claves Por Bruce Schneier Traducci≤n: Jaime Millßn de Castro, us_jaime@svalero.es El Comite TΘcnico Asesor para el Desarrollo de un Estßndar Federal del Procesado de Informaci≤n para la Infraestructura Federal de Administraci≤n de Claves, fue fundado en julio de 1996 por el Departamento de Comercio. El ComitΘ, que estuvo totalmente constituido el 24 de julio de 1996, celebr≤ su primera reuni≤n los dias 5 y 6 de diciembre de 1996. El objetivo, proximo a cumplirse, fue lograr un acuerdo con la industria sobre la regulaci≤n de la recuperaci≤n de claves. Su reuni≤n final se celebr≤ entre los dφas 17 y 19 de noviembre de 1998. La reuni≤n tuvo mßs de fracaso que de Θxito. Aunque el comitΘ concluy≤ todo su trabajo, su documento final contin·a siendo redactado y continuarß asφ durante las pr≤ximas semanas. El documento es mucho mßs coherente que el realizado en el mes de junio. Sin embargo, todavφa no ha sido revisado minuciosamente. A continuaci≤n se presentan algunos puntos que pudieran resultar de interΘs. Aunque pudiera ser descrito como tal, el documento final del comitΘ difφcilmente puede considerarse resultado del trabajo de una comisi≤n formada por 22 miembros. La participaci≤n disminuy≤ hasta tal punto que, a los miembros que no asistieron a la reuni≤n final, se les pidi≤ que dimitieran para que asφ pudiera lograrse el "quorum". Al acabar la reuni≤n definitiva, menos de media docena de participantes que todavφa quedaban, continuaban a·n realizando cambios sustantivos en el documento. Los cambios continuaron siendo realizados por el presidente y otros individuos incluso tras finalizar la reuni≤n definitiva del comitΘ. La comision no concluy≤ "nada". El comite nunca vot≤, ni siquiera trat≤, si el dep≤sito de claves tenφa sentido, d≤nde deberφa tener lugar, o siquiera si es posible, seguro o si tiene alguna justificaci≤n desde el punto de vista econ≤mico. La comisi≤n no hizo ning·n tipo de recomendaci≤n. El trabajo del comite es de dominio p·blico y presumiblemente serß continuado por el NIST. Sin embargo, el comitΘ no recomend≤ que su trabajo siguiera adelante. El documento producido por el comitΘ no presenta un anteproyecto sobre c≤mo realizar el dep≤sito de claves. Muestra mßs de 200 cosas que los productos de recuperaci≤n de claves deberφan o no deberφan hacer, sin mencionar siquiera c≤mo hacerlas. No hay ninguna raz≤n para creer que el documento del comitΘ es consistente o estß completo. Como ejemplo, la mayorφa de las mßs de 200 estipulaciones incluidas en el documento, estßn contenidas en una seccion que fue completamente reescrita por un solo miembro un poco antes de la reuni≤n definitiva. Durante el ·ltimo dφa de la reuni≤n final y antes de que esta secci≤n hubiera sido revisada por lo que quedaba del comitΘ, este miembro se march≤, argumentando que puesto que el grupo ya no contaba con el "quorum" suficiente, su presencia allφ ya no era necesaria. La secci≤n fue despuΘs revisada superficialmente por los pocos miembros que a·n quedaban. El documento fue escrito al menos tanto por el NIST, como por la NSA y el propio comitΘe. Aunque los ·unicos miembros con derecho a voto del comitΘ provenφan del sector privado, ciertamente no fue un producto (o iniciativa) de dicho sector." Comentarios de los lectores Traducci≤n: Eduardo Vßzquez Palacios, dronos@bigfoot.com * De Chris Smith, smith@interlog.com: Ha escrito acerca de las nuevas normas sobre criptografφa de Canadß. Sin embargo, las nuevas normativas no son, como usted describe, acerca de las "normas de exportaci≤n", sino acerca de la polφtica domΘstica. Esto trata sobre la criptografφa en Canadß. Mi interpretaci≤n es que Canadß va a continuar cumpliendo con el "Tratado de Wassenaar", que actualmente limita la exportaci≤n de criptografφa fuerte. * De George Foot, george@oxted.demon.co.uk: Schneier escribi≤: "El mundo electr≤nico avanza demasiado deprisa para este ciclo. Un defecto importante en un sistema de comercio electr≤nico puede llevar a la bancarrota a una compa±φa en pocos dφas. Los sistemas de hoy en dφa tienen que anticiparse a futuros ataques. Cualquier sistema de comercio electr≤nico con Θxito podrß permanecer en uso durante 10 a±os o mßs. Tiene que ser capaz de resistir el paso del tiempo: ataques mßs inteligentes, mayor poder de cßlculo y mayores incentivos para trastornar un sistema muy grande. No habrß tiempo para actualizarlo mientras estΘ funcionando." He leφdo cada ejemplar de Criptograma con gran interΘs. Si se me permite como simple suscriptor hacer una observaci≤n, me gustarφa decir que hay una gran necesidad de aprender de las advertencias en el pßrrafo anterior. ┐Pero quΘ principios deben ser adoptados para protegerse del peligro que se predice? Mi criterio es la simplicidad. Descartar los complejos algoritmos que con cada evoluci≤n abren una grieta a travΘs de la cual puede ser examinado exhaustivamente el entorno de trabajo sin lφmite de tiempo. Escoger, en lugar de ello, un sistema simple que s≤lo tenga parßmetros para cada dos estaciones que deseen comunicarse y para cada mensaje enviado, que no publique claves y no tenga ning·n tipo de asociaci≤n con una tercera parte. * De Illuminatus Primus, vermont@gate.net: Me he dado cuenta de que la principal raz≤n de que la automatizaci≤n plantee un nuevo riesgo es porque el sistema depende cada vez mßs de componentes tontos (comparativamente hablando) antes que de los humanos. Un peque±o y aislado programa normalmente no reconocerß cuando cambie repentinamente la direcci≤n del flujo monetario porque los peque±os y aislados programas no aprenden de sφ mismos como reconocer el fraude. Sin embargo los humanos, irracionablemente, a veces esperan que lo hagan. La cura es, para la mayor parte de la gente, pasar el tiempo traduciendo los sistemas de alerta a los que estßn acostumbrados los humanos en lenguaje comprensible por las mßquinas. Por ejemplo, Visa me avisa cada vez que un cambio sospechoso es detectado en mi patr≤n de gastos. Es algo parecido a tener un amigo en el banco vigilando mi dinero, pero en realidad son s≤lo unas pocas comprobaciones realizadas en una fracci≤n de segundo por un ordenador en alguna parte. La automatizaci≤n nos proporciona tambiΘn un gran beneficio: los nuevos agujeros de seguridad en el sistema pueden ser solucionados en muy poco tiempo. Los sistemas centralizados se benefician del momento en que el agujero es reparado y los sistemas descentralizados lo hacen del momento en que la soluci≤n se propaga. Creo que se puede hacer una buena argumentaci≤n sobre c≤mo los actuales sistemas dependientes de los humanos realmente pueden ser peores que los sistemas digitales. Por ejemplo, s≤lo hay que observar los problemas que trajo la introducci≤n de un nuevo valor monetario en Estados Unidos para detener el fraude. Los humanos, la mayorφa de las veces, pueden tardar mßs tiempo en adaptarse a una nueva situaci≤n que el tiempo necesario para transmitir un nuevo c≤digo de autentificaci≤n alrededor del mundo millones de veces. Quizßs hay un gran dilema alrededor de esto: la necesidad de nodos individuales para volverse mßs inteligente. Si mi tarjeta de crΘdito fuese realmente un peque±o terminal que me permitiese saldar mis recibos pendientes, quizßs el fraude a travΘs de mi tarjeta serφa mßs difφcil de llevar a cabo. Quizßs si los coches tuviesen medidores en la tapa del dep≤sito de gasolina, las gasolineras no podrφan enga±ar a la gente tan fßcilmente. Y quizßs, si los mercados intercambiaran moneda digital en lugar de dinero impreso, la falsificaci≤n no habrφa tardado dΘcadas en descubrirse. ----------------------------------------------------------------- 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. CriptoGRAMA s≤lo puede ser redistribuida de forma completa (esta nota incluida). KRIPT╙POLIS http://www.kriptopolis.com Equipo de Traducci≤n: * Juan De Miguel Hernßndez <jdmiguel@kriptopolis.com> * Isidre MarquΘs Serret <ismase@mx3.redestb.es> * Juan Ruiz de Gauna Gorostiza <juancruz.ruiz@si.upna.es> * JosΘ Luis Martφn Mas <jlmartin@lander.es> * Antonio Muntaner <mmg@balears.net> * Eduardo Vßzquez Palacios <dronos@bigfoot.com> * Jaime Millßn de Castro <us_jaime@svalero.es> ------------------------------------------------------------------