Fichero original: Snake Oil Warning Signs: Encryption Software to Avoid
Correo electrónico: Matt Curtin

Administrativia

 

Distribución

Se permite la distribución ilimitada de este documento. Procuramos específicamente alcanzar a gente que no sea experta en criptografía o seguridad, pero se encuentren tomando decisiones sobre qué clase de productos criptográficos (o ninguno) usar, tanto para sus organizaciones como para ellos mismos.

El Snake Oil FAQ [Preguntas Frecuentes sobre el Aceite de Serpiente] se publica mensualmente en sci.crypt. alt.security, comp.security, comp.answers y comp.infosystems. Está disponible en PostScript (ideal para imprimir) via web en

http://www.research.megasoft.com/people/cmcurtin/snake-oil-faq.ps

y HTML en

http://www.research.megasoft.com/people/cmcurtin/snake-oil-faq.html
 

Exoneración (Disclaimer)

Los empleadores de los contribuyentes, sin duda, no serán responsables de las afirmaciones aquí expuestas. No hablamos aquí más que por nosotros mismos.

Esta es una compilación de hábitos comunes sobre los vendedores de aceite de serpiente. No puede ser el único método de evaluar un producto de seguridad, ya que puede haber excepciones a la mayoría de estas reglas. De tiempo en tiempo, un vendedor de reputación producirá algo que puede ser realmente bueno, pero lo promocionará con técnicas de marketing. Pero si ves algo que exhibe varias señales de aviso, probablemente estés tratando con aceite de serpiente.

Se han hecho todos los esfuerzos para producir un documento exacto y útil, pero la información que contiene viene sin garantía. Esto es un trabajo en curso: se apreciará cualquier contribución. Si encuentras cualquier error o deseas contribuir, por favor contacta al encargado del mantenimiento de este documento, Matt Curtin

 

Historia del documento

Con el alza del número de productos criptográficos vino un aumento del número de productos ineficientes o simplemente inútiles. Tras alguna discusión sobre esto en la lista de cypherpunks, Robert Rothenburg escribió la primera iteración del Snake Oil FAQ. Matt Curtin tomó el texto inicial y lo convirtió a su estado actual con ayuda de los contribuyentes que se listan (y probablemente otros cuyos nombre faltan por accidente. Perdón por anticipado, si es ése el caso)

 

Contribuyentes

La siguiente gente ha contribuido a este FAQ.
Jeremy Barrett (jeremy@forequest.com)
Steven M. Bellovin (smb@research.att.com)
Matt Blaze (mab@research.att.com)
Bo Dömstedt (bo.domstedt@protego.se)
Gary Ellison (gary.f.ellison@att.com)
(ifersl@ibm.net)
(geeman@best.com)
Larry Kilgallen (KILGALLEN@Eisner.DECUS.Org)
Dutra Lacerda (dutra.lacerda@mail.telepac.pt)
Felix Lee (flee@teleport.com)
Colin Plumb (colin@nyx.net)
Jim Ray (liberty@gate.net)
Terry Ritter (ritter@io.com)
Robert Rothenburg (wlkngowl@unix.asb.com)
Adam Shostack (adam@homeport.org)
Rick Smith (smith@sctc.com)
Randall Williams (ac387@yfin.ysu.edu)
 

Introducción

La criptografía buena es una herramienta excelente y necesaria para casi todo el mundo. Hay disponibles muchos buenos productos criptográficos comercialmente, como shareware, o gratis. Sin embargo, también hay productos criptográficos extremadamente malos que no solamente no darán seguridad, sino que contribuirán a muchas malas concepciones y malinterpretaciones alrededor de la criptografía y la seguridad.

