1999 << Back To criptograma nº 11

C R I P T O - G R A M A ⌐ Bruce Schneier ⌐ Kriptopolis (versi≤n en Espa±ol). http://www.kriptopolis.com/criptograma/cg.html ----------------------------------------------------- N·mero 11 15 de Marzo de 1999 ----------------------------------------------------- SUMARIO: 1. Por quΘ la peor criptografφa se encuentra en sistemas que pasan Anßlisis Iniciales 2. Counterpane Systems: investigaci≤n documentada 3. En la ratonera: el terminal de datos de la policφa Motorola MDC-4800 4. Agujero de seguridad en Internet Explorer/Outlook y Office 5. Noticias sobre AES 6. Noticias 7. Novedades en Counterpane Systems 8. RSA-140 factorizado 9. Comentarios de los 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 ---------------------------------------------------------------- 1. Por quΘ la peor criptografφa se encuentra en sistemas que pasan Anßlisis Iniciales ------------------------------------------------------------------ Por Bruce Schneier Traducci≤n: Juan Ruiz de Gauna Gorostiza, juancruz.ruiz@si.upna.es Imaginemos esta situaci≤n: un ingeniero construye un puente. El puente aguanta un dφa y entonces se derrumba. El ingeniero construye otro puente. ╔ste aguanta tres dφas y entonces se derrumba. Entonces, construye un tercero, que aguanta durante dos semanas pero se derrumba durante la primera tormenta. Por tanto, el ingeniero construye un cuarto puente. ╔ste aguanta durante un mes y sobrevive a dos tormentas. ┐Podemos creer que este cuarto puente es fuerte, seguro y fiable? ┐o es mßs probable que estemos esperando a que suceda otro accidente?. Por estrafalario que pueda parecer, este tipo de proceso de dise±o se da continuamente en criptografφa, un campo que estß repleto de personas a las que les encanta dise±ar sus propios algoritmos y protocolos. Con tantos aspirantes a criptoanalistas ahφ fuera, hay espacio para un mont≤n de dise±os endebles. El problema es Θste: cualquiera, no importa su inexperiencia, puede dise±ar un algoritmo que Θl mismo no pueda romper. A pesar de ello, un criptoanalista competente puede romper la mayor parte de estos algoritmos tras una breve revisi≤n; el resto de estos algoritmos logran sobrevivir a la revisi≤n y en la mayorφa de los casos nos vuelven a ser revisados (especialmente fuera del campo militar). Pero el simple hecho de que un algoritmo sobreviva a una revisi≤n inicial no es motivo para confiar en Θl. Yo tuve en cierta ocasi≤n un cliente que deseaba fervientemente crear sus propios algoritmos de cifrado. No tenφa ni preparaci≤n criptogrßfica ni experiencia en dise±o de cualquier otro tipo de algoritmos. ╔l era un dise±ador, solφa decir, no un analista. Por tanto, Counterpane llev≤ a cabo el anßlisis por Θl y rompimos su algoritmo en un dφa. ╔l rehizo el algoritmo, nos lo envi≤ de vuelta y se lo rompimos en dos dφas. Volvi≤ a rehacerlo, volvi≤ a envißrnoslo y volvimos a romperlo. Finalmente, su cuarta versi≤n del algoritmo resisti≤ nuestros intentos de criptoanßlisis... al menos durante las 40 horas especificadas en nuestro contrato. El cliente estaba feliz; por fin habφa logrado tener un algoritmo seguro. Desde un cierto punto de vista, el cliente estaba peor que antes de empezar. Inicialmente Θl tenφa un algoritmo que era claramente defectuoso. Si lo hubiese incluφdo en un producto, no hubiese dispuesto de ning·n anßlisis para mostrar a los potenciales compradores ni hubiese dispuesto de respuestas a preguntas referentes a su seguridad. Si un cript≤grafo competente hubiese echado una ojeada al algoritmo -bien porque fuese p·blico o bien obteniendo el c≤digo mediante ingenierφa inversa- hubiese podido romperlo fßcilmente. Pero despuΘs de que nosotros hubiΘsemos realizado unas cuantas veces el ciclo romper-corregir-romper, termin≤ disponiendo de un algoritmo que no era defectuoso a primera vista. Ademßs disponφa por escrito de un anßlisis que mostraba que no habφamos podido romper el algoritmo en 40 horas de trabajo sobre Θl. Incluso si un cript≤grafo competente hubiese mirado el algoritmo durante unos pocos dφas probablemente no le hubiese encontrado ning·n problema. A menos que el algoritmo fuese usado en alguna aplicaci≤n importante -telefonφa celular, un producto Microsoft, un estßndar Internet- es probable que nunca se le hiciese una revisi≤n mßs profunda. Pero esto no significa que ya no fuese defectuoso, o que no pudiese ser roto empleando el tiempo y los recursos suficientes. Esto no quiere decir que el ciclo romper-corregir-romper sea completamente ineficiente. No lo es. De hecho, es la forma en que la mayor parte de los buenos sistemas criptogrßficos logran mejorar. Consideremos IPSec, el protocolo de seguridad de Internet. Fue creado por una comisi≤n, y es abierto y p·blico, y desde el principio ha sido objeto de una considerable revisi≤n p·blica. Todos sabφan que era un protocolo importante y la gente emple≤ mucho esfuerzo intentando hacer que funcionase bien. Algunas ideas fueron propuestas, rotas y modificadas. Las diferentes versiones fueron codificadas y analizadas. Hubo furiosos debates acerca de sus mΘritos de seguridad, rendimiento, facilidad de implementaci≤n, escalabilidad y uso. DespuΘs de esto, en Noviembre de 1998, se publicaron una serie de RFCs, lo que constituy≤ el siguiente escal≤n en la serie de pasos a seguir para convertir a IPSec es un estßndar Internet. Es imposible reproducir este tipo de anßlisis con un sistema propietario. De todas formas algunas compa±φas lo intentan, lo que nos plantea la siguiente pregunta: ┐Por quΘ intentar desarrollar nuevos protocolos y algoritmos? Generalmente no son mßs rßpidos, ni mßs peque±os, ni mßs eficientes. Simplemente son diferentes. Desgraciadamente, en el mundo de la criptografφa lo diferente es malo. La criptografφa ofrece lo mejor de sφ misma cuando es conservadora y la aproximaci≤n conservadora consiste en elegir un algoritmo que ya haya sido analizado. La advertencia acerca de no poner todos los huevos en una ·nica cesta no se aplica en este caso. La seguridad de un sistema es la seguridad de su componente mßs dΘbil, puesto que el componente mßs dΘbil puede romper todo el sistema. En criptografφa hay seguridad siguiendo a la muchedumbre. Un algoritmo local no puede estar sometido a los cientos o miles de horas de anßlisis a los que se han encontrado sometidos algoritmos como el DES y el Triple-DES. Una compa±φa simplemente no puede movilizar los recursos que se han empleado para resistir los candidatos AES, o el protocolo de seguridad de Internet IPSec. Nadie puede copiar la seguridad que ofrece el algoritmo RSA despuΘs de 20 a±os de revisiones criptogrßficas. Una revisi≤n de seguridad estßndar, aun siendo llevada a cabo por cript≤grafos competentes, tan solo puede demostrar posibles vulnerabilidades; nunca podrß probar la invulnerabilidad. Siguiendo al reba±o puedes hacer uso la experiencia criptoanalφtica de la comunidad mundial, no s≤lo de unas cuantas horas del tiempo de un consultor. Este artφculo apareci≤ originalmente en el n·mero de Marzo de 1999 de la Revista de Seguridad de la Informaci≤n (http://www.infosecuritymag.com). 2. Counterpane Systems: investigaci≤n documentada ------------------------------------------------------------- Por Bruce Schneier Traducci≤n: Jaime Millßn de Castro, us_jaime@svalero.es Comparativa de funcionamiento de los candidatos AES B. Schneier, J. Kelsey, D. Whiting, D. Wagner, C. Hall, y N. Ferguson 2nd AES Candidate Conference, Marzo 1999, pendiente de publicaci≤n. En este documento comparamos el funcionamiento de los principales candidatos AES en una variedad de plataformas comunes: CPUs de 32 y de 64 bits, baratas tarjetas inteligentes de 8 bits y hardware dedicado. Para cada plataforma, hacemos antes algunas observaciones generales en los aspectos relativos al funcionamiento de la plataforma para despuΘs comparar varios candidatos AES y finalmente observar aquellos aspectos especφficos para cada una de los candidatos. http://www.counterpane.com/aes-performance.html 3. En la ratonera: el terminal de datos de la policφa Motorola MDC-4800 -------------------------------------------------------------- Por Bruce Schneier Traducci≤n: Jaime Millßn de Castro, us_jaime@svalero.es Existe un programa para Windows que decodifica las transmisiones de los terminales de datos m≤viles de los coches de policφa. Si alguna vez ha pensado que serφa interesante escuchar las frecuencias de radio de la policφa, deberφa ver lo que ocurre con esos intercambios de datos. El "cifrado" de Motorola no fue dise±ado para asegurar la privacidad, sino que es mßs bien un medio para garantizar la integridad de la transmisi≤n. Bßsicamente se trata de una operaci≤n l≤gica del tipo XOR. El software es gratuito, aunque en la pßgina Web se deja constancia de un aviso: "La decodificaci≤n de transmisiones MDT puede ser ilegal en algunos paφses; compruebe las leyes de su paφs antes de usar este programa". http://www.geocities.com/ResearchTriangle/Facility/7646/ 4. Agujero de seguridad en Internet Explorer/Outlook y Office ------------------------------------------------------------- Por Bruce Schneier Traducci≤n: Antonio Muntaner, mmg@balears.net Aquφ estß la prueba, por si lo dudßbais, de que Microsoft prefiere tratar los agujeros en su seguridad como un problema de relaciones p·blicas, en lugar de arreglarlo definitivamente. Hace poco que Microsoft anunci≤ un plazo breve para arreglar un agujero en la seguridad de IE40 y Word 97. Como se ha comprobado, al final el plazo no ha sido tan breve. En Diciembre de 1997, David Foster descubri≤ un agujero en la seguridad de Office 97. Este fallo permite que cualquier pßgina Web contenga c≤digos ejecutables que se pondrßn en marcha sin avisar al ordenador del usuario. Para cualquiera que conozca Word y VBA (el macrolenguaje de Word 97), este problema es obvio. Foster llev≤ el 'bug' a pßginas Web que informan sobre Internet Explorer y Word e inform≤ del problema. Todavφa estß esperando la respuesta de Microsoft. Al final de 1998, descubri≤ que MS no s≤lo no habφa arreglado el problema en Word 97, sino que el 'bug' tambiΘn estß presente en la versi≤n beta de Word 2000. Envi≤ un mensaje mßs amplio a Microsoft, recibiendo la siguiente contestaci≤n: "Microsoft le agradece su informaci≤n referente a este asunto, pero tratßndose de cuestiones de moderna tecnologφa, todos debemos ser responsables en cuanto a lo que nos bajamos de Internet". Por si no le resulta obvio al instante, se trata de un puro disparate. No fue hasta que Woody Leonhard, gur· de Word e iconoclasta de Office 97, se enter≤ del problema y amenaz≤ con publicar los detalles del agujero en el pr≤ximo n·mero de "Woody`s Office Watch", con una difusi≤n de 140.000 ejemplares, cuando Microsoft, finalmente, hizo algo. Con este acicate, Microsoft public≤, en cuesti≤n de dφas, un parche que estß disponible en su pßgina Web. Descarga de parches: http://officeupdate.microsoft.com/downloaddetails/wd97sp.htm http://officeupdate.microsoft.com/downloaddetails/fm2paste.htm La historia del 'bug', por David Foster: http://www.panix.com/~dfoster/sec/chrono.html Artφculo en Woody┤s Office Watch: http://www.wopr.com/wow/wowv4n3.html 5. Noticias sobre AES --------------------- Por Bruce Schneier Traducci≤n: JosΘ Luis Martφn Mas, jlmartin@lander.es Para aquellos que no hayan prestado atenci≤n al tema, AES (siglas en inglΘs de Estßndar Avanzado de Cifrado) serß en principio el sustituto de DES. Es un algoritmo de bloques de 128 bits que trabaja con claves de 128, 192 y 256 bits. Y estß teniendo lugar un concurso p·blico para determinar c≤mo serß. (Para mßs detalles, ver: http://www.counterpane.com/crypto-gram-9805.html#aes) El primer paso fue la presentaci≤n de algoritmos: El NIST (en inglΘs, Instituto Nacional de Estßndares y Tecnologφa) recibi≤ quince el pasado junio. El segundo paso es la petici≤n de comentarios p·blicos sobre los algoritmos. Para esto, el NIST organiza una Conferencia de Candidatos a AES en Roma la semana del 22 de marzo. El NIST recibi≤ 28 ponencias para la conferencia, y se aceptarßn la mayorφa de ellas. Se pueden leer estos documentos en el website del NIST. No hay verdaderas sorpresas, pero si no puede ir a Roma y le interesa el tema, eche un vistazo. http://csrc.nist.gov/encryption/aes/round1/conf2/aes2conf.htm 6. Noticias ----------- Por Bruce Schneier Traducci≤n: JosΘ Luis Martφn Mas, jlmartin@lander.es El Palm VII (la versi≤n con capacidad de conexi≤n a Internet del PalmPilot) incluirß un sistema de criptografφa de clave p·blica. Certicom ha logrado convencerles de que lo mejor es un sistema de curvas elφpticas. A·n no lo he visto, pero confφo en que serß bueno. http://www.zdnet.com/pcweek/stories/jumps/0,4270,383613,00.html El NIST exporta criptografφa fuerte. íFantßstico! NIST cogi≤ y lo hizo; exportaron criptografφa fuerte al resto del mundo electr≤nicamente. Ver el apΘndice de: http://csrc.nist.gov/encryption/aes/round1/conf2/papers/baudron2.pdf Mßs buenas noticias. El 4 de marzo, Tony Blair declar≤ ante varios ingenieros informßticos que el gobierno no incluirß la obligaci≤n de emplear sistemas de almacenamiento centralizado de claves para conceder licencias de CAs. Al menos algunos paφses hacen caso. Aunque inmediatamente a±adi≤ que les concedφa tres semanas de plazo para encontrar una alternativa mejor -sea lo que sea lo que signifique "mejor" en este contexto-, o si no incluirß la obligaci≤n. http://news.bbc.co.uk/hi/english/business/the_economy/newsid_290000/290902.stm http://news.bbc.co.uk/hi/english/sci/tech/newsid_290000/290964.stm Mientras sigue teniendo lugar un acalorado debate sobre el ID ·nico de Intel y sus planes para usarlo como identificador en Internet, el New York Times informa de que Microsoft utiliza el ID de la tarjeta de red del ordenador (o genera un sustituto) y secretamente lo inserta en documentos de Word y Excel con fines de identificaci≤n. http://www.nytimes.com/library/tech/99/03/biztech/articles/03privacy.html Microsoft ha anunciado que corregirßn esto. http://www.zdnet.com/zdnn/stories/news/0,4586,2221330,00.html http://www.wired.com/news/news/technology/story/18315.html íEh, Estados Unidos tiene un "rey" de la privacidad! La pregunta es si harß o no algo ·til. http://www.zdnet.com/zdnn/stories/news/0,4586,2221341,00.html Bien, creo que es divertido: http://www.nottingham.ac.uk/~ppzmajoc/filks/customs.html El Documento de Consulta del Reino Unido sobre la propuesta de legislaci≤n del comercio electr≤nico estß en la Web en http://www.dti.gov.uk/CII/elec/consfn1.pdf Resumen: http://www.dti.gov.uk/CII/elec/elec_com.html El plazo para comentarios termina el 1 de abril. El Pentßgono afirma que varios ciberterroristas estßn lanzado ataques sofisticados y coordinados -al menos unos cien por dφa- sobre ordenadores militares. Sinceramente, esto me suena a petici≤n de mßs presupuesto. http://www.zdnet.com/zdnn/stories/news/0,4586,2220773,00.html Mientras tanto, el CSI (Instituto para la Seguridad Informßtica) y el FBI publicaron la semana pasada los resultados de sus investigaciones, que demuestran que los ciberdelincuentes causaron mßs de 100 millones de d≤lares en pΘrdidas el pasado a±o. http://www.gocsi.com/prelea990301.htm Si esto sigue asφ, podrΘ olvidarme de las campa±as de publicidad. 7. Novedades en Counterpane Systems ----------------------------------- Por Bruce Schneier Bruce Schneier pronunciarß el discurso inaugural de la V Conferencia Anual de Public-Key Solutions (PKS) en Toronto. El evento tendrß lugar entre los dφas 12 y 14 de Abril en el Hotel Four Seasons y la charla de Bruce tendrß lugar el dφa 12 a las nueve de la ma±ana. http://www.certicom.com/pks99/index2.htm Las diapositivas de la charla estßn disponibles en formato PowerPoint en: http://www.counterpane.com/crypto-flaws.ppt Counterpane Systems darß cuatro charlas en la II Conferencia de Candidatos AES: Nuevos resultados del algoritmo de cifrado TwoFish: http://www.counterpane.com/twofish-aes.html Comparativa de resultados de los candidatos AES: http://www.counterpane.com/aes-performance.html Criptoanßlisis de FROG: http://www.counterpane.com/frog.html Debilidad en claves SAFER+: http://www.counterpane.com/safer.html Y ademßs otra charla en la Conferencia de Cifrado Rßpido por Software: Criptoanßlisis Mod n, con aplicaciones contra RC5P y M6: http://www.counterpane.com/mod3.html Todo esto acontecerß en Roma, el 22 de Marzo. 8. RSA-140 factorizado ---------------------- Por Bruce Schneier Traducci≤n: Isidre Marques Serret, ismase@mx3.redestb.es Conseguido un nuevo rΘcord de factorizaci≤n. Herman J.J. te Riele, y su grupo del CWI en Amsterdam, han anunciado que ellos han factorizado un n·mero de 140 cifras (465 bits). Este n·mero fue uno de los del desafφo de la RSA (RSA-140): el producto de dos grandes n·meros primos y el tipo de n·mero usado en el sistema de criptografφa de la RSA. El trabajo realizado se estima que puede estar sobre unos 2000 mips/a±os. (Un "mips/a±o" es la potencia de cßlculo de un ordenador con una capacidad de 1 mips (mill≤n de instrucciones por segundo) funcionado durante un a±o seguido. Un DEC 11/780 es una mßquina de 1 mips. Un ordenador de gama alta con procesador Pentium II estß sobre unos 200 mips. El superordenador ASCI Red TFLOPS, recientemente instalado en el Laboratorio Nacional de Sandia -presumiblemente para simulacion de explosiones nucleares- con sus 9216 procesadores Pentium Pro, estß sobre unos 1,8 millones de mips). Usaron un algoritmo llamado Number Field Sieve (Cedazo de Campo de N·meros), el mismo algoritmo usado para factorizar el n·mero de 130 cifras del desafφo RSA-130 en 1000 mips/a±os. Y con lo que ellos han aprendido en este proyecto, estiman que si tuvieran que comenzar de nuevo podrφan factorizar el n·mero del RSA-150 en 1500 mips/a±os, y el del RSA-130 en 500 mips/a±os. ┐QuΘ significa esto para la seguridad del sistema RSA? ┐C≤mo afecta a las claves de 512 bits? ┐Y a las de 1024 bits? Nadie estß seguro. Es peligroso extrapolar estos esfuerzos a tama±os de claves mßs grandes. Te≤ricamente, aumentar el n·mero de dφgitos decimales en tres o cuatro dobla el trabajo necesario para factorizar un n·mero empleando este mΘtodo. Asφ que el desafφo RSA-150 requerirφa sobre seis veces el trabajo empleado en el RSA-140. Los n·meros mßs grandes son mucho mßs difφciles de extrapolar. Arjen Lenstra suele resaltar que los procedimientos usados en el Cedazo de Campo de N·meros no se escalan como se podrφa esperar, y que muchos de estos procedimientos simplemente no funcionan para n·meros mßs grandes. No se trata simplemente de un asunto de puros mips; se necesita memoria suficiente para guardar los resultados intermedios. A pesar de que esto es cierto, soy mßs optimista sobre la capacidad para mejorar algoritmos. Simplemente basßndose en este proyecto, ellos estiman que podrφan haber recortado el trabajo para factorizar el RSA-140 en un 25%. QuiΘn sabe quΘ aprenderßn la pr≤xima vez, o la siguiente. La factorizaci≤n se estß consiguiendo cada vez con mßs facilidad. Se consigue mßs fßcilmente mucho mßs rßpido de lo que se habφa anticipado. Yo veo cuatro de razones para esto: + Los ordenadores son cada vez mßs rßpidos. + Estßn cada vez mejor interconectados. + Los algoritmos de factorizaci≤n cada dφa son mßs eficientes. + Los adelantos bßsicos en las matemßticas nos proporcionan + cada vez mejores algoritmos de factorizaci≤n. Usando la tecnologφa y las matemßticas actuales, es imposible plantearse la factorizaci≤n de un n·mero de 1024 bits. Pero no estoy dispuesto a hacer ning·n pron≤stico para ma±ana. Mientras tanto, el pr≤ximo proyecto del grupo es un n·mero de la RSA de 155 cifras (512 bits). Esperan terminar hacia finales de este a±o. Se puede encontrar mßs informaci≤n sobre las investigaciones en factorizaci≤n de n·meros en el CWI, en: http://dbs.cwi.nl/cwwwi/@@owa/cwwwi.print_projects?ID=12 Otra direcci≤n interesante es la de Paul Zimmermann: http://www.loria.fr/~zimmerma/records/factor.html quien ha contribuido tambiΘn al rΘcord del RSA-140. (N≤tese que este NO es Phil Zimmerman.) 9. Comentarios de los lectores ------------------------------ Traducci≤n: Eduardo Vßzquez Palacios, dronos@bigfoot.com De: John Washburn johnwashburn@usa.net Tema: ┐Seguros para la Criptografφa? He disfrutado mucho de mi ejemplar de Febrero de 1999 de Criptograma. Su afirmaci≤n de que la criptografφa como producto comercial es igual que los productos farmacΘuticos en este cambio de siglo es acertada. La criptografφa comercial es similar tambiΘn a la energφa elΘctrica y a las industrias de dispositivos elΘctricos en el fin del siglo. Una industria sigui≤ el camino de las aseguradoras. Otra fue dirigida por la FDA (Food and Drug Administration). Otra (la de telΘfonos) simplemente busc≤ el monopolio. Ahora, con aproximadamente 75 a±os de datos disponibles (FDA), me gustarφa argumentar que el camino de las aseguradoras ha resultado ser el mejor. La incidencia de electrocuci≤n accidental (o deliberada) es estadφsticamente insignificante. Los estßndares de dispositivos elΘctricos han sido constantemente ampliados. Por ejemplo, un producto que ha pasado los estßndares de las aseguradoras en 1945 puede fallar fßcilmente con los estßndares de 1995. La FDA mata (o, mßs exactamente, permite morir) a mßs de 25.000 personas cada a±o. Esto no incluye sobredosis de medicamentos, recetas mal escritas, recetas incorrectas o reacciones imprevistas a los medicamentos. 25.000 personas es la cifra mßs conservadora sobre la gente que se cree que muere por no existir tratamiento mΘdico (a·n sin aprobar por la FDA). Esto es simplemente porque a la FDA no le importa c≤mo fallezcas, con tal de que la muerte no sea por un mΘtodo aprobado por la FDA. Llevando esta explicaci≤n al terreno de la criptografφa, ┐c≤mo puede optar la industria criptogrßfica por el modelo de las aseguradoras? La ·nica forma que yo veo es un seguro de responsabilidad. Por ejemplo: yo vendo criptografφa y envφo mis productos a la "Wausau Insurance" para contratar un seguro de responsabilidad. Wausau Insurance inspecciona mi sistema. Si rechazo su inspecci≤n, no obtengo la p≤liza. Tras la inspecci≤n, Wausau Insurance me impone una prima. Si la prima es demasiado alta (el producto es demasiado peligroso), renuncio. Pero despuΘs de pagar mi prima, ya puedo a±adir a la publicidad de mis productos: "Un producto criptogrßfico asegurado por una compa±φa criptogrßfica asegurada". La certificaci≤n es una variaci≤n de los seguros de responsabilidad. He escogido Wausau Insurance porque estß especializada en seguros de responsabilidad empresarial y estß cerca de ahφ, en Wausau, Wisconsin. Wausau Insurance no posee ning·n producto de este tipo en este momento. Cualquier compa±φa aseguradora podrφa servir para mi ejemplo. Lo que quiero destacar es que una compa±φa aseguradora es bastante precavida a la hora de conceder una p≤liza de responsabilidad y ·nicamente lo hace despuΘs de la revisi≤n por terceras partes o expertos internos. A su vez, la reputaci≤n y solvencia de una aseguradora harφan la afirmaci≤n "criptografφa potente" fßcil de creer. Esto podrφa ser cierto si la revisi≤n de la criptografφa comercial fuera realizada por completo bajo NDAs. Ademßs, una aseguradora serφa menos sensible a los aspectos de implementaci≤n, uso e integraci≤n con el sistema. Netscape es el principal ejemplo del uso de una criptografφa buena, aunque el sistema falle por completo (PRNG pobre para la generaci≤n de claves de sesi≤n). Ademßs, teniendo una empresa multimillonaria que estß presente en muchos paφses, el apostar por una criptografφa segura no es una mala idea. Para la aseguradora, certificar criptografφa poco segura serφa equivalente a dispensar una serie de talones de reclamaciones. Nota de Bruce: Para un punto de vista contrario, observe la explicaci≤n de Tan sobre c≤mo el modelo de las aseguradoras no funcionarφa para la criptografφa ni los productos de seguridad informßtica: http://www.10pht.com/cyberul.html. Yo estoy de acuerdo con Tan. ----------------------------------------------------------------- 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 Traductores de Kript≤polis: * Juan De Miguel Hernßndez <chili@vuelta-al-mundo.org> * 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> ------------------------------------------------------------------