Toda la información contenida en este trabajo se proporciona "tal y como está". Todas las garantías expresas, implícitas o legales sobre la exactitud de la información o su idoneidad para cualquier uso en particular quedan nulas por la presente. Aunque se han hecho todos los esfuerzos posibles para asegurar la exactitud de la información contenida en este trabajo, el autor(es) y contribuidor(es) no asumen responsabilidad alguna por los errores, omisiones o daños que resulten de la información aquí incluida. Esta obra puede ser copiada en cualquier formato impreso o electrónico para usos no comerciales, personales o educativos con la condición de que el texto no sea modificado en forma alguna, y que el copyright y nombre de todos los autores aparezcan en todas las copias.

Sam Simpson garantiza el permiso a distribuir esta obra en formato electrónico en redes de ordenadores, con la condición de que además de los términos y restricciones arribas citados, Sam Simpson y/o los otros autores citados sean notificados de ello y que no se cobre por el acceso a la información tarifa alguna aparte de los cargos habituales por el uso de la red.

Este trabajo puede también ser mencionado, citado o referirse a él (pero no copiado o distribuido excepto en los casos arriba detallados) en publicaciones impresas, servicios on-line, otros medios de comunicación electrónica y de otro tipo siempre que Sam Simpson reciba el crédito debido.

IDEA es una marca registrada por Ascom-Tech AG. PGP y Pretty Good Privacy son marcas registradas por Network Associates, Inc. Todos los demás productos mencionados son marcas registradas pos las respectivas compañías.

Los comentarios, sugerencias y correcciones a este documento son bienvenidas.

Cambios al documento

v1.4 - 18 de Agosto de 1999
Pequeños cambios de gramática y ortografía
Actualizadas las referencias a FIPS186 que pasa a ser FIPS186-1
Las referencias a USENET ahora contienen un enlace a deja.com cuando es posible.
Añadida la sección " ¿Es posible quedarse sin números primos? "
Añadida la sección " ¿Qué hay de las curvas elípticas? "
Añadida la sección " ¿Qué es AES? "
Añadida la sección " ¿Qué es Twofish? "
Añadida la sección " ¿Cuáles son las implicaciones del dispositivo TWINKLE de Shamir en la seguridad de PGP? "
Añadidos detalles a " El debate sobre la clave enorme. "
Añadidos detalles a " ¿Qué es DH / ElGamal? "
Añadidos detalles a " ¿Así que no hay problemas de propiedad intelectual con PGP v5+? "

v1.3 - 16 de Marzo de 1999
Pequeños cambios a numerosas secciones.
Se añadió la sección " ¿Cuáles son las implicaciones de los ataques contra MD5?"
Se añadió la sección " ¿Por qué no usa PGP un cifrado "probadamente seguro"?"
Se añadió la sección " El programa x ofrece claves de 200 bits, ¿es mejor que PGP?"
Se añadió la sección " ¿Así que PGP es perfecto? "
Añadidos detalles a "¿Qué es DH/ ElGamal?"
Añadidos detalles a " ¿Por qué PGP usa primos precalculados para DSS/DH? "
Añadidos detalles a " ¿Por qué son las claves DSS significativamente más pequeñas que las DH?"
Añadidos detalles a " ¿Cuál es más fuerte, RSA o DH/DSS? "

v1.2 -3 de Marzo de 1999
Pequeños cambios en la gramática y ortografía.
Se añadió la sección " ¿Por qué son las claves DSS significativamente más pequeñas que las DH?"
Se añadió la sección " ¿No sufre DSS de canales subliminales?"
Se añadió la sección " Sumario de PGP DH frente a PGP RSA"
Añadidos detalles a " ¿Qué es DH/ ElGamal?"
Añadidos detalles a " ¡¿Por qué PGP usa primos precalculados para DSS/DH?! "
Añadidos detalles a " El debate sobre la clave enorme "
Añadidos detalles a " ¿Qué comparación puede hacerse entre la seguridad de los estándares OpenPGP y S/MIME? "

v1.1 - 27 de Enero de 1999
Se añadió la sección " En relación con RSA, ¿qué son primos fuertes? "
Se añadió la sección " La implementación de DH que usa PGP está basada en Cuerpos de Galois ¿no fueron ya echados abajo?"
Se añadió la sección " ¿Cómo son de "computacionalmente resistentes" las claves simétricas"
Se añadió la sección " ¿Cómo afecta el cifrado múltiple a la seguridad? "
Se añadió la sección " ¿Por qué se firma antes de cifrar? "
Se añadió la sección " ¡Ve el riesgo con una cierta perspectiva! "
Añadidos detalles a "¿Qué es DH / ElGamal?"
Añadidos detalles a " ¿Cuál es más fuerte, RSA o DH/DSS? "
Añadidos detalles a "¿Qué es 3DES? "

v1.01 - 15 de Enero de 1999
Pequeños cambios de gramática y ortografía.
Algunos cambios técnicos, principalmente a las notas.

Tabla de contenidos

1. Introducción 2. Algoritmos de clave pública en PGP

• 2.1. ¿Qué es RSA?
• 2.2. ¿Qué es DH / ElGamal?
• 2.3. ¿Qué es DSS?
• 2.4. ¿Cuál es la probabilidad de producir un número compuesto en lugar de un primo?
• 2.5. ¿Es posible quedarse sin números primos?
• 2.6. ¿Qué tamaño debería tener mi clave asimétrica?
• 2.7. El debate sobre la clave enorme.
• 2.8. ¡¿Por qué usa PGP primos precalculados para DSS/DHH?!
• 2.9. Respecto a RSA ¿qué son primos fuertes?
• 2.10. La implementación de DH que usa PGP está basada en Cuerpos de Galois ¿no fueron ya echados abajo?
• 2.11. ¿Por qué son las claves DSS significativamente más pequeñas que las claves DH?
• 2.12. ¿No sufre DSS de canales subliminales?
• 2.13. ¿Qué hay de las curvas elípticas?
• 2.14. ¿Cuál es más fuerte, RSA o DH/DSS?
• 2.15. ¿Algún avance reciente?
• 2.16. ¿Cuáles son las diferencias de rendimiento entre los cifrados RSA y ElGamal?
• 2.17. ¿Cuáles son las diferencias de rendimiento al firmar con RSA y con ElGamal?

3. Algoritmos hash en PGP

• 3.1. ¿Qué es una función hash?
• 3.2. ¿Que es una "checksum"?
• 3.3. ¿Qué propósito tiene el algoritmo de hash en PGP?
• 3.4. ¿Qué es MD5?
• 3.5. ¿Qué es SHA1?
• 3.6. ¿Qué es RIPE-MD?
• 3.7. ¿Ha sido roto MD5?
• 3.8. ¿Cuales son las implicaciones del ataque contra MD5?
• 3.9. ¿Fue el SHA original roto?
• 3.10. ¿Cuál es más fuerte, MD5, SHA-1 o RIPE-MD?
• 3.11. ¿Qué diferencia de rendimiento hay entre MD5, SHA.1 y RIPE-MD?

4. Algoritmos de cifrado convencional en PGP

• 4.1. ¿Qué es un algoritmo de cifrado convencional?
• 4.2. ¿Cuál es la utilidad de un cifrado convencional en PGP?
• 4.3. ¿Qué es IDEA?
• 4.4. ¿Qué es CAST?
• 4.5. ¿Qué es 3DES?
• 4.6. ¿Ha sido roto 3DES?
• 4.7. ¿Ha sido roto CAST?
• 4.8. ¿Es más fuerte IDEA, CAST o 3DES?
• 4.9. ¿Cómo son de "computacionalmente resistentes" las claves simétricas?
• 4.10.¿Por qué no usa PGP un cifrado "probadamente seguro"?
• 4.11. ¿Qué diferencia de rendimiento hay entre IDEA, CAST y 3DES?

5. Certificados de revocación de claves (KRC)

• 5.1. ¿Qué es un KRC?
• 5.2. ¿Qué nos debe preocupar en relación con la producción de un KRC?
• 5.3. ¿Qué procedimiento se sigue para crear un KRC?

7. Otros asuntos

• 7.1. El anillo de claves privadas - ¿qué contiene y por qué necesita ser protegido?
• 7.2. OpenPGP
• 7.3. La licencia RSAREF
• 7.4. "Presentación forzosa" de claves de cifrado
• 7.5. ¿Rompe DH la red de confianza?
• 7.6. ¿Por qué debería confiar en Zimmerman? ¡No es criptógrafo!
• 7.7. ¿Es seguro el RNG de PGP?
• 7.8. ¿Ha cambiado el modelo de confianza en las recientes versiones de PGP?
• 7.9. ¿Así que no hay problemas de propiedad intelectual en PGP v5+?
• 7.10. ¿De verdad se molesta alguien en comprobar el código fuente de PGP?
• 7.11. A menudo, los mensajes cifrados y cifrados/firmados son menores que el original. ¿Por qué?
• 7.12. ¿Si se desarrollaran los Ordenadores Cuánticos o los basados en DNA, romperían PGP?
• 7.13. ¡PGP debe ser débil! ¡Los EE.UU. permiten su exportación!
• 7.14. El hecho de distribuir el código fuente ¿no disminuye la seguridad?
• 7.15. ¿Qué es un "certificado gubernamental"?
• 7.16. ¿Por qué hubo un retraso en la presentación de PGP v5?
• 7.17. ¿Quién confía en PGP?
• 7.18. ¿Cómo afecta el cifrado múltiple a la seguridad?
• 7.19. ¿Cuáles son las implicaciones del dispositivo Twinkle de Shamir para la seguridad de PGP?
• 7.20. ¿Por qué se firma antes de cifrar?
• 7.21. ¿Qué comparación puede hacerse entre la seguridad de los estándares OpenPGP y S/MIME?
• 7.22. El programa x ofrece claves de 200 bits, ¿es mejor que PGP?
• 7.23. ¿Así que PGP es perfecto?

8. Conclusión

• 8.1. Sumario de PGP DH frente a PGP RSA
• 8.2. ¡Ve el riesgo con una cierta perspectiva!
• 8.3. ¿Y ahora qué? Todavía no estoy convencido
• 8.4. Palabras finales.

9. Lecturas adicionales

10. Notas

11. Acrónimos.

12. Referencias

Colaboradores

