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 PGP de estos cifrados, pero son indicativos del rendimiento de cada cifrado.

5. Certificados de Revocación de Claves (KRC)

5.1 ¿Qué es un KRC?

Demasiado a menudo, alguien escribe a los grupos de noticias *.pgp con preguntas del tipo "He perdido mi clave privada, ¿cómo puedo revocar mi clave?. Demasiado a menudo, los miembros de estos grupos tienen que hacer saber a estas personas que no pueden revocar su clave.

Necesita dos cosas para revocar su clave: su clave privada y su frase de paso. ¿Y si la clave que ahora recuerdas con tanta claridad se te olvida algún día? ¿O qué pasa si accidentalmente borras tu anillo de claves privadas? Ambas cosas ocurren, y de cualquier modo, excepto inhabilitando tu clave o hackeando el valor hex de tu clave, no hay forma de hacer notar que tu clave no puede ser usada.

Por otro lado, las dos formas mencionadas no previenen que la gente utilice tu clave, mientras que un KRC si lo hace. En resumen, es inteligente que generes un KRC inmediatamente después de generar tu clave - puede ser imposible crear el KRC cuando realmente lo necesites.

5.3. ¿Que debe preocuparnos al producir un KRC?

Si alguien consigue su KRC, pueden revocar su clave. Preocúpese de almacenar su KRC de forma suficientemente segura para que nadie que no deba pueda hacerse con él. Asegúrese también de que su KRC no esté tan bien guardado que usted mismo no pueda acceder a él.

En PGP v6.0+ y las versiones comerciales de las v5.x, en preferencias, puede hacer que PGP se sincronice con los Servidores de Claves al realizar ciertas operaciones. ¡¡¡Asegúrese de que la opción de sincronización al revocar una clave no está activada o su KRC se enviará a los servidores!!!

También al crear su KRC, ha hecho copia de seguridad de su clave privada. Podría desear borrar de forma segura ese fichero. Observe que como Windows utiliza un fichero de intercambio su clave privada podría acabar allí. Qué demonios, su clave privada podría haber quedado quemada en su RAM o algo. Tome todas las precauciones que considere prudentes para proteger la información contenida en su clave privada.

5.3. ¿Cuál es el procedimiento para crear un KRC?

El siguiente procedimiento cubre la creación de un KRC bajo las versiones recientes de PGP (es decir v5.x comerciales y todas las versiones v6.x):

1. Cree su nueva clave.
   
2. Haga copia de seguridad de su nueva clave. Seleccione la clave para la que desee crear un KRC. Vaya a "Keys | Export...". Una nueva pantalla aparecerá, pidiéndole que especifique un nombre de fichero. De al fichero un nombre obvio que signifique que esa es una copia buena de su clave. También, al final de esta pantalla hay una caja que dice "Export private key(s)". Haga clic en ella. Ahora, al seleccionar ok, una copia de su clave se salvará en la localización que Vd. especifique.
   
3. Verifique que las copias de seguridad son buenas. Puede hacerlo yendo a "Keys | Import..." en PGP keys. Debería ver un icono de llave doble o un icono de llave con una cabeza. Si es una sóla llave, significa que en el paso previo no hizo clic en la caja "Export private key(s)". Si obtiene el icono de la llave doble o un icono de llave con una cabeza y no hay una línea roja cruzándolo, lo ha hecho bien.
   
4. Revoque su clave en el anillo de claves. Para hacerlo, seleccione la clave que hay que revocar. PGP le preguntará si está seguro. Conteste sí. Escriba su password para la clave privada. Si tiene habilitada la descripción de las claves en preferencias (keys: select columns), verá que la descripción dice "Revoked DH/DSS public key" o "Revoked RSA public key", dependiendo de si su clave es RSA o DH/DSS. Si sólo dice "Disabled", lo ha hecho mal.
   
5. Ahora, haga copia de seguridad de su clave revocada. No exporte su clave privada esta vez. Asegúrese de exportar su clave revocada con un nombre de fichero diferente al de la clave buena que exportó en el paso 1. Puede que también quiera imprimir una copia de su certificado de revocación en caso de que su copia en el disco resulte dañada. Para hacerlo, seleccione la clave ahora revocada en su anillo de claves, ir a "Edit|Copy", ejecute el bloc de notas, o algún otro procesador de textos y pegue su clave revocada. Puede imprimirla si lo desea.
6. Borre su clave revocada del anillo de claves ("Edit|Delete"), e importa su clave privada buena del paso 1 ("Keys|Import...").
7. Verifique que su clave funciona bien para firmar, cifrar y descifrar.
8. Coloque su clave revocada (KRC) en un disquete u otro lugar seguro. ¡Este es su salvavidas! Nota -si un adversario (o bromista) obtiene su KRC puede inmediatamente revocar su clave en su beneficio. ¡Está avisado!
9. Si y sólo si, necesita realmente revocar su clave, re-importe su KRC y súbala a los servidores.

6. ¿Qué sería necesario para "romper" PGP?

Esta realmente, es una respuesta rápida a la pregunta anterior. Para una explicación más detallada (referida sólo a las versiones RSA :-()) vea el excelente "FAQ sobre ataques a PGP" [Inf96].

Cualquiera de las siguientes cosas afectaría la seguridad de PGP:

1. Lo más probable, una implementación equivocada de alguna de las primitivas criptográficas.
   
2. Una función hash concienzudamente reventada (pueden encontrarse colisiones en un tiempo razonable por un ordenador). Esto permitiría a un adversario crear segundos mensajes con un valor de hash igual al del primer mensaje, lo que implica que se pueden falsificar las firmas.
3. Un nuevo método de criptoanálisis que rompe el cifrado simétrico usado en PGP. Esto permitiría a un adversario leer el tráfico cifrado con ese algoritmo.
   
4. Una manera de romper el PRSA, bien resolviendo el PFE bien por otros medios.
   
5. Una manera de romper el PDH, bien resolviendo el PLD, bien por otros medios.
   
6. Una manera de romper DSS, bien resolviendo el PLD, bien por otros medios.
   
7. Explotar el RNG de alguna manera. Esto podría permitir a un adversario adivinar las claves de sesión, vectores de inicialización y nuevas claves.
   

La NSA podría haber hecho alguna de las cosas anteriores. Este es un mundo gracioso.

7. Otras cuestiones

7.1 Anillo de claves privadas - ¿qué contiene y por qué necesita protección?

El anillo de claves privadas (llamado "Secring.skr" por defecto) contiene su(s) clave(s) privada(s). Si alguien accede a él podría:

1. Descifrar cualquier mensaje enviado a las claves contenidas en tu anillo. Esto incluye mensajes pasados presentes y futuros.
   
2. Crear firmas digitales usando cualquiera de tus claves privadas.
   

Básicamente, si alguien obtiene sus claves privadas entonces toda la seguridad de PGP se ha perdido. Es importante, por tanto, proteger rigurosamente las claves privadas PGP. PGP proporciona alguna protección; cifra el anillo de claves con una frase clave (passphrase) - sin ella las claves privadas son inaccesibles.

Si tienes una buena frase clave (ver [Sch96a]), entonces su anillo de claves estará seguro ante cualquier adversario. De todas formas debería seguir algunas precauciones básicas:

1. No almacene el fichero en una red o unidad de disco compartida. Yo, por ejemplo, llevo mi anillo de claves en un disco ZIP.
   
2. Almacene el fichero en una unidad cifrada (como las que proporcionan PGPDisk, ScramDisk, Bestcrypt, EFS, etc.). Esto añade otra capa de seguridad a la frase clave que requiere PGP.
   

Combinar los dos procedimientos anteriores (es decir almacenar los ficheros en una unidad extraíble que esté además cifrada) ciertamente mejorará la seguridad.