¿Por qué "aceite de serpiente"? El término se usa en muchos campos para denotar algo vendido sin consideraciones acerca de su calidad o habilidad para cumplir la afirmaciones del vendedor. Este término se aplicaba originalmente a los elixires vendidos en espectáculos de medicina errantes. El vendedor afirmaba que su elixir curaría prácticamente cualquier mal que un cliente potencial pudiese tener. Al escuchar las afirmaciones hechos por muchos criptovendedores, "aceite de serpiente" resulta ser un nombre sorprendente apto.

Superficialmente, es difícil distinguir aceite de serpiente del Producto Real: todas las utilidades de cifrado producen un fichero enmarañado. El propósito de este documento es presentar algunas "banderas rojas" sencillas que pueden ayudarte a detectar aceite de serpiente.

Por diversas razones, este documento no menciona productos o algoritmos específicos como "buenos" o "aceite de serpiente."
 

Conceptos básicos

En un esfuerzo para hacer este FAQ más completo, se cubre aquí alguna información básica. El FAQ de criptografía [3] es un tutorial más general sobre criptografía, y debería ser asimismo consultado.

Cuando se evalúa cualquier producto, debes estar seguro de tus necesidades. Para productos sobre seguridad de datos, ¿qué intentas proteger? ¿Quieres un archivador de datos, un complemento [plug-in] para correo electrónico o algo que cifra comunicaciones on-line? ¿Necesitas cifrar todo un disco o solamente unos cuantos ficheros?

¿Y cuán seguro es bastante seguro? ¿Han de ser los datos ilegibles por "espías" durante cinco minutos, un año o cien años? ¿Es el espía la hermanita menor de alguien, una empresa o un gobierno?
 

Criptografía simétrica frente a asimétrica

Hay dos tipos básicos de criptosistemas: simétricos (también conocidos como convencionales o de clave secreta) y asimétricos (de clave pública).

Los cifrados simétricos requieren que tanto el emisor como el receptor tengan la misma clave. Esta clave es usada por el emisor para cifrar los datos, y de nuevo por el receptor para descifrar los datos. El problema es hacer que emisor y receptor compartan la misma clave.

Los cifrados asimétricos son mucho más flexible desde el punto de vista de la administración de claves. Cada usuario tiene un par de claves: una clave pública y una clave privada. Los mensajes cifrados con una clave pueden ser descifrados solamente por la otra clave. La clave pública puede ser ampliamente diseminada, mientras que la clave privada se mantiene secreta.

De este modo, si Alicia desea enviar a Bob secretos, ella simplemente encuentra y verifica la clave pública de Bob, cifra su mensaje con ella, y lo envía a Bob. Cuando Bob reciba el mensaje, usa su clave privada para descifrarlo.

La verificación de las claves públicas es un paso importante. El hecho de no verificar que la clave pública pertenece realmente a Bob daja abierta la posibilidad de que Alicia esté usando una clave cuya clave privada asociada esté en manos del enemigo.

Los cifrados asimétricos son mucho más lentos que sus contrapartes simétricas. Por otro lado, los tamaños de clave generalmente deber ser mucho mayores. Vea la FAQ de criptografía [3] para una discusión más detallada de estos temas.
 

Secreto frente a Integridad: ¿qué estás intentando proteger?

Para muchos usuarios de criptografía basada en ordenador, preservar el contenido de un mensaje es tan importante como proteger su secreto. El daño causado al alterar un mensaje puede a veces ser peor que el daño causado por su revelación. Por ejemplo, puede ser inquietante descubrir que un pirata informático ha leído los contenidos de tu autorización de transferencias bancarias, pero es un desastre que él cambie el destino de la transferencia a su propia cuenta.

El cifrado en sí no protege un mensaje de la alteración. De hecho, hay varias técnicas para cambiar el contenido de un mensaje cifrado sin siquiera conocer la clave de cifrado. Si la integridad de tu mensaje es importante, no confíes simplemente en el secreto para protegerla. Comprueba cómo el vendedor protege los mensajes contra modificaciones no detectadas.
 

Tamaños de clave