En primer lugar, gracias sinceramente a Kurt Muller por proporcionar la sección sobre Certificados de Revocación de Claves y a Robert Munyer quien ha examinado atentamente cada versión de estas FAQ y continúa mejorándola sustancialmente. Muchas gracias a Dan "the" Horne y a Andy Jeffries por corregir las pruebas de este documento cuando aún estaba sin pulir.

Gracias a las siguientes personas que han ayudado (sin saberlo en algunos casos) en la producción o revisión de estas FAQ:

• Adam Back
• Laszlo Baranyi, NAI
• Bob Clements
• Dave Del Torto
• Peter Gutmann
• Don Johnson
• Tom McCune
• John Savard
• Roger Schlafly
• Bruce Schneier
• Bill Unruh

1. Introducción

"La documentación es como el sexo: cuando es bueno, es muy, muy bueno; y cuando es malo, es mejor que nada."
-- Dick Brandon

Este documento intenta responder varias de las preguntas más comunes sobre PGP propuestas en comp.security.pgp.discuss, alt.security.pgp, sci.crypt etc.:

1. ¿Ha sido roto PGP?
   
2. ¿Qué versión de PGP es más fuerte, RSA o DSS/DH?
   
3. ¿Por qué PGP ya no usa RSA como estándar?
   
4. ¿Es PGP criptográficamente menos seguro que S/MIME?
   
5. ¿Por qué PGP usa 3DES? ¿DES fue roto, no es verdad?

El paso de PGP v2.x a la V5+ nos ha traído varios avances importantes. El cambio principal ha sido el mejorar la interfaz de usuario. El otro cambio importante ha sido pasar de claves RSA a las DH/DSS. Ha sido un asunto polémico, pero yo, subjetivamente, pienso se hizo por una buena razón. Ojalá que este documento ayude a explicar la razón de ciertos cambios y dé descanso a las mentes de los usuarios preocupados.

De hecho, al acabar estas FAQ debería estar claro que PGP/NAI tenía que cambiar la implementación de PGP de manera que necesariamente quedarían retiradas las antiguas claves RSA.

Estas FAQ intentan ser objetivas en su enfoque y ofrecer abundantes referencias de materiales presentados por los más eminentes criptógrafos. Algunos podrían argüir que estas FAQ tienen un número excesivo de referencias, pero creo que es necesario permitir a los usuarios comprobar las afirmaciones que hago. Después de todo ¿por qué debería confiar en lo que digo? :-)

Estas FAQ asumen que ha leído previamente (y entendido) el manual de usuario de PGP v6.02 especialmente la sección "Phil Zimmerman sobre PGP". También recomendaría al lector que descargue las RSA FAQ [RSA98], pero sea consciente de que RSA tiene intereses comerciales en la criptografía de clave pública.

Sobre el autor

Sam Simpson es licenciado en Ciencias de la Computación por la Universidad de Hertfordshire y también ha asistido a cursos de postgraduado sobre Seguridad de la Información y Criptografía en la Universidad de Londres.

Está muy involucrado en el proyecto freeware Scramdisk [Scr99], en mejorar la eficiencia en la implementación de Serpent, un candidato AES [Gla99], y como consejero en la revisión crítica de varios productos criptográficos.

Él tuvo el "honor" de ser el primero en distribuir PGP v6.0 fuera de los EE.UU. después de que el programa le fuera enviado anónimamente [WIR98].

Sam es un ardiente defensor de la privacidad y, como tal, se considera a sí mismo "neutral hacia los vendedores" en el camino hacia dicha meta. Actualmente trabaja como Analista de Comunicaciones especializado en seguridad en Internet y previamente ha sido desarrollador de aplicaciones y sistemas.

2. Algoritmos de Clave Pública en PGP

2.1. ¿Qué es RSA?

RSA se anunció en 1978 [RSA78]. La seguridad del sistema RSA se basa en el problema RSA (PRSA). Se conjetura, aunque no ha sido probado, que este problema es equivalente al Problema de la Factorización de Enteros (PFE) [MOV96], [Sti95].

En [MOV96] se define el PRSA así: "dado un entero positivo n que es producto de dos primos enteros impares p y q, un entero positivo e tal que mcd(e,(p-1)(q-1))=1, y un entero c, encontrar un m tal que m^e es congruente con c (mod n)." Básicamente el PRSA implica calcular raíces e-esimas módulo un entero compuesto.

No hay mucho que decir sobre RSA que no esté dicho ya en el manual de PGP o en las FAQ de RSA. [Bon98] resume bien la seguridad del sistema RSA después de 20 años de uso.

Recientemente RSA ha dejado de ser el algoritmo escogido para PGP. Ya no se puede utilizar en la versión freeware de PGP, debido a ciertos problemas (ver secciones posteriores).

La Nota 2 contiene un breve resumen de como se utiliza RSA en PGP actualmente. El lector observador notará que PGP mantiene más parámetros en la clave privada de los estrictamente necesarios, se hace para acelerar los cálculos por medio del Teorema Chino del Resto [Sch96a].

2.2. ¿Qué es DH / ElGamal?

Diffie-Hellman (DH) fue el primer sistema de clave pública abiertamente publicado [DH76] (es más correcto decir que DH es un mecanismo de intercambio de claves) y como tal ha sido objeto de detallados análisis por eminentes criptógrafos.

Diffie-Hellman junto con sus derivados como ElGamal estan cubiertos por la patente U.S. número 4.200.700 que expiró el 6 de Septiembre de 1997.

PGP implementa actualmente ElGamal [ElG85], que es una variante de clave pública del problema de Diffie-Hellman (PDH). Se ha demostrado que el esquema de cifrado de ElGamal es equivalente al PDH. [MOV96], [TY98], [Sti95] - es decir que si puede romper bien ElGamal o bien DH entonces puede también romper el otro (vea Nota 1).

La seguridad del sistema DH se basa en el problema de Diffie-Hellman (PDH). Se conjetura (no se ha demostrado) que es equivalente al Problema del Logaritmo Discreto (PLD) [MOV96], [Sti95], [Odl83].

El PDH es equivalente al PLD bajo la "conjetura de Diffie-Hellman" [Kob94]. Esto asume que es improbable calcular g^ab conociendo sólo g^a y g^b. Citando [Kob94] "...nadie puede imaginar una forma de pasar de g^a y g^b a g^ab sin ser primero capaz de determinar a o b; pero es concebible que dicha forma pudiera existir". Lo anterior presupone que todos los valores se calculan sobre GF(p).

Hay varias desventajas en usar DH frente a RSA:

1. Expansión del mensaje. El tamaño del mensaje cifrado se dobla respecto al original. Esto sin embargo no es un obstáculo real en ElGamal ya que sólo se utiliza para cifrar la clave de sesión de cada receptor.
   
   
2. Fortaleza de la firma. Las implementaciones actuales de DH sólo ofrecen DSS como algoritmo de firmado. Esto limita la longitud de la clave a sólo 1024 bits lo que podría, por si solo, ser insuficiente para la seguridad a largo plazo. Las firmas RSA utilizan una clave de hasta 2048 o 4096 bits (dependiendo de la implementación).
   
   
3. Intensidad computacional. Tanto DH como DSS utilizan más intensamente el tiempo de procesador que RSA. En los procesadores modernos esta diferencia no es apreciable pero en dispositivos de poca potencia (tarjetas inteligentes o pequeños chips), DH/DSS podrían no ser utilizables. Si el tiempo de procesador o el tamaño de la clave son importantes un sistema asimétrico basado en Curvas Elípticas podría ser una mejor elección que tanto RSA como ElGamal.
   
   
4. La necesidad de una "buena" aleatoriedad. El valor aleatorio "k" en DH / DSS necesita ser único e impredecible. Si un adversario obtiene dos mensajes cifrados con el mismo "k" o recupera "k" entonces puede obtener la clave privada [Sch96a] - esto es realmente un fallo catastrófico.

La otra cara de la moneda es que hay varios beneficios en usar DH/DSS frente a RSA:

1. ElGamal está totalmente libre de copyrights y patentes. Esto significa que ElGamal puede ser utilizado globalmente sin necesidad de una licencia. El uso de RSA en EE.UU. y Canadá requiere sin embargo requiere obtener una licencia de RSA Labs si se utiliza en productos comerciales. RSA proporciona licencias gratuitas para una cierta librería RSA, pero hay algunas prohibiciones en la licencia (ver sección "La licencia de RSAREF").
   
   
2. Usando RSA, alguien podría generar un primo falso o de una clase especial que facilitase su factorización. Sin acceso a la clave privada es simplemente imposible comprobarlo. [Sch96a] describe un método de comprobar que los números usados en DSA/DH se calculan aleatoriamente y son de hecho primos.
   
   
3. No es apropiado usar RSA en situaciones en las que la generación de la clave ocurre regularmente (en cada mensaje), como en sistemas de clave efímera [SH97].
   
   
4. RSA ofrece menos seguridad por cada bit de clave que DH/DSS.
   
   
5. DH parece estar basado en una teoría matemática más sólida (ver la sección "¿Algún avance reciente?" para más detalles).
   
   
6. De [Odl99]. Las claves de sesión DH son evanescentes. Usando la aplicación más simple de la generación de claves RSA, Alice crea una clave de sesión y se la transmite a Bob usando la clave pública de Bob. Un "mirón" que pueda coaccionar a Bob posteriormente para que le revele su clave privada puede recuperar el texto completo de la comunicación entre Alice y Bob. Como contraste, si Alice y Bob usan DH para generar la clave de sesión, la destruyen después del fin de la sesión, y no almacenan su comunicación, ni la coacción ni el criptoanálisis permitirán al "mirón" descubrir la información intercambiada.
   
   

DH requiere siempre un Generador de Números Aleatorios (RNG) seguro, pero también lo hace RSA cuando se usa para cifrar claves de sesión aleatorias (como en PGP, S/MIME etc.). Ya está disponible un RNG criptográficamente seguro (ver sección "¿Cómo de seguro es el RNG de PGP? "). Un fallo en el RNG bajo RSA permitiría a un adversario recuperar mensajes individuales, pero un fallo en el RNG usando DH / DSS permitiría recuperar tanto el mensaje como la clave privada.

La nota 3 contiene un breve resumen de como se lleva a cabo DH en PGP.

[Odl99] contiene un resumen excelente del estado actual de los conocimientos sobre DH.

2.3. ¿Qué es DSS?

DSS significa Digital Signature Standard (Estándar de Firma Digital) y se define formalmente en [FIPS186-1] y [ANSI930-1].