7.2. OpenPGP

PGP se ha propuesto recientemente como estándar IETF. Es muy improbable que OpenPGP fuera aceptado como estándar si obligase a usar algoritmos bajo patente IMC98], [WIR97b], [CNET97], [Bac99b]. Esto explica por qué RSA e IDEA han sido dados de lado en las últimas versiones de PGP.

El estándar ha sido aceptado ahora por la IETF y puede encontrarse en [RFC2440].

Uno puede ver una transformación similar en estándares afines como S/MIME

7.3. Cuestiones sobre la licencia RSAREF.

PGP / NAI se encontraron en la interesante posición de decidir si apoyar a RSA en la versión freeware de PGP v5+. La versión más reciente de la librería de referencia RSA, que tiene que ser usada para no infringir la patente, tiene algunas estipulaciones interesantes [RSA94]:

1. proporcionar el código completo de la aplicación a RSADSI
2. garantizar a RSADSI el derecho a redistribuir tal aplicación
3. distribuir el código fuente de la aplicación con cada ejecutable
4. obtener el acuerdo expreso y por escrito del usuario final de que el programa no será usado para obtener ningún beneficio económico.

PGP podría haber estado en la posición de tener que usar una librería que es inferior en términos de velocidad a las librerías no patentadas MPILIB o BNLIB.

Por supuesto, PGP/NAI podrían haber seguido usando la versión antigua de RSAREF (la RSAREF v1), pero eso también tenía una cláusula onerosa [RSA93]:

"...incorporar el Programa en otros programas para su uso personal o interno, siempre que proporcione a RSA una copia de tales modificaciones o Programas de Aplicación por correo electrónico, y garantice a RSA una licencia perpetua sin royalties para usar y distribuir tales modificaciones y Programas de Aplicación en los términos establecidos en este acuerdo."

Básicamente, PGP/NAI tendrían que garantizar a RSA una "licencia sin royalties para usar y distribuir PGP". Esto es ciertamente contrario a los intereses comerciales de NAI/PGP y como tal parecería prohibitivo distribuir una versión gratuita de PGP que incorpore RSAREF. Esta parece la única manera actualmente de proporcionar RSA sin entrar en conflicto con la ley de patentes.

Los usuarios, por supuesto, son libres de usar versiones antiguas de PGP si se ven forzados a usar RSA. También debe observarse que las versiones internacionales de PGP v5+ utilizan RSA como estándar (ya que no hay patentes que afecten a RSA fuera de Estados Unidos).

Se puede ver, en la versión EE.UU. de PGP v6.02, que NAI ha hecho un intento honesto de proporcionar la máxima funcionalidad RSA disponible "en términos razonables" - esta versión de PGP usa la funcionalidad RSA que aporta CAPI (licenciado por Microsoft).

Quizá alguien pueda ver una forma comercialmente viable de que NAI/PGP siga usando RSA en la versión freeware de PGP. Yo desgraciadamente no puedo.

7.4. "Presentación forzosa" de claves de cifrado

Nota: este es un área oscura en términos legales, hay muy pocos precedentes y por tanto se recomienda a los usuarios solicitar ayuda legal antes de actuar según los comentarios de esta sección.

Parece posible (al menos en algunos países) que las Cortes tengan la posibilidad de forzar la presentación de claves necesarias para descifrar las comunicaciones. En términos de PGP esto significa que una Corte podría forzar al usuario a proporcionar la frase clave que permita a la Corte acceder a la clave privada usada para el descifrado.

Se acepta en general [EC98] que "un sistema de custodia de claves (key escrow) no está pensado para acceder a las claves privadas que se usen sólo para comprobar la integridad de los mensajes." La presentación forzosa o, peor aún, la custodia de claves sólo para firmar no permitiría la no-repudiación o autenticación "asegurada". Por lo que sé, ningún país maneja la idea de obligar la presentación o custodia de claves de firmado.

En versiones anteriores de PGP (las v2.x), divulgar la clave RSA significaba que:

1. Todos los mensajes pasados, presentes y futuros podrían ser descifrados.
   
2. Las firmas digitales podrían ser falsificadas.
   

Obviamente, estos dos puntos son tan desastrosos que PGP ofrece soluciones a ambas cuestiones:

1. Las claves de cifrado y firmado son entidades independientes. Cada clave generada con PGP consiste en dos partes:
1. Una clave de cifrado (Diffie-Hellman)
2. Una clave de firmado (DSS, Digital Signature Standard)
2. La capacidad de revocar una clave de cifrado sin revocar la totalidad de la clave. Se pueden crear y revocar claves de cifrado sin sacrificar tu clave maestra de firmado y las firmas utilizadas con ella.

Estas facilidades no estaban disponibles para las claves RSA. Es cierto que PGP podría haber construido una capacidad similar para las claves RSA pero estas nuevas claves serían necesariamente incompatibles con las antiguas.

Desde el punto de vista criptográfico, es también una práctica recomendable evitar usar la misma clave para diferentes usos [MOV96].

7.5. ¿Rompe DH la red de confianza existente?

Una queja antigua, y sin fundamento, sobre PGP DH era que las nuevas claves "rompían la red de confianza". La gente pensaba que todas sus firmas existentes, que construían la red de confianza, estarían ahora difuntas.

Una forma simple de mantener la "red de confianza RSA" existente es simplemente firmar las nuevas claves DH/DSS con antiguas claves RSA.

7.6. ¿Por qué debería confiar en Zimmerman? ¡No es criptógrafo!

Hay tres respuestas a esta pregunta hecha frecuentemente:

1. Phil Zimmerman no ha escrito una sola línea de código desde al menos el 92 [Zim96]. En su lugar criptógrafos y programadores profesionales han desarrollado PGP.
   
2. Incluso si él estuviese haciendo toda la programación, no necesitaría ser un criptógrafo. PGP simplemente utiliza las primitivas criptográficas existentes, bien documentadas y especificadas en la literatura criptográfica. Las primitivas usadas en PGP se pueden comprobar con los vectores de comprobación ya publicados.
   
3. ¡En realidad Phil parece un programador muy bueno! Por ejemplo, [PGP96] su implementación MPILIB de las funciones RSA es más rápido que la RSAREF de la propia RSA!
   

Docenas, si no cientos de criptógrafos entrenados y programadores han revisado las varias implementaciones de PGP existentes (yo conozco al menos 5 personalmente). No hay duda de que romper una implementación de PGP haría de alguien un criptógrafo (recuerde que Matt Blaze se "hizo" criptógrafo al romper un popular estándar criptográfico). Ver la sección "¿De verdad alguien se molesta en comprobar el código fuente de PGP?"

7.7. ¿Cómo es de seguro el RNG de PGP?

La seguridad de PGP depende poderosamente del Generador de Números Aleatorios (RNG).

El RNG se usa en las siguientes situaciones:

1. Producción de claves asimétricas de larga duración.
   
2. Producción de claves simétricas aleatorias de sesión.
   
3. Producción de vectores de inicialización (IV).
   
4. Producción de valores aleatorios usados por DSS.
   

Afortunadamente, PGP v5+ implementa un RNG que sigue el ANSI X9.17, que está de acuerdo con el estándar perfilado en [FIPS186-1].

Como me interesaba personalmente, separando el RNG del resto de las funciones de PGP v5.0i produje 50 ficheros de 30Mb de datos "aleatorios" que fueron probados con DieHard [Mar98], un programa popular para comprobar datos en busca de no-aleatoriedad. De acuerdo con DieHard la salida del RNG que usa PGP no exhibe desviaciones, correlaciones u otras debilidades estadísticas obvias. Un par de los tests fallaron, pero eso es algo que se debe esperar [Rit98].