Incluso si un método de cifrado es seguro contra ataques analíticos, será vulnerable a ataques de fuerza bruta si la clave es demasiado pequeña. En un ataque de fuerza bruta, el atacante simplemente prueba todas las claves posibles hasta que encuentre la correcta. Cuánto tiempo le lleve dependerá del tamaño de la clave y de la cantidad de potencia de cómputo disponible. Así que cuando intentes proteger datos, debes considerar durante cuánto tiempo deben permanecer secretos y cuánto potencia de cómputo puede usar un atacante.

[1] y [2] ofrecen algunas líneas para elegir una longitud de clave apropiada. Por ejemplo, la tabla 1 muestra el coste de romper claves simétricas mediante fuerza bruta, tal y como se denota en [2]. El mismo informe recomienda insistentemente usar claves simétricas de 90 bits o más.

Como se mencionó antes, los sistemas de cifrado asimétrico típicos requieren claves significativamente más largas para ofrecer el mismo nivel de seguridad que los sistemas simétricos. Comparar longitudes de clave entre algoritmos es chiflado porque algoritmos diferentes tienen diferentes características. Saber el tamaño de la clave es inútil si no sabes qué tipo de algoritmo se usa.

Pero para darte alguna idea de lo que es razonable, la tabla 2, de [2], compara claves simétricas contra un tipo de clave asimétrico: la basada en el "problema de la factorización" o el "problema de los logaritmos discretos." (Los algoritmos basados en el "problema de logaritmos discretos en curvas elípticas" son más resistentes a los ataques de fuerza bruta y pueden usaras claves mucho más pequeñas. En realidad, no tienen que ser mucho mayores que las claves simétricas, por lo que sabemos ahora mismo).

Clave frente a contraseña.

Una "clave" [key] no es lo mismo que una "frase de contraseña " [passphrase] o "palabra de contraseña" [password]. Para resistir ataques, todas las claves posibles deben ser equiprobables. Si algunas claves son más probables que otras, un atacante puede usar esta información para reducir el trabajo necesario para romper el mensaje cifrado.

Esencialmente, la clave debe ser aleatoria. Sin embargo, una (frase de) contraseña generalmente ha de ser fácil de recordar, así que tiene significativamente menos aleatoriedad que lo que sugiere su longitud. Por ejemplo, una frase en inglés de 20 letras, en vez de tener 20*8=125 bits de azar, tienen solamente 20*2=40 bits de azar.

Por eso, la mayor parte de los programas criptográficos convertirán una frase clave en una clave a través de un proceso llamado "hashing" [revoltilleo, o función resumen] o "inicialización de clave" como vector de inicialización. Evita los criptosistemas que se salten esta parte mediante el uso de la contraseña directamente como clave [key].

Evita cualquier cosa que no te permite generar tus propias claves (p. ej. el vendedor te vende claves por correo, o bien las claves están insertadas en la copia de software que compras).
 

Ambiente de implantación

Otros factores que pueden influir en la seguridad relativa de un producto están relacionados con su ambiente. Por ejemplo, en paquetes de cifrado basados en software, ¿hay texto sin cifrar [plaintext] que se escriba en el disco (quizá en ficheros temporales)? ¿Qué hay de los sistemas operativos con la habilidad de intercambiar [swap] procesos de la memoria al disco? Cuando algo que va a ser cifrado borra su contraparte sin cifrar, ¿es el borrado simplemente una eliminación estandar de su nombre en los directorios de contenidos, o ha sido sobreescrito? Si ha sido sobreescrito, ¿lo ha sido lo bastante bien? ¿Es este nivel de seguridad asunto tuyo? ¿Estás guardando claves criptográficos en una máquina multiusuario? La probabilidad de que se pueda acceder ilícitamente a tus claves es mucho mayor, en ese caso. Es importante considerar tales cosas cuando se intenta decidir cuán seguro va a ser (o a no ser) algo que vas a implementar.
 

Señales de aviso contra aceite de serpiente

 

"Confíe en nosotros, sabemos lo que hacemos"