DSS emplea los sistemas de clave pública de ElGamal y Schnorr para producir una firma de longitud constante (independiente del tamaño de las claves públicas / privadas). En contraste, la longitud de una firma RSA está en función del tamaño de la clave empleada.

El DSS utiliza la exponenciación módulo un primo p, los exponentes se calculan módulo un primo q. Una firma producida con DSS probablemente permanecerá segura durante al menos 20 años [Odl95]. El sellado de tiempos y el marcaje de documentos se pueden usar junto con DSA si se necesita una verificación de firmas a largo plazo.

Se piensa que DSS es seguro suponiendo que se utilice un buen RNG. Serge Vaudeney tiene un ataque interesante contra DSS que permite un Ataque de Cumpleaños en sólo 2⁷⁴ pasos, en lugar de los esperados 2⁸⁰ cuando se utilizan "claves débiles" [Vau96]. Este ataque no es una preocupación real, y las claves débiles se detectan fácilmente.

2.4. ¿Qué probabilidad existe de obtener un número compuesto en lugar de primo al usar PGP?

Pequeña. Muy pequeña en realidad.

De [PGP97]: la probabilidad de que las rutinas de generación de números primos en PGP v5.0 den como resultado un número compuesto en lugar de primo (es decir que el número pase los tests probabilísticos) para una clave de 1024 bits (es decir un candidato a primo de 512 bits) son 10^-44 (aprox. 2^-146).

Por poner las cosas en perspectiva, la probabilidad de que otro asteroide mata-dinosaurios golpee la tierra HOY son de 2^-36 [PGP97].

2.5 ¿Es posible quedarnos sin números primos?

No.

Por ejemplo, hay aproximadamente 3.7 x 10 ¹⁵¹ primos de 512 bits. Hay aproximadamente 1.5 x 10 ²⁹⁸ primos de 1000 bits - ¿cuántas claves necesitamos? :-)

2.6. ¿Qué tamaño debería tener mi clave asimétrica?

NOTA: de acuerdo con las matemáticas actuales y el conocimiento criptográfico, esta sección se aplica por igual a las claves DH y RSA? (si acaso las claves DH son más seguras pero la diferencia parece poco importante actualmente).

Cuando elegimos una clave asimétrica, estamos limitados por dos principios:

1. Seguridad. Uno de los factores clave en la fortaleza de sistemas como PGP es el tamaño de los pares de claves públicas / privadas.
   
2. Velocidad. Cuanto mayor es la clave, tanto más lentas serán las operaciones de clave pública.
   

Para la mayoría de los usuarios, el principal factor en la selección del tamaño de una clave pública sería la seguridad. La velocidad rara vez será un factor condicionante, debido a las siguientes razones:

1. El algoritmo de clave pública no se usa para el grueso del cifrado sino sólo para cifrar la clave de sesión a cada destinatario.
   
2. Los ordenadores son tan rápidos hoy en día que la diferencia en rendimiento entre firmar o cifrar con una clave de 4096 bits y otra de 512 bits es despreciable.

La siguiente tabla, tomada de [Sch96a] lista las longitudes de clave pública recomendadas para protegerse contra ataques por una sola corporación (¡las claves deberían ser significativamente más grandes para protegerse contra las agencias de inteligencia!):

Tabla 1: Longitud recomendada de claves asimétricas.

Schneier ha comentado posteriormente sobre estas cifras [Sch98e]: "En PGP, por ejemplo, romper el algoritmo simétrico nos facilita leer un mensaje. Romper el algoritmo de clave pública nos permite leer cualquiera."

Necesita considerar lo importantes que son sus mensajes, la "vida" de dichos mensajes (es decir cuanto tiempo necesita proteger los datos) y su probable adversario.

Longitudes de clave de 10.000 bits o más pueden en ocasiones ser necesarias, por ejemplo para proteger las claves de firmar claves que poseen las Agencias de Certificación, o para almacenar datos que deben permanecer en secreto durante un periodo muy largo [Odl95].

Sabemos que las claves de 512 bits han sido inseguras ya hace algún tiempo [Sch96a], [Odl95], [Rob95]; un adversario con los suficientes fondos podría ciertamente romper claves de este tamaño (incluso si tiene que emplear un mes o dos). Realmente, un adversario, ni siquiera tendría que tener fondos, basta con que tenga acceso a una gran red de ordenadores. El adversario podría ser por tanto un fabricante de ordenadores, una gran corporación (usando el tiempo de inactividad de sus ordenadores) o un esfuerzo coordinado. Si existen dudas sobre la capacidad de factorizar una clave de 512 bits, uno sólo tiene que ver que una clave de 456 bits se rompió usando solo 2000 años MIPS [Paa99].

Las versiones modernas de PGP permiten sólo la creación de claves >= 768 bits, así que el usuario poco informado tiene cierta protección contra crear una clave excesivamente débil. Sin embargo la pregunta sigue en pie, ¿cuál es un tamaño "razonable" para la clave?

Personalmente sugeriría crear claves de cifrado asimétrico no menores que 2048 bits. ¿Por qué tan grandes? Bueno, suponiendo que haya avances "razonables" en teoría de números y potencia de cálculo, junto con el crecimiento del cálculo distribuido vía Internet, una clave de 1024 bits sólo ofrecerá una protección garantizada (suponiendo que PRSA/ PLD sean de hecho intratables) durante un periodo de unos 5 años [Odl95]. No se ha realizado ninguna demostración de romper una clave de 768 bits, pero uno debería asumir que ya es posible [Sil97], [Ley99].

Cualquier avance importante en los algoritmos de factorización, velocidad de los ordenadores, potencia de cálculo disponible en trabajos distribuidos etc. afectarían negativamente la seguridad de DH y RSA. Recuerde que los algoritmos más rápidos de factorización y cálculo de logaritmos discretos son ahora subexponenciales - de modo que cada aumento en la potencia de cálculo afecta en buena medida a la seguridad que proporcionan las claves públicas.

Haríamos bien en recordar una de las máximas básicas de la seguridad de la información: "La criptografía trata de hacer que el coste de recuperar un mensaje sea mucho mayor que el valor del mensaje en sí."

Para más detalles sobre el tamaño recomendable de las claves, consulte [Sch96a], [Sch96b]. Un gran ensayo sobre la factorización de enteros es [Odl95].

2.7. El debate sobre la clave enorme.

Cyber-Knights Templar [Cyb99] ha presentado una versión corregida de PGP v5.5 que aporta las siguientes mejoras:

1. Claves RSA de hasta 16.384 bits de longitud. Una firma con una clave de esta longitud ocuparía unos 2,5Kb :-)
   
2. Claves DH de hasta 8192 bits y claves DSS de hasta 2048.
   

Hay algunos argumentos contra el uso de estas claves gigantescas. Algunos afirman (incluyendo Phil Zimmerman) [Zim98b] y Will Price [Pri98] de NAI), que claves de este tamaño son absolutamente inútiles.

No estoy particularmente de acuerdo con el uso diario de claves tan grandes que resultan tediosamente lentas, pero estoy parcialmente en desacuerdo con el argumento de Phil. Si un adversario rompe una clave simétrica de PGP, el adversario puede leer un sólo mensaje. Si el adversario rompe una clave asimétrica, entonces puede leer todos los mensajes, pasados, presentes y futuros (y falsificar firmas si se hace con una clave RSA).

Hay por tanto un argumento razonable para usar claves asimétricas que ofrecen más seguridad que el cifrado simétrico subyacente [Sch98e], [Sim98].

Hay otro hecho que a menudo se pasa por alto: existen ahora algoritmos subexponenciales para factorizar y calcular logaritmos discretos (por tanto el aumento en la potencia de cálculo hace más factible que las claves sean atacadas). Tal aumento de la potencia de cálculo de los ordenadores afecta en un menor grado a la facilidad en romper claves simétricas (pues el problema de romper por fuerza bruta una clave simétrica es exponencial). ¿No sería por tanto sensato ser más conservador (en cuanto a la seguridad) con respecto a las claves asimétricas, especialmente ahora que los bits de clave están "baratos"?

De cualquier modo, si un adversario consigue romper una clave > 3000 (ya sea RSA o DH) hoy, entonces probablemente ha ocurrido bien debido a un importante adelanto matemático o por una implementación defectuosa que haría inútiles claves asimétricas de cualquier tamaño.

Las futuras versiones de PGP utilizarán cifrados de bloque del estándar AES con un tamaño de clave de 256 bits - entonces los usuarios podrán elegir mayores claves. Por ahora, sugeriría utilizar grandes claves sólo en circunstancias extremas.

También se debería recordar a los usuarios que las claves DSS mayores de 1024 bits ya no cumplen el estándar oficial DSS [FIPS186-1] y deberían ser llamadas de otra forma por tanto.

Las "versiones oficiales" de PGP v5+ no utilizarán claves DSS mayores de 1024 bits o claves DH mayores de 4096 bits.

La siguiente tabla señala las versiones de PGP que son compatibles o incompatibles con ciertos tamaños de claves [Cyb99b]:

2.8. ¡¿Por qué usa PGP primos precalculados para DSS/DH?!

Una preocupación que existía cuando PGP v5 se publicó por primera vez fue el uso de valores precalculados o "enlatados" para el cuerpo finito y el generador de este cuerpo (p y g respectivamente) en DH, o p y q en el caso de DSS.

Es bastante aceptable el uso de valores públicos, precalculados para estos valores [Sch96a], [FIPS186-1], [MOV96], [Kob94], [Sti95]. Yo también recomendaría al usuario preocupado, la lectura de [Sch97a].

También si está preocupado por esto puede desactivar "Generación rápida de claves" (esté preparado para esperar más tiempo a que las claves se generen).

El problema de usar primos "enlatados" es que la tabla de valores para p necesita ser calculada una sola vez para el cuerpo. El romper claves individuales en este cuerpo es una operación relativamente rápida. Por supuesto, calcular una base de datos de factores de la base de los logaritmos para unos parámetros razonables es aún imposible, pero parece prudente desde la perspectiva de la seguridad no usar primos precalculados para claves de larga duración [MOV96].

O en román paladino (ver [BB99]): "Con ElGamal, por ejemplo, la parte más costosa de calcular de la clave es el módulo primo público. Un grupo de claves puede compartir un módulo público común sin que haya consecuencias negativas para la seguridad, dejando aparte de que la clave resulta ser un blanco más apetecible para ataques por precálculo."

Mi recomendación: desactive la opción "Generación Rápida de Claves" cuando se creen claves de larga duración... Puede llevar más tiempo, pero ofrece más seguridad a largo plazo contra un ataque coordinado.