El RNG de PGP también pasa los tests especificados en [FIPS140-1].

Nota: el RNG no puede ser declarado seguro sólo por estos tests empíricos.

Si estás interesado en probar el RNG de PGP recomiendo el excelente libro de Knuth [Knu98], o el artículo de Kelsey, Schneier, Wagner, Hall [KSWH98a]. Más fuentes particularmente buenas de información sobre RNG están disponibles en [MOV96].

7.8. ¿No ha cambiado el modelo de confianza en las versiones recientes de PGP?

Sí. Las nuevas versiones de PGP están basadas en un tratamiento mucho más riguroso de la confianza por Ueli Maurer [Mau96].

7.9. ¿Así que no hay problemas de propiedad intelectual con PGP v5+?

No exactamente. Hay dos posibles problemas de patentes en relación con los algoritmos implementados en PGP (y en docenas de otros tipos de software!):

1. En relación con SHA-1, Hitachi ha informado a la IEEE de que creen que SHA y SHA-1 podrían infringir las patentes 4.982.429 y 5.103.479.
   
2. En relación con DSS, Schnorr ha insinuado que DSS infringe la Declaración 6 de su patente 4.995.082.
   

[FIPS186-1] afirma decididamente "El Departamento de Comercio desconoce patente alguna que sea infringida por este estándar." y en [NIST98] "el NIST no es consciente de ninguna patente en EE.UU. que pudiera ser infringida por la práctica de la invención reclamada en su patente sobre DSA... el NIST no es consciente de ninguna patente en EE.UU. que pudiera ser infringida por el uso de SHA o SHA-1."

Todos los programas que implementan DSS o SHA podrían potencialmente infringir una de estas dos reclamaciones. Uno asumiría que de acuerdo con la ley de patentes de EE.UU., que afirma que si tienes una patente y no persigues una infracción podrías perder la patente [Sch96a], todas las reclamaciones válidas deberían estar hechas ya.

RSA está todavía patentada en EE.UU. En septiembre del 2000 la patente expirará. Resulta gracioso que RSALabs haya indicado [SD99] que van a registrar como marca comercial el término "RSA", a pesar de asegurar previamente a la IEEE lo contrario [SD98]. Parece que en septiembre del 2000 los usuarios podrán usar el esquema RSA, ¡pero los vendedores se verán forzados a llamarlo de otra manera!

NOTA: sugeriría que consulte un abogado especializado en patentes si lo anterior le preocupa.

7.10. ¿De verdad se preocupa alguien en comprobar el código fuente de PGP?

¡Sí! Yo personalmente he comprobado (en PGP v5.0i) la implementación de DES, CAST, IDEA, MD5, SHA-1, RIPE-MD con los vectores de comprobación. También he probado el código usado para las firmas DSS con lo vectores de comprobación que proporciona [FIPS186-1] lo que demuestra que la librería de Grandes Números funciona correctamente.

He comprobado la salida del RNG que usa PGP como se detalla en la sección "¿Cómo es de seguro el RNG de PGP?"

Yo, por supuesto, realizaría las comprobaciones anteriores con otros paquetes de seguridad similares (implementaciones de S/MIME por ejemplo) pero eso no es posible.

Según mi experiencia personal, hay más gente compilando, examinando y comprobando el código fuente de lo que uno ingenuamente esperaría. Por mi relación con Scramdisk, observo que de la base de usuarios (que estimamos en unos 20.000), he recibido e-mails de más de 40 individuos haciéndome a veces preguntas muy técnicas sobre el código fuente. Hay mucha más gente usando PGP que Scramdisk, así que podemos predecir que el número de personas que inspecciona el código fuente de PGP es lógicamente mucho más alto.

7.11. ¡ A menudo los mensajes cifrados y cifrados/firmados son menores que el original! ¿Por qué?

Antes de cifrarlos, los mensajes se comprimen usando algoritmos estándar de compresión [RFC1951]. Comprimir datos antes de cifrarlos ayuda a eliminar redundancias del texto en claro. La redundancia en el texto en claro podría ayudar al criptoanálisis [BW94], [Sch96a], [MOV96], [Pfl97], [Bau97].

7.12. ¿Rompería PGP el desarrollo de Ordenadores Cuánticos o de DNA?

¡Interesante pregunta! De hecho, son dos preguntas pues el cómputo Cuántico y el de DNA afectan a la seguridad de PGP de diferente manera.

En primer lugar los Ordenadores Cuánticos (QC). Si (y es un gran "si" [Sch96a], [RSA96a]) los QCs se vuelven una realidad práctica entonces tendría varias implicaciones en criptografía:

1. Todos los sistemas prácticos de CP se podrían romper en tiempo polinomial [RSA96a] (los QCs pueden factorizar y calcular logaritmos discretos de cualquier tamaño en tiempo polinomial.)
   
2. Los algoritmos simétricos que utilicen claves de longitud insuficiente serán reventados. Claves de 128 bits serán rotas con la facilidad con que lo son las de 64 bits hoy en día. Se piensa que los QCs no pueden romper claves simétricas de 256 bits. (ver Nota 5 y [Dif98]). Por supuesto, este comentario también se aplica a las funciones hash.
   

En segundo lugar, el cómputo con DNA, que parece ser más práctico que el de QC. Los ordenadores basados en DNA pueden ser usados para resolver cualquier problema que se reduzca al del camino Hamiltoniano [RSA96a], [Bea95], [Sch96a]. Esencialmente, el cálculo con DNA es como el cálculo clásico pero altamente paralelizado. El cálculo con DNA puede ser obstaculizado usando claves de suficiente tamaño (p.ej. las claves asimétricas de 4096 bits son ciertamente seguras contra los ordenadores basados en DNA). No se sabe aún si una clave simétrica de 128 bits es segura contra los ataques de ordenadores basados en DNA - un pesimista ciertamente tomaría en cuenta pasarse a claves de 256 bits (ej. AES) cuando sea posible [Bea95] hace notar que de acuerdo con la teoría actual sobre cálculos con DNA, se necesitarían 10¹²⁰ litros de DNA para factorizar una sola clave RSA de 1000 bits.

Recomiendo vivamente los artículos [Bea95] y [Sho94] como resumen de los ordenadores DNA y QC respectivamente, y en particular su aplicación a la factorización.

Todos los comentarios de esta sección se aplican tanto a PGP como a otros programas similares que usan criptografía de clave pública.

7.13. ¡PGP debe ser débil! ¡El gobierno de EE.UU. permite su exportación!

Totalmente falso. PGP se ha exportado recientemente con el siguiente método:

1. Imprimir el código fuente de PGP
   
2. Exportar los libros que contenían el código fuente (la libertad de expresión los protege). EAR la regulación sobre exportación, no cubre la exportación de material escrito. Ver como referencia EAR § 734.3(b)(2).
   
3. Volver a escanear los libros en un país extranjero y compilar el código fuente.
   

¡Estadounidenses afortunados, tenéis una gran constitución! Intentad vivir en el Reino Unido de la edad oscura alguna vez...

7.14. ¿No disminuye la seguridad distribuir el código fuente?

Absolutamente no. Un adversario razonablemente determinado puede simplemente aplicar ingeniería inversa al código máquina que constituye el programa y analizarlo [GW96]. Los estudiantes universitarios son capaces de llevar a cabo esta tarea, así que es extremadamente ingenuo pensar que las agencias de inteligencia no podrán hacerlo.

Como ejemplo, Netscape y Microsoft rehusaron liberar el código fuente de sus programas de seguridad para ser evaluados [GW96]. Como resultado de la falta de revisión, dos de las implementaciones de SSL más conocidas eran totalmente inseguras contra un adversario decidido. Obsérvese que incluso las versiones "seguras" de los navegadores (es decir las versiones domésticas en EE.UU. del software) padecían este agujero de seguridad.