Tal vez la mayor señal de aviso de todas es el mensaje de "confíe en nosotros, sabemos lo que hacemos" que se transmite, bien directa, bien implícitamente por parte del vendedor. Si el vendedor está preocupado con la seguridad de su sistema después de describir exactamente cómo funciona, ciertamente no tiene objeto. Al margen de que te lo digan o no, la gente lista se lo figurará. Los malos que persiguen tus secretos (especialmente si eres un blanco atractivo como una gran empresa, banco, etc.) no son estúpidos. Se figurarán cuáles pueden ser los puntos flacos. Si el vendedor no te dice exacta y claramente lo que pasa dentro, puedes estar seguro de que está ocultando algo, y que el único que sufrirá como resultado de ello serás tú, el consumidor.

Tecnocháchara

Evita el software que use algoritmos secretos. Esto no se considera un medio seguro de proteger datos. Si el vendedor no confía en que su método de cifrado pueda soportar un escrutinio, debes tener cuidado en no confiar tú tampoco.

Una excusa común para no revelar un algoritmo es que "los hackers podrían intentar reventar la seguridad del programa." Si bien esta puede ser una preocupación válida, hay que hacer notar que tales "hackers" pueden someter el programa a ingeniería inversa [reverse-engineering] para ver cómo funciona, a fin de cuentas. Esto no es problema si el algoritmo es fuerte y el programa está adecuadamente implementado. Usar un algoritmo de confianza bien conocido, proveer notas técnicas explicando la implementación y poner el código fuente a disposición son señales de que un vendedor confía en la seguridad de su producto. Puedes desmontar la implementación y comprobarla tú mismo. Aunque el algoritmo sea bueno, una implementación pobre hará un producto criptográfico completamente inútil. Sin embargo, un cerrojo que los atacantes no pueden romper aunque puedan ver sus mecanismos internos es ciertamente un buen cerrojo. La buena criptografía es exactamente esa clase de cerrojos.

Nótese que un vendedor que se especializa en criptografía puede que tenga algoritmos de su propiedad, que solamente revelará bajo un acuerdo de no revelación. El criptoproducto puede ser perfectamente adecuado si el vendedor es de buena reputación (¿pero cómo un no experto sabe si un vendedor de criptografía es de buena reputación?). En general, te irá mejor evitando los algoritmos secretos.
 

Descubrimientos revolucionarios

Cuidado con los vendedores que afirman haber inventado un "nuevo tipo de criptografía" o un "descubrimiento [breakthrough] revolucionario." Los verdaderos descubrimientos suelen aparecer en la bibliografía de investigación, y los profesionales del ramo no suelen confiar en ellos hasta después de años de análisis, cuando ya no son tan nuevos.

La fortaleza de cualquier esquema de cifrado se demuestra solamente mediante la prueba del tiempo. Los criptosistemas nuevos son como los productos farmacéuticos nuevos, no como los coches nuevos. Y en algunos casos es peor: si una empresa farmacéutica produce medicamentos de pega, la gente comenzará a ponerse mala, pero si usas criptoproductos de pega, probablemente no tendrás ninguna indicación de que tus secretos no son tan secretos como piensas.

Evita el software que afirma usar "nuevos paradigmas" de la computación, tales como autómatas celulares, redes neurales, algoritmos genéticos, teoría del caos, etc. Sólo porque el software use un método diferente de computación, no tiene por qué ser más seguro (en realidad, esas técnicas son objeto de investigación criptográfica en curso, y nadie ha publicado aún resultados con éxito basados en su uso). Cuidado también con versiones especialmente modificadas de algoritmos conocidos. Esto puede debilitar, intencionadamente o no, el sistema de cifrado.

Es importante comprender la diferencia entre un nuevo tipo de cifrado y un nuevo producto. Meterse en la práctica de desarrollar sistemas de cifrado y productos criptográficos es buena cosa. Pero hacer ambas cosas al mismo tiempo es una tontería. Muchos vendedores de aceite de serpiente presumen de hacerlo, a pesar de la ausencia de conocimientos en tal actividad.
 