2.9. ¿Con relación a RSA, qué son primos fuertes?

Históricamente, era deseable seleccionar primos fuertes (p y q) para usar con el sistema RSA. Estos primos fuertes ayudaban a defenderse contra el algoritmo de factorización p-1 de Pollard. Más recientemente sin embargo se han descubierto algoritmos de factorización más rápidos que funcionan igual de bien con los primos fuertes, así que no hay ninguna ventaja real en usar estos primos fuertes.

PGP no usa primos "fuertes", una decisión con la que estoy de acuerdo por las siguientes razones:

1. No ofrecen seguridad extra contra los modernos algoritmos de factorización.
   
2. Estos primos "fuertes" pueden ser de hecho más susceptibles a los ataques modernos. Por ejemplo es estándar ANSI X9.31-1997 detalla ciertos criterios que deberían ser usados para crear los primos con los que calcular el módulo RSA. Uno de los criterios de hecho hace que el módulo sea más fácil de factorizar mediante la SNFS [Sil97]!
   

Puede que sea necesario en el futuro confiar en parámetros "fuertes" al usar el sistema RSA - pero de momento, la longitud del número primo es bastante más importante que su estructura [Sil97], [Sch96a], [MOV96].

2.10. ¿La implementación de DH en PGP se basa en los Cuerpos de Galois, no fueron echados abajo?

No. Hay dos tipos de Cuerpos de Galois generales con importancia en criptografía, GF(p) con p primo, y GF(2ⁿ) donde n es aproximadamente 2000. Claramente, el Cuerpo de Galois GF(p) ofrece mejor seguridad para el mismo tamaño de parámetros.

Desdichadamente estos dos sistemas, aunque relacionados, se tienden a meter "en el mismo saco" - sin embargo la teoría en uno de los cuerpos no es necesariamente aplicable en el otro.

De cualquier modo, PGP implementa Diffie-Hellman sobre GF(p) que, como veremos después, sigue siendo seguro.

Si todavía estás interesado en la relación entre GF(p) y GF(2ⁿ) recomiendo calurosamente [Odl83].

2.11. ¿Por qué son las claves DSS significativamente más pequeñas que las DH?

Claramente, si las claves DH pueden tener hasta 4.096 bits mientras que las claves DSS pueden alcanzar tan solo 1024 bits, hay una seria disparidad entre la fortaleza que ofrecen ambas claves.

Se penso en principio, que las claves DSS podían ofrecer más seguridad combinando las firmas de ElGamal y Schnorr pero esto es falso ya que romper ElGamal claramente rompe también DSS.

Así que, ¿por qué ese contraste? Bien, en primer lugar, PGP simplemente implementa el Estándar de Firma Digital DSS como se detalla en [FIPS186-1]. DSS es el estándar de facto para las firmas digitales, y PGP lo implementa hasta la máxima fortaleza posible dentro de los límites del estándar (es decir con p hasta 1024 bits). Una implementación de "DSS" con p mayor de 1024 bits se apartaría del estándar.

En segundo lugar, fijémonos en el propósito de las claves de cifrado y firmado. El cifrado se usa para esconder los datos - si la clave se viera comprometida todos los mensajes serían legibles haciendo el cifrado inútil. Esto es un problema real; un día será posible leer los mensajes que se creyeron seguros con claves de 1024 bits.

Las claves de firmado se usan para ofrecer integridad, autenticación y no repudio. La capacidad de "romper" una clave DSS permitiría a un adversario falsificar firmas digitales. Las claves DSS de 1024 bits serán seguras durante varios años, ¿y luego qué? Bien, el sellado de tiempos y los métodos de marcaje de documentos pueden ser usados para "probar" que una firma digital antigua es genuina (podría haber sido falsificada utilizando lo que será la tecnología en uso). Esto, suponiendo que no haya avances inesperados en el cálculo de logaritmos discretos.

Así que vemos que romper una clave de cifrado es catastrófico, mientras que romper una clave de firmado en algún momento futuro no es tan desastroso.

De todas maneras, a mí personalmente me gustaría tener la opción de un mecanismo más fuerte de cifrado; firmas con claves ElGamal con la misma longitud que las claves de cifrado serían una buena elección. Hago notar que las firmas con claves ElGamal están en el estándar OpenPGP, pero no han sido implementadas en la práctica.

Es interesante sin embargo, observar que hacer las claves de cifrado más largas no necesariamente hacen que el esquema de firma sea más fuerte. Notemos que las funciones hash generalmente aceptadas (MD5, SHA-1 y RIPEMD) sólo ofrecen una seguridad de unos 160 bits (128 en el caso de MD5). Si uno utiliza una clave ElGamal o RSA de 4.096 bits con una de estas funciones de resumen (hash), ¿estamos realmente incrementando sustancialmente la seguridad? Yo sugeriría que no; un "ataque de cumpleaños" se podría llevar a cabo contra una de las funciones hash en 2⁸⁰ operaciones (o peor, 2⁶⁴ con MD5) por tanto, contra ciertos ataques, aumentar los bits de la clave asimétrica en el esquema de firmado podría dar al usuario poco informado una falsa impresión de seguridad.

DSS es un esquema de firmado "equilibrado"; la función hash cae ante un ataque en 2⁸⁰ operaciones, y la clave de firmado permite también algunos ataques que emplean 2⁸⁰ operaciones. Compare esto con las rechazadas claves de las versiones 2.x, donde el esquema de firmado cae en 2⁶⁴ operaciones mientras la clave RSA ofrece una seguridad mayor de 2¹²⁸ operaciones. ¿Es esta discrepancia tan grande útil?

Uno podría, con cierta razón, argumentar que las claves asimétricas deberían proporcionar más seguridad que la función hash subyacente; romper por fuerza bruta la función hash sólo permite al adversario falsificar un mensaje, mientras que romper la clave asimétrica permitiría falsificar muchas firmas, así que el argumento de "seguridad equivalente" es un tanto débil.

Will Price [Pri98] ha señalado que la comunidad criptográfica necesita elegir (o crear si es necesario) primitivas criptográficas más fuertes. El proceso AES está seleccionando un algoritmo de cifrado de bloques y es de suponer que NIST/NSA se sacará un estándar de hash más fuerte "del sombrero".

Para leer más que lo expuesto hasta aquí, recomiendo "El futuro de la factorización de enteros" por A.M.Odlyzko [Odl95] - que también trata las longitudes de las claves basadas en DHH/ ElGamal.

La red de confianza se basa propiamente en el uso de firmas digitales, el usuario firma la clave pública de otro usuario con su clave privada para crear un "certificado". El uso de un esquema de firmado débil haría que la red de confianza en las nuevas versiones de PGP fuera insegura [Bac99b]. ¿Estamos ya en ese caso? No. ¿Lo estaremos? Sí, algún día.

[Mun99] ofrece un argumento interesante por el que las claves de firmado pueden ser menores que las claves de cifrado: "Si una agencia altamente secreta tuviera la habilidad de romper claves de 1.024 bits, mucho antes de que la comunidad criptográfica lo creyera posible, entonces podrían leer montones de tráfico cifrado, pero sólo mientras el resto del mundo creyera que las claves de cifrado de 1.024 bits son seguras. Podrían usar esta tecnología para leer mensajes cifrados rutinariamente, y nadie lo sabría nunca. Pero si lo usaran para falsificar firmas rutinariamente, esto se notaría ciertamente. El mundo pronto se daría cuenta de que 1.024 bits no son seguros, y todo el mundo se pasaría a las claves de 2.048 bits para el cifrado y también para la autenticación. En otras palabras, usando su capacidad de falsificar, se arriesgan a perder su capacidad de descifrar.

2.12. ¿No sufre DSS de canales subliminales?

Un canal subliminal permite que se filtre información o datos sobre una clave a un adversario. Por ejemplo una versión modificada de PGP podría ser distribuida de modo que permite a una tercera parte recoger detalles obre tu clave privada utilizando las firmas digitales.

¿Inverosímil? ¡No! Tal sistema existe: [YY96].

DSS puede sufrir de canales subliminales, pero también RSA, ElGamal, Diffie-Hellman e incluso los cifrados simétricos [YY96]. Si crees que el software que estás usando podría estar explotando canales subliminales es importante que compruebes el código fuente para asegurarte que los parámetros de CP se generan de forma aceptable. Esto es sencillo con PGP, ya que el código fuente está disponible para su inspección, pero podría ser imposible con otros programas.

Simmons ha comentado que DSS "...proporciona el escenario más hospitalario para las comunicaciones subliminales que se ha descubierto hasta la fecha" (también citado en [Sch96a]). Se ha demostrado posteriormente lo contrario [AVPN96]: "...el diseño de DSA no maximiza la utilización encubierta de sus firmas, sino que lo minimiza."

2.13. ¿Qué hay de las curvas elípticas?

Los sistemas de curva elíptica se especifican en ANSI x9.62 y x9.63 e IEEE P1363.

Las curvas elípticas fueron propuestas por primera vez para ser usadas en aplicaciones criptográficas en 1985 de forma independiente por V.S.Miller y N.Koblitz. Las curvas elípticas en sí llevan estudíandose durante muchos siglos y están [Kob94] entre los objetos más ricamente estructurados y estudiados de la teoría de números.

Las curvas elípticas son interesantes porque presentan las siguientes ventajas sobre DH y RSA:

1. Tamaño de clave. Una clave de curva elíptica tiene habitualmente unos 160 bits, mientras que las claves DH y RSA deben tener 1.024 bits para conseguir el mismo nivel de seguridad.
   
   
2. Velocidad. Los sistemas de curva elíptica son significativamente más rápidos que los sistemas basados en RSA o DH (ante igual nivel de seguridad, no misma longitud de clave).
   
   

Existe un algoritmo subexponencial para resolver una clase de curvas elípticas conocidas como "curvas supersingulares", aunque esas curvas se evitan fácilmente. Para la gran mayoría de las curvas, el único algoritmo aplicable es exponencial. Esto significa que las claves de CE pueden ser notablemente más pequeñas que las claves DH o RSA y proporcionar un nivel esperado de seguridad similar.

Incluso aunque no todos los métodos de factorización pueden ser usados para romper los sistemas de logaritmos discretos, es concebible que un nuevo algoritmo de factorización o de LD se pudieran usar para romper tanto RSA como DH. Esto crea la necesidad de diversificación en el diseño de los algoritmos de CP [Len96]. O más sencillamente, si RSA o DH resultan rotos por un avance matemático, es altamente improbable que los sistemas basados en curvas elípticas resulten también afectados.