Citando directamente el artículo: "La revisión por parte de los expertos es esencial para el desarrollo de cualquier software de seguridad. Netscape no animo las auditorías externas ni las revisiones críticas de su software - y eso va contra todo lo que la industria de la seguridad ha aprendido de anteriores errores. Por extensión, sin revisiones e intenso escrutinio externo del software de Netscape al nivel de código fuente, simplemente no hay forma de que los consumidores puedan saber si habrá problemas futuros de seguridad con los productos de Netscape."
...
"Estamos preocupados porque las compañías oculten información sobre sus módulos de seguridad y rehuyan las revisiones críticas"

Sin revisiones del código fuente, ¿cómo saber que el sistema criptográfico no esta filtrando información sobre la clave en cada firma o cifrado realizado? Las firmas que emplean canales subliminales son indistinguibles de las firmas normales - sólo el adversario (que tiene una clave secreta que le permite liberar los datos subliminales) es consciente de la existencia del canal subliminal.

Es una hipótesis estándar en la seguridad de la información (conocida como principio de Kerchkoff, también parafraseada por Shannon "El enemigo sabe el sistema que está siendo usado") que un adversario tiene acceso a los métodos usados en el proceso de cifrado [Sch96a], [MOV96], [Sti95], [Bau97] - la seguridad debe descansar por tanto en el secreto de la clave. Intentar obtener "seguridad a través de la oscuridad" parece imprudente a la luz del artículo de Goldberg y Wagner.

7.15. ¿Que es un "certificado gubernamental"?

El gobierno tiene un programa de certificación para módulos criptográficos [FIPS140-1].

NAI ha confirmado que están en el proceso de obtener el certificado FIPS140-1 para las primitivas usadas en PGP. De hecho, ya han recibido el certificado para DES y SHA-1.

El proceso de certificación implica remitir el código fuente al laboratorio de pruebas del NIST y puede requerir cambios en las primitivas usadas en el software. Como tal, puede considerarse un proceso iterativo. Uno de los problemas con la certificación es que sólo se refiere a la versión certificada. Por tanto la siguiente versión del software debe ser de nuevo remitida para su certificación.

En la práctica las certificaciones significan que PGP puede ser adquirido y usado por los departamentos del gobierno. También proporciona un "nivel base" para la seguridad en los algoritmos utilizados.

Como complemento, hago notar que algunas de las primitivas criptográficas usadas por Netscape (DES, DSA, SHA-1) han obtenido ya el nivel 2 de certificación cuando se ejecutan en "Sun Sparc 5 c/ Sun Solaris versión 2.4SE" y el nivel 1 en Windows NT Workstation.

El lector observador notará que la implementación del algoritmo de clave pública (RSA / DH o lo que sea) no se comprueba como parte de los estándares de evaluación.

Un problema con el proceso de certificación es que puede dar a los usuarios ingenuos una falsa sensación de seguridad en el producto evaluado. La implementación por parte de un programa de las primitivas criptográficas podría, por ejemplo, ser usada en un entorno que contiene serios fallos de seguridad que afecten la seguridad global del paquete. Estos fallos pueden no ser fáciles de encontrar ni evidentes. Sólo una revisión completa del paquete puede "probar" su seguridad.

No sólo el núcleo del código criptográfico necesita comprobación, el código en la periferia de la implementación también necesita ser comprobado, lo que FIPS140-1 no asegura. Para más información lea cualquier buen libro de texto sobre seguridad de la información o criptografía aplicada, por ejemplo [Sch96a] o [Pfl97].

7.16. ¿Por qué hubo tal retraso en la presentación de PGP v5?

Algunos se han quejado del retraso en la presentación de la v5 de PGP. Recuerde que Phil Zimmerman sufrió una investigación criminal durante tres años, que terminó a principios de 1996. Yo sugeriría que PRZ tenía un tiempo y recursos monetarios limitados para llevar a cabo mucho desarrollo durante ese periodo.

También debe observarse el largo "salto en capacidades" entre las versiones 2.x y 5.x. PGP tiene ahora funciones de hash muy fuertes, dos cifrados extra, un nuevo esquema de cifrado de CP, un esquema de firmado que se ajusta al estándar USG [FIPS186-1], integración con los servidores de claves etc.

7.17. ¿Quién confía en PGP?

Tomado de [Zim96]:

"Grupos de derechos humanos usan PGP en todo el mundo, los activistas por los derechos humanos que están documentando las atrocidades de los escuadrones de la muerte, entrevistando a los testigos y siguiendo con todo ello el rastro de los abusos contra los derechos humanos, cifran sus materiales con PGP, y me dicen que si el gobierno pudiera poner sus manos en ellos, detendrían a todos los testigos y los asesinarían después de torturarlos.

Eso ocurre en Centro América, y yo hablé con alguien trabajando con el programa allí. Los grupos de resistencia en Burma lo están usando. Burma tiene un gobierno realmente horrible, y hay grupos de resistencia usando PGP en los campos de entrenamiento de la jungla. Se les entrena para usarlo en ordenadores portátiles. Luego lo llevan a otros campos de entrenamiento y lo enseñan.

Dicen que ha la introducción de PGP allí ha ayudado a levantar la moral, los documentos capturados llevarían al arresto, tortura y ejecución de familias enteras. El gobierno del Tíbet en el exilio usa PGP. Hay varios otros ejemplos de países del tercer mundo con dictaduras brutales, donde los activistas por los derechos humanos están usando PGP."

De [Hof94]:

• Los profesores universitarios usan PGP para proteger la propiedad intelectual.
• Las empresas de contabilidad usan PGP para proteger las copias de seguridad de sus datos.
• Los abogados usan PGP para comunicarse confidencialmente con sus clientes.

De [Zim98a]:

• La relación de los activistas por los derechos humanos en Rumanía - probablemente se salvaron vidas por el uso de PGP.

Parece que la gente confía secretos comerciales, la confidencialidad de sus clientes y sus vidas a PGP. ¡Esto ciertamente pone mi uso del programa para cifrar comunicaciones personales en perspectiva!

7.18. ¿Cómo afecta el cifrado múltiple a la seguridad?

Esta pregunta puede ser interpretada de varias maneras:

1. ¿Cómo afecta cifrar un mensaje a múltiples receptores a la seguridad del mensaje?
   
2. ¿Aumenta la seguridad cifrar un mensaje ya cifrado (es común cuando se usan cadenas de remailers) ?

Contestaré a estas preguntas en orden:

Cifrar un mensaje a múltiples receptores lo hace tan fácil de romper como la más débil de las claves simétricas. Por ejemplo, si un mensaje se cifra a una clave de 786 bits y a una de 1024 bits entonces un adversario sería obviamente capaz de leer el mensaje si rompiera la clave menor.

Si un mensaje se cifra a receptores con claves asimétricas o simétricas diferentes - es decir uno con RSA otro con DH o uno con 3DES y otro con IDEA, entonces leer el mensaje es tan difícil como romper el cifrado simétrico de cualquiera de los cifrados asimétricos empleados.

Esto necesariamente introduce una debilidad teórica, pues un adversario puede atacar múltiples esquemas de cifrado para llegar a un mensaje protegido. Se piensa que todos los cifrados que emplea PGP son seguros, así que esta debilidad teórica no se traduce en ninguna debilidad práctica.

Los ultra-paranoicos podrían presentar un débil argumento para usar sólo un tipo de clave (tanto de las simétricas como de las asimétricas). Por ejemplo, un usuario podría rehusar aceptar tráfico cifrado con RSA (no creando una clave RSA) y rehusar aceptar o mandar mensajes utilizando otro cifrado que no fuera CAST. Esto minimizaría la debilidad teórica pero sugeriría que es totalmente innecesario.