Expertos en seguridad, análisis raros y otros certificados inútiles

Cuidado con cualquier producto que afirme haber sido analizado por "expertos en seguridad" sin dar referencias. Siempre busca en la bibliografía. Cualquier sistema de cifrado que usen debería aparecer en referencias académicas. Si no, obviamente no ha sido comprobado lo bastante bien para probar o refutar su seguridad.

No confíes en análisis de periódicos, revistas o programas de televisión, ya que generalmente no tienen criptógrafos para que analicen el software (los piratas informáticos célebres que conocen los sistemas telefónicos no son necesariamente expertos en criptografía).

Y tampoco un algoritmo ha de ser seguro sólo porque un vendedor es una compañía conocida o porque el algoritmo esté patentado.

 

Invulnerabilidad

Algunos vendedores afirmarán que su software es "invulnerable." Esto es exageraciones de marketing, y una señal habitual del aceite de serpiente. Ningún algoritmo es invulnerable. Incluso los mejores algoritmo son atacables mediante fuerza bruta., aunque esto puede no resultar práctico si la clave es lo bastante larga.

Algunas empresas que pretenden la invulnerabilidad de sus productos en realidad tienen serias razones para decir eso. Desafortunadamente, esas razones suelen depender de alguna estrecha definición de lo que significa "vulnerar" la seguridad. Por ejemplo, las libretas de uso único (ver la próxima sección) son técnicamente invulnerables en lo que respecta al secreto, pero solamente si se cumplen varias condiciones importantes y difícil. Incluso entonces, son trivialmente vulnerable ante ataques de texto conocido [plaintext attack] contra la integridad del mensaje. Otros sistemas pueden ser irrompibles solamente si uno de los aparatos de comunicación (como un ordenador portátil) no resulta robado. Así que asegúrate de cuáles son exactamente esas propiedades "irrompibles" del sistema, y comprueba si las partes más vulnerables del sistema ofrecen asimismo una seguridad adecuada.

A menudo, vendedores poco experimentados enarcarán las cejas y dirán "claro que no es invulnerable si haces esto y lo otro." La cuestión es que la naturaleza exacta de los "esto y lo otro" variará de un producto a otro. Elige el que concuerde mejor con tus necesidades operativas sin sacrificar tus exigencias de seguridad.

 

Libretas de uso único

Un vendedor puede afirmar que el sistema usa una libreta de uso único [OTP: One-Time-Pad], que se puede probar invulnerable. Técnicamente, la salida cifrada de un sistema de un sistema OTP puede descifrarse con igual probabilidad a cualquier texto no cifrado del mismo tamaño. Por ejemplo,

El algoritmo o producto X es inseguro

Ojo a cualquier cosa que afirme que los algoritmos o productos de la competencia son inseguros, si no ofrecen evidencias de tal cosa. A veces los ataques son teóricos o imprácticos, requiriendo circunstancias especiales o potencia masiva de computación durante muchos años, y resulta fácil confundir a un no iniciado al mencionar tales ataques.
 

Claves recuperables

Si hay un sistema de copias de seguridad para claves o de depósito de claves [key escrow], ¿tienes tú el control de la copia o tiene alguien más una copia de la clave? ¿Puede un tercero recuperar tu clave sin mucho esfuerzo? Recuerda, no tienes seguridad contra alguien que tiene tu clave.

Si el vendedor afirma que puede recuperar claves perdidas sin usar algún tipo de servicio sobre depósito de claves, evítalo. La seguridad tiene un fallo obvio.
 

Exportable desde EEUU