OpenPGP [RFC2440] apoya la implementación de la tecnología de CE. El algoritmo de CP ID 18 se reserva para "Curvas Elípticas", mientras la ID 19 se reserva para "DSACE" que es una implementación de DSA sobre curvas elípticas.

[Kob94] señala que "Es probable que el PLD sobre curvas elípticas demuestre ser más intratable que la implementación de DSA sobre curvas elípticas. Por supuesto, sólo el tiempo lo dirá.

Se ha mostrado que PDHCE es totalmente exponencial si PLDCE lo es. Es este un resultado fundamental pues nunca se ha encontrado una equivalencia así para RSA / PFE o PDH / PLD [Joh99a].

Recientemente, el NIST ha especificado una colección de curvas elípticas para el uso del gobierno de Estados Unidos, lo que es una indicación de que confían hasta cierto punto en la criptografía de curva elíptica [NIST99a].

De momento no veo ninguna razón poderosa para cambiar a un sistema asimétrico de curva elíptica, aunque algún día podría existir dicha razón. Desde la perspectiva de la seguridad me parece prudente ser precavido en cuanto al uso de curvas elípticas. Cuando se usen, se recomiendan tamaños de clave de al menos 300 bits incluso para una seguridad moderada [Odl99].

Sugiero a los interesados en las curvas elípticas que consulten el excelente texto de Koblitz [Kob94] o el breve resumen de [Odl99].

2.14. ¿ Cuál es más fuerte, RSA o DH/DSS?

Ambos están basados en problemas supuestamente intratables sometidos al escrutinio de los mejores matemáticos y criptógrafos. El comportamiento ante cantidades arbitrariamente grandes de datos de RSA y DH es similar pero en la práctica las claves RSA parecen más vulnerables [Sch98f].

Bob Silverman, quien es Senior Research Scientist de RSA Labs, ha dicho [Sil96a]: "Estoy lo suficientemente pagado de mí mismo como para decir que la NSA no puede reventar RSA o los logaritmos discretos".

Es de hecho, un poco más difícil calcular logaritmos discretos módulo un primo adecuado que factorizar un entero "complicado" del mismo tamaño - así que RSA parece ligeramente más débil que PDH [Odl95] , [Sch97c]. De [Sch99]: "Los usuarios de RSA deben escoger una clave mayor que los que usan DH sobre GF(p) si quieren una seguridad equivalente."

Se piensa que es posible, aunque poco probable, que exista un procedimiento polinomial para factorizar grandes números o calcular logaritmos discretos. Existe también la posibilidad de que PRSA o PDH pudieran ser rotos sin tener que resolver el problema difícil subyacente (PFE y PLD respectivamente).

Discutiendo el PLD y PFE, [RSA96a] afirma: "Esto sugiere que los grados de dificultad de ambos problemas están íntimamente ligados, y que cualquier descubrimiento, sea positivo o negativo, afectará a ambos problemas igualmente.

Y citando [Sch96a]: "El cálculo de los logaritmos discretos está muy relacionado con factorizar. Si puedes resolver el PLD entonces puedes factorizar."

Otra cita relevante [Wie98]: "El factor más importante al elegir una tecnología de clave pública es la seguridad. Basándose en los mejores ataques conocidos, RSA de 1024 bits, DSA y DH de 1024 bits y las curvas elípticas de 170 bits ofrecen niveles comparables de seguridad."

Es también interesante [Odl83]: "En general, aunque existen algoritmos de factorización que no se generalizan al cálculo de logaritmos discretos (el algoritmo Schnorr-Lenstra por ejemplo), lo contrario no es cierto. Por tanto parece bastante seguro decir que los logaritmos discretos son al menos tan difíciles como factorizar y seguramente seguirá siendo así." O, en español, todos los algoritmos conocidos para resolver el PLD se pueden aplicar al PFE, pero no al revés en general.

Si DH se rompe resolviendo el PLD entonces RSA también caerá, ya que si se sabe calcular logaritmos discretos entonces se puede factorizar (esa es la base del algoritmo de factorización cuántico de Shor [Sho94]). Por tanto, el PLD parecería más fuerte que el PFE, pues factorizar no nos permite calcular logaritmos discretos [MOV96]. Más rigurosamente; "el problema de Diffie-Hellman en Z ^*_n es al menos tan difícil como el problema de factorizar n."

No conozco nada en la literatura que afirme o prediga que, bien DH, bien RSA sean significativamente menos seguro que el otro dada una correcta implementación y selección de parámetros.

Desde la perspectiva de la seguridad, un buen argumento para usar claves DH/DSS es el hecho de que las claves de cifrado y firmado son ahora autónomas. Así, si alguien se las arregla para obtener tu clave DH privada (por ejemplo por fuerza bruta o por una orden judicial) serán capaces de leer todo el correo dirigido a ti. No serán capaces de falsificar firmas sin embargo. Compárese esto a RSA, donde divulgar una clave permite a alguien tanto leer correo como falsificar firmas. Vea la discusión adicional en "Presentación forzosa de claves de cifrado.".

PGP versión 6.0 proporciona la capacidad de crear y revocar nuevas claves de cifrado sin sacrificar tu clave maestra de firmado y las firmas producidas con ella. Esta característica no hubiera sido posible con las antiguas claves RSA.

En palabras de Cylink [CYL98b]: "Los sistemas basados en Diffie-Hellman pueden ser usados en lugar de RSA en cualquier aplicación que requiera criptografía de clave pública."

2.15. ¿Algún avance reciente?

La teoría de números es un área que cambia rápidamente. Recientemente, varias demostraciones y descubrimientos han afectado a los problemas en los que tanto DH como RSA están basados.

Obviamente, la demostración de que RSA o DH son computacionalmente equivalentes al problema subyacente (PFE y PLD respectivamente) aumenta drásticamente la confianza que deberíamos poner en el sistema de llave pública.

Destacaré brevemente los escritos relevantes a intentaré explicar como afectan a la seguridad de los algoritmos asimétricos utilizados en PGP.

"Diffie-Hellman generalizado módulo un compuesto no es más débil que la factorización" [BBR98]
Implicaciones: Algunas clases del PDH no son computacionalmente más débiles que el PFE.

"Reventar RSA puede no ser equivalente a factorizar." [BBR98]
Implicaciones: proporciona indicios de que algunas formas de RSA pueden no ser equivalentes al PFE.

"Sobre la complejidad de romper el protocolo de Diffie-Hellman" [MW96]
Implicaciones: demuestra que algunas clases del PDH son equivalentes al subyacente PLD.

Básicamente, se han dado varios pasos significativos para demostrar que la seguridad del PDH es equivalente al PLD, mientras que podría no existir la demostración de la equivalencia entre RSA y el PFE. Esto podría tener consecuencias en la seguridad a largo plazo de las claves basadas en RSA.

2.16. ¿Qué diferencias de rendimiento existen entre el cifrado RSA y ElGamal?

Tiempos de cifrado (en milisegundos, usando una Sparc II) tomado de [Sch96a]:

Los mensajes se cifran una vez pero pueden ser descifrados muchas más - por tanto ElGamal se considera mejor en términos de eficiencia.

Observe que el cifrado asimétrico se utiliza sólo para cifrar la clave aleatoria de sesión - así que el impacto en el proceso es despreciable. Estas cifras pueden tener impacto en entornos de bajo coste (tarjetas inteligentes) o de gran volumen de trabajo.

2.17. ¿Qué diferencias de rendimiento existen al firmar con RSA o DSS?

Los tiempos de firmado digital (en milisegundos en un Pentium Pro 200 MHz) según [Wie98]:

Tabla 3: Comparación de las velocidades de las firmas asimétricas.

Podemos ver que producir firmas de la misma longitud usando el esquema DSA es mucho más rápido que con RSA. Verificar una firma es bastante más rápido con RSA.

Las firmas se crean una vez, pero pueden verificarse muchas más - por tanto RSA se considera mejor en términos de rendimiento.

En el mundo real, la diferencia entre estos dos sistemas pasará inadvertida. Es más probable que sea un problema en sistemas de bajo coste (tarjetas inteligentes por ejemplo) o en sistemas de gran volumen de trabajo.

3. Algoritmos hash en PGP

3.1. ¿Qué es una función hash?

Una función hash criptografica toma un mensaje de longitud arbitraria como entrada y produce una salida de longitud fija. La entrada es usualmente un fichero o mensaje. La salida de la función hash se llama Resumen del Mensaje (o Condensado del Mensaje), valor hash o huella digital del mensaje.

Por su misma naturaleza, las funciones hash aplican muchos mensajes en un mismo valor - es decir que habrá ciertamente más de un mensaje que produzca un valor hash dado. El propósito de la función hash es hacer que la labor de encontrar tales colisiones sea computacionalmente irrealizable.

Ser capaz de producir colisiones en una función hash en un tiempo razonable convierte a una función hash en ineficaz.

La mayoría de las funciones modernas de hash se construyen a partir de una función de compresión que se itera sobre un flujo de entrada. Igual que una función hash completa, una función de compresión puede sufrir colisiones. El diseño exacto de una función hash dicta como influyen las colisiones de la función de compresión en el conjunto de la función hash - pero una función de compresión libre de colisiones es necesaria para una función hash iterada segura [MOV96].

3.2. ¿Qué es una "checksum"?

Una checksum o función CRC es un mecanismo no criptográfico para detectar errores en las transmisiones [MOV96], [RSA98].

PGP usa checksums para:

1. Producir números pseudo aleatorios no criptográficamente seguros. Existe un PRNG fuerte para generar números cuando se necesita seguridad criptográfica.
   
2. Comprobar si un mensaje se corrompió durante la transmisión. Observe que esto se hace como una comprobación extra además de cualquier método criptográficamente seguro de detección de errores. (Un interesante aparte: OpenPGP (v1) no obliga a comprobar los errores de los mensajes cifrados con métodos tradicionales y no firmados - los mensajes firmados si son comprobados - así que podrían existir errores y no recibiríamos ningún aviso [Bac99a]).
   

Observe que la función de checksum se utiliza sólo en áreas que no requieren criptografía fuerte. Cuando se requiere esta condición, PGP usa una función hash.

3.3. ¿Qué propósito tienen los algoritmos de hash en PGP?

La función hash tiene dos tareas principales en PGP:

1. Creación de firmas digitales. El mensaje pasa a través de la función y el valor de hash resultante se firma con la clave privada del usuario.
   
2. "Blanqueado" de la frase clave. Las frases clave se pasan a través del algoritmo de hash para producir una "huella digital" que un cifrado simétrico usa para descifrar la clave privada.
   

Por tanto es importante que la función hash tenga las dos siguientes características:

1. La función es de un sólo sentido - es decir que debería ser "difícil" encontrar un mensaje que dé como resultado un valor hash especificado previamente.
   
2. La función es resistente a las colisiones - es decir que debería ser "difícil" encontrar dos mensajes con el mismo valor hash.
   

3.4. ¿Qué es MD5?

MD5 es una función hash de Ron Rivest [RFC1321]. Es una versión mejorada de la función MD4 (que fue totalmente rota [RSA98]).

MD5 se incluyó en PGP desde el comienzo, pero recientemente ha sido desaprobada por razones de seguridad (ver la sección "¿Ha sido roto MD5?"). MD5 parece haber sido un catalizador de los cambios que hemos visto desde PGP v2.x.

S/MIME (v3) utiliza MD5 sólo por [IETF98]: "razones de compatibilidad con versiones anteriores".

3.5. ¿Qué es SHA-1?

SHA-1 es la función hash elegida actualmente en los estándar PGP y S/MIME. SHA-1 se define formalmente en [FIPS180-1] , [ANSI930-2] y [ISOIEC10118-3].

SHA-1 se basa en el algoritmo MD4 mejorado por NIST / NSA. La salida de SHA-1 es de 160 bits.

SHA-1 ha sido analizado detalladamente pero hasta la fecha no ha habido ataques exitosos.

3.6. ¿Qué es RIPE-MD?

RIPE-MD es otra función hash derivada de MD4. Se define formalmente en [DBP96].

Hasta la fecha no hay criptoanálisis satisfactorio de RIPE-MD. PGP implementa RIPE-MD160 que produce una salida de 160 bits.

Existen versiones de la función RIPE-MD que ofrecen longitudes de hash mayores de 160 bits (256 y 320 bits para ser precisos) pero estas funciones de hash son, de acuerdo con los autores [DBP99]: "RIPEMD-256" y "RIPEMD-320" son extensiones opcionales de, respectivamente, RIPEMD-128 y RIPEMD-160, y están pensadas para aplicaciones de las funciones hash que requieran un valor hash más largo sin un nivel mayor de seguridad."

3.7. ¿Ha sido roto MD5?

No totalmente. Primero den Boer y Bosselaers [BB94] encontraron pseudo-colisiones en la función de compresión, luego Dobbertin [Dob96a] encontró colisiones en la función de compresión.

Esto no significa que se hayan encontrado colisiones en la función hash completa, pero significa que MD5 no debería ser usado en situaciones donde se requiera resistencia a las colisiones [Dob96a], por ejemplo en la creación de firmas digitales (la principal aplicación de las funciones hash en PGP). Citando a Hans Dobbertin directamente [Dob96a]: "Por tanto sugerimos que en el futuro mD5 no debería ser implementado en aplicaciones como las firmas digitales, donde se requiere una función hash resistente a las colisiones. De acuerdo con nuestros conocimientos actuales, las mejores alternativas son SHA-1 y RIPEMD-160."

Uno debería recordar que el objetivo al diseñar MD5 era construir una función hash resistente a las colisiones a partir de una función de compresión resistente a las colisiones [Sch96a], [MOV96], este objetivo ha sido ahora violado.

En palabras de RSA Labs [RSA96b]: "Con respecto a las aplicaciones existentes que usan MD2 y MD5, no se han encontrado aún colisiones en las funciones hash pero este avance debería esperarse... RSA Labs recomienda actualmente que en general, la función hash SHA-1 debería usarse en su lugar pero RIPEMD-160 podría ser también una buena alternativa."

[MOV96] dice: "Una función hash iterada es en este aspecto al menos tan fuerte como su función de compresión".

Una queja más sobre MD5 es la salida de 128 bits. Es insuficiente para la seguridad a largo plazo [PBD97] y [Sch96a].

En resumen, Schneier dice [Sch96a] "Recelo de usar MD5".

Observemos también que S/MIME (v3) utiliza MD5 sólo por [IETF98]: "razones de compatibilidad con versiones anteriores". Parece tonto seguir utilizando tecnología tan dudosa cuando hay disponibles algoritmos muy superiores.

En resumen, las tres principales preocupaciones sobre el uso de MD5:

1. Se han encontrado pseudo colisiones en la función de compresión.
   
2. Se encontraron colisiones en la función de compresión. Esto viola los objetivos del diseño de MD5.
   
3. La función hash solo devuelve 128 bits, poco para la seguridad a largo plazo.

Un punto de vista equivocado es "MD5 es seguro hasta que alguien encuentre un modo de romperlo" - esto no es verdad. Por ejemplo, sabemos que DES era poco efectivo ante un adversario decidido incluso antes de que Internet y luego EFF rompieran el cifrado. Creo que Schneier tiene la idea exacta sobre el tema [Sch96b]: "La historia nos ha enseñado algo: nunca subestime la cantidad de dinero, tiempo y esfuerzo que alguien empleará en desbaratar un sistema de seguridad. Siempre es mejor esperar lo peor. Supón que tus adversarios son mejores de lo que son. Supón que la ciencia y la tecnología podrán pronto hacer cosas que aún no pueden. Date a ti mismo un margen de error. Date a ti mismo más seguridad de la que necesitas hoy en día. Cuando lo inesperado ocurra, estarás contento de haberlo hecho."

3.8. ¿Cuáles son las implicaciones de los ataques contra MD5?

El ataque contra MD5 fue detallado por primera vez en [Dob96a].

El ataque no permite en la actualidad a un adversario crear un mensaje ligeramente alterado que se ajuste a los valores de hash originales. Es decir que dado un mensaje A un adversario no puede encontrar un mensaje B cuyo hash sea el mismo M.

Lo que sí permite a un adversario es crear un mensaje A con un mensaje relacionado pero diferente B con un mismo hash M. En la práctica deberías firmar un mensaje sólo cuando una tercera parte no tiene influencia sobre el mensaje que está siendo firmado.

MD5 no debería ser usado en adelante universalmente sin reflexión. Los usuarios tienen que ser cuidadosos cuando consideren que documentos van a autentificar o firmar con MD5. Compare esto con SHA-1 y RIPEMD que pueden utilizarse sin esta precaución (porque con ellos no puede encontrarse tal B con el mismo valor de hash).

Si está interesado recomiendo [Dob96b] que contiene una descripción (ligeramente anticuada) del estado de MD5. El documento dice en sus conclusiones "...podría indicar que hay un serio problema de seguridad con MD5...pero en futuras implementaciones mejor apártense de MD5".

3.9. ¿Fue el SHA original roto?

La única diferencia entre SHA-1 y SHA es la inclusión de las rotaciones de un bit en la expansión de un bloque de 16 a 80 palabras - algo relacionado con "códigos lineales de corrección de errores", aparentemente [MOV96]. Se remite al lector interesado a [CJ98], un análisis detallado de los ataques contra el SHA original.

Para contestar a la pregunta, parece que SHA no fue roto, pero podría haber sido susceptible de un ataque más avanzado todavía desconocido.

De todas formas es agradable ver que los anónimos criptógrafos de la NSA son simplemente humanos también.

3.10. ¿Cuál es más fuerte, MD5, SHA-1 o RIPE-MD?

Ciertamente no MD5 (ver sección "¿Ha sido roto MD5? ").

Parece que la elección estaría entre SHA-1 y RIPE-MD. Ninguno de los dos ha sucumbido a los ataques conocidos y ambos son obra de los mejores criptógrafos.

SHA-1 es el estándar usado en PGP v5+ y no hay razón en absoluto para dudar de esta elección [Sch96a], [PGP98], [RSA96b], [MOV96], [Dob96a]. El manual de PGP [PGP98] resume el sentimiento de la comunidad criptográfica sobre SHA-1: "SHA se ha publicado abiertamente y ha sido objeto de detallados análisis por la mayoría de los mejores criptógrafos del mundo especializados en funciones hash, y la opinión unánime es que SHA está extremadamente bien diseñado."

Todavía no he encontrado una sola cita que haga albergar dudas sobre la seguridad criptográfica de SHA-1 o RIPEMD.

3.11. ¿Qué diferencias de rendimiento existen entre MD5, SHA-1 y RIPE-MD?

Velocidad de las funciones hash (en Mbit/s en una plataforma no especificada) tomado de [PBD97]:

Tabla 4: Comparaciones de velocidad de las funciones hash

MD5 puede ser rápido, pero recuerde que es relativamente inseguro ante ciertos ataques.

4. Algoritmos de cifrado convencional en PGP

4.1. ¿Qué es un algoritmo de cifrado convencional?

Un algoritmo de cifrado convencional es una función que aplica un bloque de texto de n-bits en un bloque de texto cifrado de n-bits donde n es el tamaño del bloque. Típicamente, n es igual a 64 o 128 bits.

La función toma un parámetro, la "clave" que especifica cual de las aplicaciones entre el texto en claro y el cifrado se utilizará.

Los cifrados de bloque son, dada la misma clave, inversibles.

4.2. ¿Qué propósito tiene un algoritmo de cifrado convencional en PGP?

Los cifrados de bloque se usan en numerosas áreas de PGP:

1. Cifrado de grandes cantidades de datos. Las claves de sesión se cifran con el algoritmo de clave pública, y a continuación el grueso de los datos se cifra con un algoritmo convencional. Esto se hace por razones de seguridad y velocidad.
   
2. Mantener un depósito de datos aleatorios.
   
3. Cifrar las claves almacenadas en el anillo de claves privadas. Este anillo mantiene la clave privada de descifrado y es imperativo que este fichero esté cifrado de una manera "segura". Es interesante observar que no todo el anillo de claves está cifrado - sino sólo los datos de la clave privada. Por tanto alguien que obtenga un anillo de claves privadas obtendría detalles de todas las identificaciones de usuarios anónimos y parámetros públicos [Bac99a].

4.3. ¿Qué es IDEA?

IDEA es un fuerte cifrado de bloques de Xuejia Li, formalmente definido en: [Lai91].