Vamos con la segunda pregunta... Cifrar un mensaje que ya ha sido cifrado es ciertamente más seguro que un sólo cifrado. Para leer el mensaje en claro, un adversario tendría que descifrar dos niveles de cifrado de categoría militar - lo que es totalmente irrealizable. Pero espera - romper un sólo nivel de un cifrado de categoría militar es totalmente irrealizable también así que no hemos ganado nada en la práctica!

De hecho, hay una sutil debilidad teórica cuando se anidan mensajes PGP; los mensajes PGP tienen una cabecera estándar, así que romper el nivel exterior de cifrado puede ser equivalente a un ataque con texto en claro conocido - que es bastante más fácil que un ataque por fuerza bruta sin saber el contenido del mensaje subyacente. Nota: esto no afecta al "nivel interno" - que es tan difícil de romper como cualquier otro mensaje PGP.

Si usa remailers encadenados y cifrados anidados en ellos, esté seguro de que el mensaje es al menos tan difícil de romper como el texto cifrado una sola vez - y puede ser en la práctica mucho más seguro dependiendo de los recursos del adversario.

[Sch96a] contiene una buena descripción de los esquemas de cifrado múltiple.

Un problema cuando se anidan esquemas de cifrado (especialmente múltiples aplicaciones de la misma primitiva) es que las aplicaciones múltiples sean un "grupo" - es decir que cifrar un mensaje con dos claves Clave1 y Clave2 sea equivalente a cifrar una sola vez con una sola clave Clave3. No veo la forma de que aplicar varias veces el cifrado de PGP pueda constituir un grupo - pero tampoco he visto evidencias de que no pueda ocurrir (comprimir el texto con armadura ASCII antes de cifrar podría ayudar a desfigurar cualquier estructura).

7.19 ¿Cuáles son las implicaciones del dispositivo Twinkle de Shamir en la seguridad de PGP?

"TWINKLE" es un dispositivo teórico obra de Adi Shamir a comienzos de 1999 [Sha99]. Las siglas significan The Weizmann Institute Key Locating Engine (algo así como Máquina del Instituto Weizmann para Búsqueda de Claves).

TWINKLE es una máquina de criba que puede usarse para romper claves RSA y en un menor grado las DH/DSS. Por lo que sé, ninguna máquina TWINKLE se ha implementado hasta ahora, pero se cree que es factible. En lugar de investigar un nuevo método de factorización, TWINKLE simplemente acelera la implementación del algoritmo existente (NFS).

NFS consiste en dos pasos:

• Criba. Este paso puede ser distribuido entre muchas máquinas.
• Solucionar la matriz. Actualmente puede hacerse sólo en una máquina. Necesita mucha memoria.

Donde es posible, el dispositivo TWINKLE acelera dramáticamente la parte de criba del NFS. Se necesita un ordenador convencional para resolver la matriz resultante.

Recientemente, un equipo rompió un número de 465 bits usando NFS. La parte de criba uso 200 ordenadores durante 4 semanas y solucionar la matriz necesitó de un superordenador CRAY durante 4 días y 810 Mb de RAM. Como contraste [Sil99a], se necesitarían 6 máquinas TWINKLE como las de Adi Shamir durante unos 6 días (más 4 días en el superordenador para resolver la matriz).

Desgraciadamente, no parece probable que TWINKLE pueda escalarse a claves de 1.024 bits ( o incluso 768). Se prevee que 45.000 dispositivos TWINKLE necesitarían 500.000 años para cribar un entero de 1.024 bits y resolver la matriz necesitaría de al menos 5 terabytes de RAM y más de 5 millones de años [Sil99b]. Siendo realistas, parece que TWINKLE sólo puede amenazar a las claves en el rango de 512 a 600 bits.

TWINKLE puede atacar las claves DH/DSS del mismo modo que las RSA. PERO ( y es un gran pero...), resolver la matriz con las claves DH es mucho más difícil porque uno tiene que [Sil99b] "resolver la matriz módulo el orden del grupo o cuerpo" en vez de módulo 2.

Es también interesante observar que las estimaciones de seguridad para las CE no se ven afectadas por TWINKLE [Sil99b], [Cer99].

Realmente, TWINKLE nos confirma algunos pensamientos previos:

• Las claves de 512 bits son inseguras contra un adversario determinado. Se cree que las claves de 1.024 bits son todavía seguras.
• Las claves RSA son en la práctica más susceptibles que las DH del mismo tamaño.

Como resumen: PGP (desde v5.5) sólo permite la creación de claves >= 768 bits - así que ninguna de las claves PGP producidas recientemente se ven comprometidas por este desarrollo.

Si está interesado en leer sobre TWINKLE recomendaría el artículo original de Adi Shamir [Sha99] y el análisis de Robert Silverman [Sil99a].

7.20. ¿Por qué firmar antes de cifrar?

Cuando un usuario solicita que PGP cifre y firme un mensaje, el programa (y todos los sistemas de CP que conozco) primero firma el mensaje y luego cifra la concatenación de la firma y los datos.

Es posible implementarlo de esta otra forma: primero cifra los datos y luego firma el texto cifrado. Transmite tanto los datos cifrados como la firma.

Dos razones para no aplicar el algoritmo de firma (ya sea RSA o DSS) después del cifrado:

1. Principalmente porque firmar un texto firmado permite a un adversario quitar la firma correcta transmitida y reemplazarla por otra firma (producida con una clave diferente). Esto permite a un adversario firmar un mensaje (incluso no sabiendo su contenido) y el receptor ingenuo puede pensar que el mensaje tuvo su origen en el adversario [Sti95]. ¿Sigiloso no?
   
2. La información sobre el emisor y el receptor real se descubre. Al tener la firma fuera de la sección cifrada es posible para un adversario leer la identidad de las claves del emisor (cabecera de la firma) y del receptor (cabecera de cifrado) Al firmar primero, y luego cifrar, sólo se rebela información sobre la clave del destinatario.
   

Puedo imaginar algunas oscuras situaciones en las cuales te gustaría autentificar / verificar un mensaje fuera del cifrado. Para implementarlo, simplemente cifre (y opcionalmente firme) un mensaje con PGP y luego firme el mensaje cifrado resultante. Simple.

7.21. ¿Qué comparación puede hacerse entre la seguridad de los estándares OpenPGP y S/MIME?

La siguiente tabla identifica los algoritmos obligatorios en S/MIME (v3) [IETF98] y OpenPGP [RFC2440]:

Tabla 7: Comparación entre S/MIME y OPENPGP

Por supuesto, es la implementación del estándar lo que dicta la seguridad, no el estándar "teórico". (Obsérvese que ElGamal y DH son equivalentes - ver Nota 1). A los lectores confusos por el significado de "DEBER" en los documentos de la IETF se les remite a [RFC2119].

El tamaño de la clave asimétrica es de gran importancia en PGP y S/MIME. La tabla 1 en la sección "¿Qué tamaño debería tener mi clave asimétrica? " lista las longitudes de claves públicas recomendadas para protegerse del ataque de una sola corporación (¡las claves deberían ser bastante mayores para protegerse contra las agencias de inteligencia!). Así que... el estándar S/MIME especifica un tamaño máximo de clave pública de 1024 bits, que de acuerdo con la tabla anterior ¡no ofrece suficiente protección a largo plazo contra una corporación decidida! El estándar OpenPGP y la implementación de NAI del estándar, permiten claves públicas de hasta 4096 bits, que deberían proteger datos en el futuro próximo.

ANSI X9F1 obliga a una longitud mínima de clave de 1024 bits para RSA y DH, pero S/MIME sólo proporciona claves como máximo de 1024 bits.