Si el software está fabricado en EEUU, ¿puede ser exportado? La criptografía fuerte está considerada como munición peligrosa por los Estados Unidos y precisa de aprobación por parte del Departamento de Estado USA antes de que pueda abandonar el país (EEUU no está solo en esto; algunas otras naciones tienen restricciones similar para la exportación de criptografía fuerte). Es posible que, si el software ha sido aprobado para exportación, el algoritmo sea débil o vulnerable.

Si el vendedor no está al tanto de las restricciones a la exportación, evita su software. Por ejemplo, si afirman que el sistema de cifrado IDEA puede ser exportado cuando la mayoría de los vendedores (!y el Departamento de Estado!) afirman lo contrario, entonces el vendedor probablemente carazca de postas suficientes para proveerte de criptografía fuerte.

Debido a las restricciones a la exportación, algunos criptoproductos decentes vienen en dos sabores: solo-EEUU y exportable. La versión exportable estará limitada, probablemente al usar claves más pequeñas, haciéndolo fácil de reventar.

No hay restricciones para importar criptoproductos en los EEUU, así que un vendedor no-EEUU puede ofrecer legalmente una única y segura versión de un producto para todo el mundo.

Nótese que un criptosistema puede no ser exportable desde EEUU aunque esté disponible fuera de EEUU: a veces un sistema se exporta ilegalmente y se instala en un lugar de ultramar.
 

"Calidad militar"

Muchos criptovendedores afirman que su sistema es de "calidad militar." Este es un término sin sentido, ya que no hay un estándar que defina la "calidad militar," aparte de que realmente sea usado por varias fuerzas armadas. Como esas organizaciones no revelan que criptografía usan, no es posible probar o refutar que algo sea de "calidad militar."

Desafortunadamente, algunos buenos criptoproductos usan también este término. Vigila este en combinación con otros indicadores de aceite de serpiente, p. ej. "!nuestro sistema de cifrado con calidad militar es exportable desde EEUU!"

 

Otras consideraciones

Evita a los vendedores que no parezcan comprender nada descrito en la sección "Conceptos Básicos" de antes.

Evita cualquier cosa que permita a alguien con una copia del software tener acceso a ficheros, datos, etc. sin necesitar algún tipo de clave o contraseña.

Ojo con productos diseñados para una tarea específica, como el archivo de datos, y tiene el cifrado como característica adicional. Normalmente es mejor usar una aplicación de cifrado para la encriptación, en vez de alguna herramienta diseñada para otro fin que añade el cifrado como un extra.

Ningún producto es seguro si se usa incorrectamente. Puedes ser tú el eslabón más débil de la cadena si usas un producto sin cuidado. No confiés en que el producto sea a prueba de tontos, y ojo con cualquier producto que pretenda serlo.

La interfaz no lo es todo: la facilidad de manejo es importante, pero alerta contra cualquier cosa que ponga demasiado énfasis en la facilidad de uso sin las consideraciones debidas a la robustez criptográfica.

Glosario

algoritmo

Procedimiento o fórmula matemática. Los algoritmos criptográficos convierten texto normal a y de texto cifrado.

(sistema de) cifrado

Sinónimo de "algoritmo criptográfico"

criptoanálisis

Resolver o "romper" un criptosistema

EAR

Export Administration Regulations [Regulaciones de la Administración sobre la Exportación]. Las reglas bajo las cuales se gobierna ahora la exportación de software criptográfico desde los EEUU.

escrow [depósito de claves]

Una tercera parte capaz de descifrar mensajes enviados de una persona a otra. Aunque este término se usa a menudo en conexión con las propuestas "Clipper" del gobierno USA, no está limitado a la capacidad, bajo orden del gobierno, de acceder a información cifrada a voluntad. Algunas empresas pueden desear que sus empleados usen criptosistemas con características escrow cuando lleven a cabo negocios de la compañía, para que la información pueda ser recuperada en el caso de que el empleada sea incapaz de descifrarla más tarde (o si olvidase su contraseña, se despidiese repentinamente, fuese atropellado por un autobús, etc.). O bien, alguien podría desear que su esposa o abogado fuese capaz de recuperar datos cifrados, etc, en cuyo caso podría usar un criptosistema con capacidades escrow.