IDEA es un algoritmo de 8 rondas con un tamaño de bloque de 64 bits que utiliza claves de 128 bits. La fortaleza del cifrado la proporciona "mezclar operaciones de diferentes grupos algebraicos". IDEA es resistente tanto al criptoanálisis [Sch96a]. Actualmente, no se conoce ninguna manera de romper IDEA aparte de la fuerza bruta [Sch96a].

De [RSA96a]: "Se considera generalmente que IDEA es seguro y tanto el desarrollo del algoritmo como su base teórica han sido abierta y ampliamente discutidos."

Los mejores ataques conocidos contra IDEA son:

1. Ataque diferencial con clave elegida en una versión muy debilitada del algoritmo con sólo 3 rondas. [KSW96].
   
2. Ataque temporizado sólo con texto cifrado y clave elegida sobre el algoritmo completo que requiere 5x2¹⁷ peticiones de claves relacionadas, cada una de ellas usada para realizar 2²⁰ bloques de texto claro sin nombre y aleatorios [KSW96].
   
3. Una combinación de criptoanálisis diferencial y lineal que requiere 2²⁹ pares de texto en claro elegido y una carga de trabajo de 2⁴⁹ sumas módulo 2¹⁶+1 en una versión muy debilitada del algoritmo con sólo 3 rondas [Bor96].
   
4. Un ataque de criptoanálisis imposible por Biham y Shamir - los detalles son esquemáticos (por decir algo) pero este es el mejor ataque contra IDEA hasta la fecha [Sch98h].
   

Ninguno de estos ataques es útil para romper ninguna implementación práctica de IDEA. IDEA completo resiste ataques diferenciales, lineales y con clave relacionada o elegida, aunque hay un interesante ataque "lateral" que puede ser llevado a cabo en una implementación de IDEA que permite medir tiempos de proceso con una alta resolución [KSWH98b]

IDEA ya no es el algoritmo por defecto en PGP debido a problemas de patente (IDEA necesita una licencia para usarse comercialmente).

4.4. ¿Qué es CAST?

CAST es una familia de cifrados de bloque por Carlisle Adams y Stafford Tavares. PGP v5 implementa una versión de CAST conocida como CAST5 o CAST-128. Esta versión de CAST es el cifrado más estándar al que la gente se refiere cuando dicen "CAST". La especificación formal de CAST puede encontrarse en [RFC2144].

Esta versión de CAST tiene un tamaño de bloque de 64 bits y una longitud de clave de 128 bits. Es resistente tanto al criptoanálisis diferencial como al lineal [Sch96a]. Actualmente, no hay forma conocida de romper CAST aparte de la fuerza bruta [Sch96a].

No hay ataques conocidos contra CAST con un número reducido de rondas- parece increíblemente seguro.

CAST es ahora el cifrado por defecto de PGP.

4.5. ¿Qué es 3DES?

DES se define formalmente en [FIPS46-2] y Triple-DES (3DES) en [ANSI952].

Recientemente, NIST ha sugerido que FIPS46-2 debería ser reemplazado por el algoritmo Triple-DES que espera ser formalmente aprobado como [FIPS46-3]. Esto se debe fundamentalmente a la forma en que la EFF reventó DES en menos de un día.

3DES consiste en tres aplicaciones del cifrado DES en modo CDC (cifrado- descifrado- cifrado) con claves independientes. El cifrado se ejecuta como sigue:

TextoCifrado=DES_k1(DES^-1_k2( DES_k3(TextoClaro)))

Y el descifrado:

TextoClaro=DES^-1_k3(DES_k2( DES^-1_k1(TextoCifrado)))

3DES tiene un tamaño de bloque de 64 bits y una longitud de clave de 168 (3*56) bits. Por la construcción de 3DES, se piensa que ofrece una seguridad equivalente a un cifrado de bloque de 112 bits [BK98].

Los mejores ataques conocidos contra RSA son:

1. El ataque Meet In The Middle (MITM) (encontrarse en el medio). Este ataque puede ser teóricamente ser usado contra cualquier cifrado múltiple. En el caso de DES este ataque requiere 524.288 Terabytes de almacenamiento, 2¹¹² cifrados y 2¹¹² consultas de tabla [MOV96], [Luc98].
   
2. Ataques MITM optimizados. Algunos compromisos tiempo/memoria aplicados al ataque MITM estándar pueden hacer que MITM sea ligeramente más realizable [Luc98]. Se necesitan 2¹⁰⁸ operaciones de cualquier modo para el ataque "realizable" en términos de memoria.
   
3. Ataque con clave relacionada. Necesita una consulta con clave relacionada, una consulta con texto cifrado elegido y de 2⁵⁶ a 2⁷² intentos de cifrado offline [KSW96].

Estos ataques no son útiles para romper implementaciones prácticas de 3DES.

4.6. ¿Qué es AES?

AES (Advanced Encryption Standard o estándar criptográfico avanzado) es la búsqueda del gobierno de EE.UU. de un sustituto para el viejo estándar DES (Data Encryption Standard o cifrado de datos estándar).

El Instituto de Estándares y Tecnología (NIST), hizo una primera solicitud pública de algoritmos el 12 de Septiembre de 1997 [NIST97]. Varios criptógrafos bien conocidos (Rivest, Schneier, Knudsen, Biham, Rijmen, Coppersmith etc) desarrollaron algoritmos candidatos para el AES que cumplían los criterios solicitados. De los 15 algoritmos iniciales, cinco (Mars, RC6, Rijndael, Serpent y Twofish) han sido seleccionados para pasar a la segunda ronda. Se espera que un candidato sea finalmente llamado AES en algún momento del año 2000.

Aunque este proceso de selección solo elige un cifrado para el gobierno estadounidense, se cree que AES, cuando sea seleccionado, se convertirá en el estándar internacional durante el próximo milenio. Todos los candidatos AES aceptan claves de 128, 196 o 256 bits y tienen un tamaño de bloque de 128 bits.

El estándar OpenPGP [RFC2440] ha reservado las IDs 7, 8 y 9 para las claves de 128, 192 y 256 bits respectivamente.

A cualquiera interesado en saber más sobre el AES se le recomienda ver el informe del NIST sobre la primera ronda [NIST99b].

4.7. ¿Qué es Twofish?

Twofish es un candidato AES obra de Schneier, Kelsey, Whiting, Wagner, Hall, Ferguson presentado incialmente en [SKWWHF98]. Se incluye en una sección separada de este documento porque OpenPGP y NAI han decidido que Twofish es un cifrado tan prometedor que debería ser añadido a PGP antes del término del proceso AES [Koc98], [Pri99a].

Twofish es una evolución del cifrado Blowfish. La mayoría de los cambios parecen haber sido hechos para cumplir los criterios AES. Actualmente, no se conoce método de romper Twofish aparte de la fuerza bruta, aunque esto debería esperarse teniendo en cuenta el poco tiempo pasado tras la publicación.

Personalmente, creo que es una MALA idea incluir Twofish como cifrado en este momento. Mis comentarios originales sobre la elección [Sim99] fueron:

Básicamente creo que Twofish es demasiado nuevo entre los sistemas criptográficos "vivos". Ideas similares se expresan en [Pre99], [Knu99].

Sin embargo los receptores de mensajes de PGP tienen la opción de elegir cual de los cifrados simétricos van a aceptar. Por ejemplo, si el estándar OpenPGP ofreciera un simple algoritmo XOR (¡totalmente inseguro!), entonces los receptores pueden simplemente deshabilitar este algoritmo y nunca recibiran mensajes cifrados con dicho algoritmo.

4.8. ¿Ha sido roto 3DES?

No. El DES "simple" fue reventado por fuerza bruta por la EFF usando una máquina especializada en sólo 56 horas [EFF98]. La fuerza bruta básicamente involucra intentar las 2⁵⁶ claves hasta encontrar la correcta. La fuerza bruta necesita, en promedio 2^{long.clave -1} - así que en el caso de DES la máquina tiene que intentar aproximadamente 2⁵⁵ veces el descifrado antes de ser recompensado con el texto en claro correcto. Obsérvese que los ataques por fuerza bruta se consideran generalmente como de texto en claro conocido, pero [WB94] esboza un chip capaz de reconocer un descifrado correcto - esto hace un ataque por fuerza bruta plausible incluso si no se conoce algún bloque de texto en claro.

Más recientemente, el tercer desafío DES propuesto por RSA fue ganado en menos de un día por la máquina de la EFF [EFF99]!

Triple-DES es al menos 2⁵⁶ (aprox. 10¹⁷) veces más difícil de romper que el DES original [CYL98a] y como tal puede ser considerado muy seguro. Un adversario tendría que intentar en promedio 2¹¹¹ claves para romper un solo mensaje 3DES (y necesitaría una gran cantidad de espacio de almacenamiento para almacenar los valores intermedios). Es importante en los esquemas de cifrado múltiple que el cifrado subyacente no sea un grupo; afortunadamente Campbell y Wiener han mostrado que DES no es un grupo [CW93].

Implementado adecuadamente se cree que 3DES es muy fuerte [Wag94], [WB94], [Sch96a], [MOV96], [RSA96a], [RSA98], [Sch98f]. De hecho, no he sido capaz de encontrar un sólo criptógrafo con dudas sobre la fortaleza de 3DES.

En palabras de [CYL98a]: "Ya que triple-DES es 10¹⁷ veces más fuerte que el DES simple, haciendo un poco de aritmética veremos que este ordenador de 300 millones de dólares puede romper una clave triple-DES en unos 4x10¹⁰ años, aproximadamente la edad del universo."

En palabras de Bruce Schneier [Sch98f]: "Ciertamente triple-DES es una mejor elección que AES, en algunas aplicaciones. Triple-DES será posiblemente el algoritmo elegido para muchas aplicaciones bancarias incluso después de que el estándar AES sea aprobado."

Y finalmente en palabras de Dorothy Denning [Den98]: "Triple DES no ha sido roto y su seguridad no ha sido comprometida."

4.9. ¿Ha sido CAST roto?

Como se ha mencionado previamente, CAST es una familia de cifrados. Algunos de los otros algoritmos CAST han sucumbido a ataques avanzados (Rijmen y Preenel han atacado algunos diseños CAST y también lo han hecho Kelsey, Schneier y Wagner [KSW97]). Los mismos ataques intentados contra la implementación de CAST en PGP han fallado hasta el momento.

4.10. ¿Cuál es más fuerte, IDEA, CAST o 3DES?

Esto es materia de debate y subjetivo. Ninguno de estos algoritmos ha sido roto ni existen dudas serias sobre su fortaleza.