Algunos argumentarán que las futuras versiones del estándar S/MIME podrían posiblemente obligar al uso de claves mayores de 1024 bits. Esto significa que un adversario decidido y con buenos fondos podría leer tus comunicaciones actuales en 5 años o así.

Uno de los documentos periféricos de S/MIME [PKIX98] describe una característica de S/MIME llamada "Prueba de Posesión de Clave Privada (PoP)". Este es un mecanismo por el cual las claves privadas del usuario pueden ser depositadas en la AC cuando se pide un certificado. Esta es una inclusión muy preocupante y hace de la implementación de la custodia obligatoria de claves un asunto trivial [Gut99].

El borrador del estándar PGP no contiene referencias a tal tecnología de recuperación de claves pero, interesantemente, PGP v5+ incluye una característica llamada Clave Adicional de Descifrado - algo a lo que a veces también se le llama Recuperación de Mensajes Corporativos. Como se ha mencionado anteriormente, esta característica no forma parte del estándar OpenPGP. Los usuarios interesados en leer sobre esta característica pueden dirigirse a [Bar99a].

Se cree que la inclusión de la PoP se añadió al estándar PGP por requerirlo la USG. Personalmente creo que debería haber un pronunciamiento claro sobre si el estándar S/MIME necesita de TTPs incondicional o funcionalmente fiables (como en [MOV96]) - y no un confuso estándar que está sujeto a presiones políticas.

Completémoslo diciendo que PGP especifica el modo de encadenamiento CFB mientras S/MIME obliga a usar el modo CBC. Ambos modos son equivalentes en cuanto a fortaleza [Sch96a], [MOV96] asumiendo que un IV único (o datos aleatorios añadidos al comienzo del mensaje) pueda ser aportado al modo CFB. PGP ya implementa un RNG así que proporcionar estos datos aleatorios no es un problema.

Por supuesto, uno puede aplicar teoría estadística simple a las implementaciones de PGP y S/MIME. Programadores y criptógrafos independientes han sometido al código fuente de PGP a literalmente miles de horas de análisis. No se puede hacer un análisis similar de la implementación de S/MIME pues el código fuente no se distribuye.

Ya que no podemos probar que no haya debilidades en ambas implementaciones, la probabilidad de que haya tales debilidades está en función inversa a las horas que los expertos hayan pasado buscándolas. Uno no debe afirmar que EXISTAN dichas debilidades para argumentar. Por tanto el riesgo al usar PGP es menor que el riesgo al usar las implementaciones de S/MIME de las que no disponemos del código. Es simplemente teoría de decisión estadística aplicada.

¿Cuántas horas de experto se han invertido en buscar errores en PGP? Ver la sección "¿Realmente se molesta alguien en comprobar el código fuente de PGP?". ¿Cuántas horas han invertido los expertos en comprobar errores en S/MIME? ¿Quién puede decirlo? Uno podría posiblemente argumentar que el núcleo de S/MIME ha sido comprobado exhaustivamente por los que implementan el sistema (pero observe que las diferentes implementaciones de S/MIME usan diferentes librerías criptográficas), pero recuerde que en el contexto de la seguridad, el código de la periferia (es decir no sólo el núcleo criptográfico) puede tener un impacto directo en la seguridad. Así que volvemos a la "falta de revisión por expertos" tal y como se presenta en [GW96].

Se podría publicar una versión de S/MIME (¿o ya lo ha sido?) que implemente la "cleptografía" - es decir implementar rutinas de generación de claves en DH o RSA que produzca claves aparentemente normales, pero que permitan a una tercera parte (que tiene una "clave de apertura") recuperar la clave privada. Esto es un interesante desarrollo en el concepto de canales subliminales, documentado por primera vez por Gus Simmons. Para más información consulte el artículo [YY96]. No existe tal canal encubierto en PGP v5.0i - un vistazo rápido al código fuente revelaría el código culpable.

Es importante, que los usuarios no estadounidenses de S/MIME se quedan con RC2/40 un cifrado simétrico de 40-bits y cifrados asimétricos <=512 bits, claramente inseguro. De [IETF98]: "la criptografía de 40 bits se considera débil por la mayoría de los criptógrafos. Usando criptografía débil S/MIME ofrece poca seguridad real al enviar texto en claro." Bruce Schneier ofrece un salvapantallas que rompe por fuerza bruta claves de 40 bits usando el tiempo de inactividad de un PC estándar.

Es peor que eso realmente... Muchas implementaciones de los cifrados fuertes no interoperan con RC2 de 40 bits [Sch97b], [WIR97a]. Malas noticias para el usuario final.

PGP usa claves simétricas de 128 bits y asimétricas de hasta 4.096 bits independientemente del país. Así, los usuarios de PGP pueden comunicarse de forma segura mientras que los usuarios de S/MIME no pueden actualmente.

Desde la perspectiva de la seguridad, PGP puede ser considerado correctamente como más seguro que S/MIME por las siguientes razones:

1. S/MIME está limitado a claves públicas de 1024 bits; PGP puede acomodar claves de hasta 4096 bits.
   
2. El certificado estándar de S/MIME contiene características que pueden ser usadas fácilmente para la custodia obligatoria de claves. No existen tales características en el estándar PGP.
   
3. Las implementaciones de PGP están abiertas y sujetas a detalladas revisiones por expertos. Los usuarios de S/MIME tienen que confiar en la implementación. Para citar a la NSA [Sch96a] "...la mayoría de los fallos en esta área de interés se deben a los fallos en la implementación, no a fallos en algoritmos o protocolos" y [And93] "la gran mayoría de los fallos de seguridad ocurre al nivel de detalles de implementación". Así que, como parte del procedimiento para la licencia de exportación, la NSA puede revisar la implementación de S/MIME y explotar por tanto cualquier debilidad, pero los usuarios finales no tienen ese privilegio [GW96].
   
4. Los usuarios fuera de EE.UU. de S/MIME pueden usar sólo claves de 40 bits lo que, de acuerdo con la documentación de S/MIME [IETF98]: "ofrece poca seguridad real al enviar texto en claro."
   

Una vez más, para citar a Schneier [Sch98i]: "El estándar de correo S/MIME 2 tomo un diseño relativamente fuerte y lo implementó con un algoritmo criptográfico débil"..."La funcionalidad no es lo mismo que la calidad, y ninguna cantidad de beta testing revelará todos los fallos de seguridad".

Un artículo escrito por un criptógrafo bien conocido [GW96] ha proclamado del navegador de Netscape (un programa bien conocido que pretende implementar el estándar S/MIME) "Hasta que aprendan la lección y abran su programa de seguridad a la evaluación pública, muchos expertos en seguridad permanecerán justificablemente escépticos sobre las pretensiones de seguridad de la compañía".

7.22. El programa x ofrece una clave de 200 bits, ¿es mejor que PGP?

Esta es una pregunta que hacen muchas veces los nuevos usuarios, y suscita una serie de puntos interesantes:

1. La necesidad de claves más largas. ¿Ofrece el uso de claves más largas que las ofrecidas por PGP alguna seguridad adicional?
   
2. ¿Se publica el código fuente para ser revisado por los expertos?
   
3. ¿Disfruta ese software de un uso tan extendido como PGP? ¿Tendrá el receptor deseado una copia del programa?
   
4. ¿Ha sido el software revisado tan minuciosamente como PGP?
   
5. ¿Son todas las primitivas criptográficas (cifrados simétricos y asimétricos, función hash etc.) igualmente fuertes? ¿Usa un cifrado "propio"? - estos son invariablemente más débiles que los algoritmos probados y comprobados.
6. ¿Hay fallos en los protocolos?
   