vector de inicialización

Uno de los problemas con el cifrado de cosas como ficheros en formato específico (p. ej. los de un procesador de texto, correo electrónico, etc.) es que hay un alto grado de predecibilidad sobre los primeros bytes del mensaje. Esto puede usarse para violentar el mensaje cifrado de manera más fácil que mediante fuerza bruta. En sistemas de cifrado donde un bloque de datos se usa para influir el texto cifrado del siguiente (como CBC), un bloque aleatorio de datos es cifrado y usado como el primer bloque del mensaje cifrado, resultando en un mensaje cifrado menos predecible. Este bloque aleatorio es conocido con el nombre de vector de inicialización. El proceso de descifrado lleva a cabo la función de eliminar el primer bloque, con lo que resulta el texto original.

ITAR

International Traffic in Arms Regulations [Regulaciones sobre el Tráfico Internacional de Armas]. Estas son las reglas por las cuales las municiones, tal y como las define el Departamento de Estado USA, pueden ser (o no) exportadas desde los EEUU. Hasta hace poco, esto incluía la exportación de criptoproductos. La exportación de criptografía está ahora en manos de la Oficina de Administración de Exportaciones, dentro del Departamento de Comercio de EEUU.

clave

Un conjunto de datos que, cuando se introducen en un algoritmo juntamente con el texto cifrado, dará como resultado el texto original (o, cuando se introduce en un algoritmo conjuntamente con el texto no cifrado, dará el texto cifrado).

clave aleatoria de sesión

Esta es una clave temporal generada específicamente para un mensaje. Típicamente, en criptosistemas de clave pública, el mensaje a enviar es cifrado con una clave simétrica generada específicamente para ese mensaje. La versión cifrada de ese mensaje, junto la clave asociada de sesión, pueden entonces cifrarse con la clave pública de receptor. Cuando el receptor descifra el mensaje, el sistema realmente descifrará el mensaje que recibe (que es el texto cifrado y la clave simétrica para descifrarlo), y entonces usar la clave simétrica para descifrar el texto cifrado. El resultado es el texto original. Esto se suele hacer debido a la tremenda diferencia en la velocidad de los sistemas de cifrado simétrico frente a los asimétricos.

Referencias

1. B. Schneier. Applied Cryptography, 2e. John Wiley & Sons. 1996.

2. M. Blaze, W. Diffie, R. L. Rivest, B. Schneier, T. Shimomura, E. Thompson, M. Wiener. ``Minimal Key Lengths for Symmetric Ciphers to Provide Adequate Commercial Security''. Available at ftp://ftp.research.att.com/dist/mab/keylength.ps and http://theory.lcs.mit.edu/~rivest/bsa-final-report.ascii

3. The Crypt Cabal. Cryptography FAQ. Available at http://www.cis.ohio-state.edu/hypertext/faq/usenet/cryptography-faq/top.html.

4. The National Security Agency. The VENONA Project. Disponible en http://www.nsa.gov/docs/venona/venona.html

 

Sobre este documento...

Snake Oil Warning Signs:
Encryption Software to Avoid

Este documento [original] fue generado usando el traductor LaTex2 HTML Versión 96, 1-h (30 Septiembre, 1996). Copyright © 1993, 1994, 1995, 1996, Nikos Drakos, Computer Based Learning Unit, University of Leeds.

Los argumentos en línea de comandos fueron:
latex2html -split 0 -html_version 3.1 snake-oil-faq.tex.

La traducción fue iniciada por C Matthew Curtin el Mie 9 Abri 9 04:16:33 EDT 1997

---

C Matthew Curtin
Wed Apr 9 04:16:33 EDT 1997

---

Traducido por Arturo Quirantes Sierra (aquiran arroba ugr.es)
Vuelta a la sección Informes y expedientes

---