Algunas personas no confían en 3DES porque se basa en DES, obra de la NSA. Sin embargo, respetados criptógrafos tienen a 3DES en muy alta estima.

CAST5 tal y como lo implementa PGP, no ha sufrido ningún ataque con éxito, pero Bruce Schneier ha dicho lo siguiente [Sch98a] "Yo doy a CAST-128 un gran ¡puaj!" y [Sch98c] "No me gusta el proceso de diseño.".

IDEA es posiblemente el segundo cifrado más conocido (después de DES). Esto se debe principalmente a dos influencias:

1. La elogiosa descripción en Applied Cryptography [Sch96a].
   
2. Su inclusión como parte de PGP.
   

IDEA parece haber sufrido un cierto retroceso debido a los problemas de patentes. Sin estos, no dudo que IDEA sería ahora el estándar de facto. [RSA96a] dice lo siguiente sobre IDEA: "Se considera a IDEA seguro en general y tanto el desarrollo del algoritmo como su base teórica se han discutido abierta y ampliamente."

Más recientemente IDEA parece haber perdido favor (posiblemente por el pequeño tamaño del bloque comparado con los candidatos AES). Recientemente Bruce Schneier ha dicho lo siguiente sobre IDEA [Sch98d]: "Que conste que estoy menos enamorado de IDEA en estos días. Todavía es seguro, porque no hay ataques publicados, pero otros algoritmos me gustan mucho más."

Cuando recientemente se le preguntó "¿Cual de estos algoritmos se considera el más difícil de reventar; RC6, IDEA, CAST, 3DES o Blowfish" Bruce respondió [Sch98b] "Triple DES sin duda. Ninguno se acerca a la cantidad de análisis existente sobre él." El también dijo [Sch98a] "Si quieres ser conservador, usa Triple DES."

David Wagner ha dicho [Wag99]: "3DES es todavía mi cifrado preferido para las aplicaciones donde la seguridad es crítica."

La NSA se opuso a que el algoritmo 3DES se convirtiera en el estándar ANSI X9 con los comentarios [Fro95]:

• El compromiso del gobierno con EES y DES es inconsistente con este objetivo.
• Triple DES no puede exportarse.
• La proliferación ulterior de triple-DES es un freno a la seguridad nacional y los asuntos económicos.

¡Así que no puede ser tan malo!

A mí personalmente me hace sentir bien la presencia de estos tres fuertes algoritmos en PGP. Si alguno de estos algoritmos fuera roto, incluso aunque este desarrollo aparezca improbable es este momento, los usuarios de PGP podrían simplemente deshabilitar el algoritmo roto y usar uno de los algoritmos que todavía fueran seguros. Compare esto con los usuarios de uno de los estándares (p. ej. S/MIME) que están abandonados con un sólo algoritmo seguro.

En resumen, ninguno de los algoritmos en PGP v5+ están rotos, ni cerca de ello. PGP ciertamente añadirá el cifrado AES una vez que sea seleccionado y este debería ser utilizado como algoritmo preferido. Por ahora parece que 3DES es el algoritmo que elegirán los pesimistas [Wag94], [Sch96a], [Sch98f].

Un empleado de ha expresado la opinión de que [Pri99]: "Yo elegiría CAST5 sobre cualquiera de estos algoritmos (Blowfish y 3DES) en cualquier momento -- aunque creo que los tres son 'seguros' en general." Un punto de vista con el que no estoy de acuerdo...

CAST es el algoritmo por defecto para las nuevas claves producidas con PGP v5+, pero 3DES es el algoritmo obligatorio en el estándar OpenPGP (es decir todas las implementaciones del estándar deben proporcionar el cifrado 3DES).

4.11. ¿Cómo son de "computacionalmente resistentes" las claves simétricas?

Siendo honesto, no esperaba tener que escribir esta sección. Cualquier cosa que escriba estará finalmente equivocada por un lado o por otro, y además se presta a serias malinterpretaciones.

Lo primero que se debe decir es que todas estas cifras asumen que la fuerza bruta es el mejor ataque disponible (o MITM en el caso de DES). Si un adversario se las ingenia para encontrar un método criptoanalítico práctico de reducir el trabajo necesario, estas cifras se podrían reducir consecuentemente.

En segundo lugar, si los QCs o los ordenadores basados en DNA se hacen realidad, o si la ley de Moore es una grosera subestimación del aumento de potencia de los ordenadores, entonces de nuevo esta sección es inútil.

Entonces, volviendo a la pregunta... Para romper por fuerza bruta los cifrados simétricos ahora bajo una serie de supuestos:

1. Cada uno de los ordenadores (3*10⁸ estimados) del planeta se usa a tiempo completo.
   
2. Cada ordenador tiene la potencia de proceso de un PII a 450Mhz.
   

Entonces una sola clave (3DES) puede ser forzada en un promedio de 10¹¹ (más exactamente 457.351.814.728) años. Este supuesto es desde algunas perspectivas muy optimista (desde el punto de vista del adversario); ¿pueden utilizarse todos los ordenadores simultaneamente y que todos funcionen a la velocidad de un PII 450? No.

A esta cifra se llega así: 2^{(LongClave-1)} / (NumOrdenadores) / NumOpsPorAño o también: 2¹¹¹/3*10⁸/18.921.600.000.000

Por otro lado las cifras son "un poco" pesimistas:

1. Se supone que la potencia de cálculo permanecerá constante.
   
2. Se supone que el número de ordenadores permanecerá constante.
   

Intentar tomar en cuenta todos los factores arriba señalados es difícil. La tabla 5 intenta mostrar cuanto tiempo permanecerán seguras los distintos tipos de claves. Se hacen las siguientes suposiciones:

1. El número de ordenadores en el mundo es igual a 100 mil millones de (10¹¹) es decir 10 por cada persona que se espera que viva en el mundo en el año 2.014 (diez mil millones de personas estimadas).
   
2. Cada uno de los ordenadores obedece la ley de Moore durante todo el periodo de ruptura de la clave. (NOTA: este supuesto puede romper las teorías actuales sobre la velocidad de la luz, física cuántica etc.). Realmente se predice que la ley de Moore se volverá menos creíble en 10 años o así.
   
3. Seguimos asumiendo que no se encuentran ataques mejores que el de fuerza bruta - lo que parece improbable a la luz de las mejoras en el criptoanálisis durante la última década.
   

Aquí va...

Tabla 5: Fortaleza de los cifrados de bloque contra un adversario con muy buenos recursos.

Tomaré una de las cifras para explicar exactamente lo que significa - no es inmediatamente obvio. Si un adversario tiene 10 mil millones de ordenadores de "última generación" equivalentes a PII 450MHz que puede emplear solamente en reventar una clave 3DES, entonces empezaríamos a preocuparnos en cambiar el cifrado dentro de 44 años - el adversario podría romper la clave en 10 años a partir de ese momento. Recuerde que esto le daría ¡una sola clave!

Otro ejemplo; si un adversario toma 500 superordenadores de última generación, cada uno de ellos capaz de reventar mil millones de claves por segundo (¡menudos ordenadores!) y usarlos solamente para reventar una clave 3DES, necesitaríamos pensar en cambiar el cifrado dentro de 61 años - el adversario podría romper el cifrado en 10 años a partir de ese momento. De nuevo esto rompe una sola clave.

Aún otro ejemplo; si un adversario usa 100.000 máquinas "Deep Crack", cada una de ellas capaz de romper 92.625.000.000 de claves por segundo, y las emplea sólo para reventar una clave 3DES, necesitaríamos cambiar de cifrado dentro de 74 años - el adversario podría en 10 años a partir de ese momento romper la clave. Como siempre todo este esfuerzo nada más le daría una clave.

Para ser totalmente honesto, esta sección sólo la escribí "coaccionado" - montones de personas la pidieron. No estoy seguro de que sirva para probar más que 3DES, IDEA y CAST serán seguros durante 50 años siempre y cuando la mejora manera de reventarlos sea la fuerza bruta.

Yo personalmente pienso que el cifrado asimétrico terminará siendo el eslabón débil de la cadena - es decir que factorizar / calcular logaritmos discretos será más factible mientras que será menos factible el ataque a las claves simétricas. Aún peor, tanto el PLD como el PFE podrían resultar ser "computacionalmente fáciles".

Si toda esta historia tiene alguna moraleja es "Cuanto antes empieces a calcular, más tiempo tardarás en acabar." [Sil98].

Uno tiene que preguntarse a sí mismo si una agencia de inteligencia se molestaría en gastar miles de millones de dólares para leer un mensaje... Si el mensaje fuera tan importante, ¿no te raptarían (y matarían si fuera apropiado)?

4.12. ¿Por qué no usa PGP un cifrado "probadamente seguro"?

¡Porque no hay ningún cifrado práctico que ofrezca una demostración general de seguridad!

Algunos algoritmos ofrecen seguridad probada frente a ciertas clases de ataques (p.ej. DFC [GGH+98]), y otras ofrecen una demostración más general de seguridad bajo algunas hipótesis subyacentes sin demostrar (p.ej. Bear [AB96]). Pero ninguno de estos algoritmos ha pasado por una cantidad significativa de análisis.

El documento de Twofish [SKWWHF98] afirma que "Cualquier prueba razonable de seguridad general para un cifrado de bloque probaría también que P != NP".

[MOV96] dice sobre la seguridad incondicional: "...necesita tantos bits de clave secreta como texto en claro y no puede ser proporcionada por un cifrado de bloque que cifre más de un bloque". ¡No es muy útil!

Así, sin usar One-time pad (también conocido como cifrado de Vernam), que no es práctico, PGP tiene que hacer "lo siguiente mejor" - usando un cifrado de bloque fiable que ofrezca seguridad heurística. De todos los cifrados de bloque publicados, 3DES parece ser el más cercano a un "cifrado ideal" en términos de fortaleza.

Lo mejor que podemos esperar hacer es usar todo nuestro arsenal de herramientas analíticas para intentar probar que un cifrado es inseguro. Si no sucumbe a estas herramientas entonces no hemos probado que sea seguro, pero nos indica el grado de confianza que podemos poner en ese cifrado.

4.13. ¿Qué diferencias de rendimiento haya entre IDEA, CAST, 3DES?

Velocidades de cifrado simétrico (en Mbits/s en un Pentium 200Mhz) tomado de [Lip99]:

Tabla 6: Comparación de la velocidad de los cifrados de bloque

NOTA: estas cifras no son de la implementación que hace P