Desdichadamente, la criptografía no es como cualquier otra ciencia; nosotros normalmente confiamos en la evidencia empírica para juzgar la fortaleza de los algoritmos empleados y las implementaciones de los sistemas. La criptografía mala tiene el mismo aspecto y olor que la buena.

A veces es útil pensar en el cifrado como una cerradura de combinación en una caja fuerte. ¿Es mejor tener una caja con un número mayor de posibles combinaciones? Si todas las demás cosas son iguales, la respuesta es sí. Pero esas "otras cosas" normalmente no son iguales. Algunas cerraduras pueden abrirse sin probar todas las combinaciones. Vd. no querría que las cosas valiosas de su hogar estuviesen protegidas por una cerradura con trillones de combinaciones pero que cualquiera con un estetoscopio pudiese abrir.

Las claves cortas garantizan la debilidad, pero las claves largas no aseguran la fortaleza.

Si ha leído lo anterior (también sugeriría las FAQ del Aceite de Serpiente), y todavía piensa que los beneficios superan a los perjuicios, sírvase usted mismo.

7.23. ¿Así que PGP es perfecto?

No.

PGP es un estándar en evolución y como tal mejora constantemente. La siguiente lista destaca algunas quejas frecuentes sobre los elementos criptográficos de OpenPGP:

1. Disparidad en el tamaño de la clave DSS. Las claves DH pueden tener hasta 4096 bits, las firmas se limitan a 1024 bits. La situación podría cambiar con la introducción de un nuevo estándar federal de firma, pero esto podría llevar cierto tiempo. Como parche, las implementaciones podrían ofrecer firmas ElGamal mayores de 1024 bits (tal y como lo permite el estándar OpenPGP).
   
2. Algunas implementaciones ofrecen una característica llamada "Clave Adicional de Descifrado". Esta es, en mi humilde opinión, verdaderamente horrible y afortunadamente ha desaparecido del estándar OpenPGP. Vea [Bac99b] que contiene un argumento para explicar por qué la Recuperación Corporativa de Mensajes es inaceptable.
   
3. El uso de "Cifrar a sí mismo" (Encrypt to self) como mecanismo para proporcionar almacenaje "seguro" del correo enviado. Idealmente PGP proporcionaría una clave de "archivo" diferente para cifrar datos que serán almacenados a largo plazo [Bac99b].
   

8. Conclusión

"Nadie será objeto de injerencias arbitrarias en su vida privada, su familia, su domicilio o su correspondencia, ni de ataques a su honor o a su reputación. Toda persona tiene derecho a la protección de la ley contra tales injerencias o ataques."
-- Artículo 12, Declaración Universal de Derechos Humanos

"Hace falta ser un hombre para soportar la ignorancia y sonreír."
-- Sting

Al parecer hay varias razones para los cambios entre las versiones v2.x y v5+, principalmente:

1. Serias dudas sobre la seguridad a largo plazo que ofrece MD5. El algoritmo de hash usado por PGP es fundamental para su seguridad - una función de hash rota podría hacer las implementaciones de PGP totalmente inseguras.
   
2. El movimiento de PGP hacia un estándar abierto y público para la seguridad en el correo electrónico. La inclusión de RSA e IDEA como algoritmos "OBLIGATORIOS" ciertamente tendría un impacto negativo en la adopción de PGP como estándar de Internet (una transición similar se observa en el estándar S/MIME). Uno también recuerda los problemas con las librerías RSA esbozados en la sección "La licencia de RSAREF"
   
3. En una tentativa de continuar ofreciendo una versión Freeware comercialmente viable, ha sido necesario abandonar el uso de RSA, debido a problemas con la licencia RSAREF.
   
4. La adopción del Digital Signature Standard (DSS) como algoritmo de firmado en PGP. Este es ahora el estándar del gobierno y de facto para utilizar firmas digitales.
   
5. El dividir las claves de cifrado y firmado - esto permite la presentación obligatoria de claves de firmado sin divulgar la clave de firmado lo que necesariamente invalidaría la no-repudiación.
   
6. Arreglar dos problemas (no relacionadas con MD5) de las versiones anteriores a v5 de PGP: crear un ID arbitrario y una clave con la misma huella digital que otra (Ver Nota 6). Estos cambios habrían necesariamente invalidado las claves existentes.
   

PGP tenía que cambiar la implementación de PGP de formas que hubieran invalidado las claves anteriores, no es por tanto irrazonable que cambien también el cifrado asimétrico usado en PGP. Los usuarios pueden todavía usar claves RSA (aunque esto pueda significar usar una versión Internacional de PGP o pagar por la versión RSA) si se necesita usar las claves antiguas. Sin embargo en vista del asunto MD5, esto parece imprudente.

Un argumento ha sido que ElGamal tal y como se implementa en PGP podría ser defectuoso - es decir que podría haber una sutil debilidad en la implementación. El usuario debería recordar que ElGamal se basa en las mismas operaciones matemáticas y funciones que RSA, es decir: aritmética básica con grandes enteros, exponenciación modular, inversos modulares, MCD, algoritmo extendido de Euclides, teorema chino del resto, recíprocos etc. [Dif98], [Sil96b] (ver también Nota 4), todas las cuales han sido, en este momento, comprobadas exhaustivamente.

PGP v5+ es ciertamente criptográficamente más sólido que las versiones anteriores de PGP. También parece haber habido otras influencias, principalmente las listadas arriba, que han requerido los cambios vistos entre estas versiones.

La única razón válida que puedo encontrar para usar claves RSA con preferencia a las nuevas DH/DSS es comunicarse con un receptor que tiene sólo las claves antiguas, o si no hay una versión nueva de PGP disponible para su plataforma.

8.1. Sumario de PGP DH frente a PGP RSA

En resumen, las claves PGP DH pueden ser consideradas más fuertes que las claves PGP RSA por las siguientes razones (he quitado las referencias en esta sección en favor de la claridad - refiérase a las anteriores secciones del documento para justificar estas afirmaciones):

1. DH y DSS ofrecen un poco más de seguridad por bit que RSA. Esto probablemente seguirá siendo así. Por otro lado, RSA ofrece más seguridad por ciclo de reloj que DH/DSS.
   
2. La función hash usada por las claves RSA tiene defectos graves. Recuerde el comentario de Schneier "Recelo de usar MD5". Las claves DH usan SHA-1 (o RIPEMD). Claro que es posible (con las nuevas versiones de PGP) seleccionar la función hash que se usa con las claves RSA, pero estas firmas son incompatibles con el estándar de las versiones v2.x de PGP y siguen sufriendo de los ataques a la ID de la clave (descritos después). Las claves RSA siempre usan MD5 para crear las huellas digitales [Bar99b].
   
3. Se pueden crear claves RSA con una ID o huella digital arbitraria - que puede ser usada para burlar a los servidores de claves. Esto no es posible con las claves DH.
   
4. Las claves DH permiten elegir entre múltiples cifrados. Si un cifrado se rompe no todas las claves DH quedarán inutilizadas. Si IDEA es roto todas las claves RSA son inútiles.
   
5. Las claves DH constan de dos partes: clave de firmado y clave de cifrado. Romper (o forzar a divulgar) una de las claves no rompe la otra. El romper una clave RSA permite a un adversario descifrar y firmar.
   
6. Las claves DH pueden tener múltiples claves de descifrado. De esta manera un clave maestra (de firmado) puede conservarse muchos años utilizando múltiples claves de descifrado para minimizar el daño que haría una "ruptura general" en una de las claves de cifrado. De nuevo, esta característica no esta disponible con las claves RSA.
   
7. Teóricamente, las claves DH parecen más fuertes que las RSA. Observemos que algunos ejemplos del DHP son probadamente equivalentes al difícil problema matemático subyacente (PLD). No se ha mostrado ninguna equivalencia así para RSA, de hecho se demuestra que algunos casos del PRSA no son equivalentes al problema subyacente (PFE).
   

El único argumento que encuentro para no usar claves DH/DSS es que las claves de firmado RSA pueden ser significativamente más grandes que las DSS, sin embargo este punto se contrarresta fácilmente:

1. Las firmas RSA "estándar" (tal y como se implementan por defecto) están basadas en MD5, que se considera roto.
   
2. Si se necesita seguridad a largo plazo gracias a las firmas digitales, puede simplemente usar sellados de tiempo y marcaje de documentos.

Por favor, hágame saber si se le ocurren otras razones por las que un tipo de clave sea más fuerte que la otra.

8.2. ¡ Ve el riesgo con una cierta perspectiva!

La NSA probablemente no está específicamente interesada en Vd. No van a forzar la puerta de tu casa para instalar micrófonos, o monitorizar tu pantalla desde una manzana de distancia. Sin embargo recogerán todos tus mensajes enviados por una red pública.

PGP le protege de la monitorización - Echelon u otros métodos de espionaje pasivo de redes. Cuando su mensaje es capturado por este sistema de monitorización global, junto con millones de mensajes más cada día, al NSA puede probablemente intentar decodificar tu mensaje.

El riesgo más significativo para PGP proviene de la dejadez de los usuarios. Es mucho más fácil instalar un registrador de pulsaciones en tu ordenador, instalar un troyano de PGP o romper por fuerza bruta tu frase clave que romper cualquiera de los mecanismos criptográficos que emplea PGP.

Si estás seriamente preocupado por que las Agencias de Inteligencia te estén monitorizando, lo último de lo que deberías preocuparte es de un ataque criptográfico contra tu implementación de PGP.

8.3. ¿Y qué más? ¡Aún no estoy convencido!

Si, después de haber leído todo lo anterior, aún no está convencido de los beneficios de las claves DH sobre las RSA todavía tienes la opción de:

1. Inspeccionar el código fuente y convencerte de que funciona correctamente.
   
2. Usar una versión más antigua de PGP.
   
3. Cambiar de sistema de cifrado (S/MIME por ejemplo - y soportar las inevitables y severas limitaciones de seguridad).
   
4. Usar la versión internacional de PGP. (NOTA: el uso de versiones internacionales de PGP "con RSA habilitado" dentro de EE.UU. podría estar sujeto a problemas de patentes).
   
5. Usar PGP v6.02 (sin capacidades RSA) bajo la versión de 128 bits del IE v4 que ofrece un RSA limitado vía CAPI.
   
6. ¡Pagar por el programa que tanto necesitas! (la versión comercial de PGP todavía ofrece la antigua implementación de RSA).
   

8.4. Palabras finales

¿Por qué ofrecer mi opinión subjetiva sobre PGP como sumario? No lo haré. En su lugar utilizaré 3 citas (¡me gustan las citas!):

[Sch96a] sobre PGP:

"Suponiendo que confíes en IDEA, PGP es lo más parecido que posiblemente conseguirás a un cifrado de calidad militar".

[PGP98] resume perfectamente la seguridad de PGP v5+ :

"Si tu situación justifica que te preocupes por ataques formidables de este calibre, entonces quizá deberías contactar con un consejero de seguridad de datos en busca de una solución adaptada a tus necesidades especiales."

Las palabras finales de estas FAQ tienen que ser de Whitfield Diffie, distinguido progenitor de la criptografía de clave pública [DL98]:

"Al escribir PGP, Phil Zimmerman hizo algo por la criptografía que ningún artículo técnico podría hacer: dio a la gente preocupada por su privacidad que no eran criptógrafos (y ni siquiera necesariamente programadores) una herramienta que podían usar para proteger sus comunicaciones".

9. Lecturas adicionales.

Sólo voy a hacer tres recomendaciones:

Applied Cryptography (2&ordf; edición) por Schneier - Una introdución extensa y definitiva a la criptografía.

Handbook of Applied Cryptography por Menezes, van Oorschot y Vanstone - un "hito" y muy riguroso.

Privacy on the Line por Diffie y Landau, 1998 - el padre de la CP pasa revista a la política que rodea el debate sobre la criptografía.

10. Notas

(1) Para romper DH, uno necesita ser capaz de encontrar g^ab sabiendo sólo g^a y g^b. Para romper ElGamal, uno necesita determinar P, sabiendo g^k y Pg^ak, con g^a que también es público. Pero entonces romper ElGamal es equivalente a encontrar g^ak, sabiendo sólo g^a y g^k -- el mismo problema que es necesario resolver para romper DH. (Todo lo anterior por supuesto sobre un "gran" cuerpo finito cuyo tamaño es público.) Así que roto uno roto el otro, tanto si solucionas el PLD como si no. Sin embargo, se conjetura que no hay forma de resolver el problema anterior sin esencialmente resolver el PLD.

(2) De el código fuente de PGP v5.0:
Componentes de la clave pública:
n el módulo público
e el exponente público
Componentes de la clave privada:
d el exponente de descifrado (igual a e^-1 mod ((p-1)(q-1))
p el menor factor de n
q el mayor factor de n
u 1/p (mod q)

El cifrado en pseudocódigo:
MensCifr = MensDesc^e mod n

El descifrado en pseudocódigo:
MensDesc = MensCifr^d mod n

(3) Tomado directamente del código fuente de PGP v5.0:
Componentes de la clave pública: p primo público
g generador público
y clave pública, g^x mod p

Componentes de la clave privada:
x clave secreta, logaritmo discreto de y

(4) Del código fuente de 2.6.3i MPILIB.H:
"Estas rutinas implementan toda la aritmética multi-precisión necesaria para algoritmos criptográficos de la teoría de números como ElGamal, Diffie-Hellman, Rabin o estudios de factorización de grandes enteros compuestos, asi como criptografía de clave pública RSA (Rivest-Shamir-Adleman) ."

(5) "Aunque la computación cuántica puede hacer que problemas como la factorización y los logaritmos discretos (en los que los logaritmos de clave pública se basan) se vuelvan fáciles, sólo pueden reducir la complejidad de cualquier cálculo por una raíz cuadrada. Así que, por ejemplo, si una clave de 128 bits de longitud fuera suficiente antes del cálculo cuántico, después se necesitarían 256 para lograr la misma seguridad."
-- B.Schneier, 10 de Octubre de 1998 escribiendo en el grupo de USENET soc.history.what-if.

(6) "¿Cómo podemos, en conciencia, permitir a los usuarios generar claves que no alcanzan nuestros estándares de seguridad? No podemos. Caso cerrado. Si no estás familiarizado con la razón por la que las claves RSA no son tan seguras como nos gustaría, deberías comprobar los archivos de los grupos de noticias de los últimos años.

Las debilidades de MD5 y el ataque contra la ID de la clave fueron dos puntos primarios de seguridad que sentimos que tenían que ser solucionados en la 5.0. Al equipo de desarrollo no podían importarle menos los asuntos de la patente RSA.

El único punto era la seguridad. Arreglarlo hacía necesario un nuevo formato. Ya que estabamos cambiando el formato de la clave, decidimos pasarnos a algoritmos sin problemas de patentes ya que el impacto sería el mismo -- todo el mundo necesitaría nuevas claves. Si a un usuario en particular no le preocupan los problemas de seguridad de las claves RSA, deberían sentirse libres de continuar usándolas aunque el número de versiones nuestras que las utilicen seguirá sin duda disminuyendo, y al mismo tiempo el número de versiones y plataformas usando claves DH/DSS crecerá dramáticamente."
-- W.Price, Nov. 97 escribiendo a la lista ietf-open-pgp