ÚLTIMA
ACTUALIZACIÓN DE ESTA PÁGINA: 7 DE NOVIEMBRE
DE 2007
Firmas PGP:
Descarga desde aquí la Firma PGP del sitio www.gnosis2002.com |
En pocas palabras:
Todos los libros en teoría libres de errores o mejor
dicho: revisados exhaustivamente (casilla de título color verde) están firmados
con PGP. La firma sirve para garantizar que el texto del libro no sea
modificado después de firmarse (puede modificarse el libro, pero en ese caso al
comprobar la firma se sabe), para hacer la comprobación necesitas instalar el
programa PGP en tu computadora. Nosotros hemos usado la versión 6.5.8 CKT de
PGP (es muy especial, más adelante en este documento está la discusión completa
del porqué de elegir esta versión).
Para saber cómo instalar y configurar el PGP te
recomendamos esta página (si no conoces de nada el programa vale la pena que la
visites): http://www.ugr.es/~aquiran/cripto/cursopgp.htm
Toda esa información la hemos
recopilado en un documento por si desaparece la página, también puedes
descargar desde aquí el programa
PGP versión 6.5.8 CKT build 8 que es la versión con la que hemos firmado
todos los libros (bájate la 6.5.8 CKT Build 9
Beta 3 si usas Windows XP), y nuestra firma digital
oficial, que necesitarás para poder comprobar las firmas de los libros una
vez tengas instalado el programa.
Si PGP sólo te interesa para comprobar nuestras firmas, no tienes más que:
1. Bajar el programa y nuestra firma. Una vez instalado el programa se verá un candado en la barra de tareas.
2. Baja nuestra firma y descomprímela, para agregarla pincha en el candado y se abrirá un menú, elige PGPKeys, se abrirá una ventana, en el menú Keys, elige la opción Import...
3. Esto abre un cuadro de diálogo que te pide el archivo de firma o clave pública, tienes que darle la ruta del archivo de firma que has bajado (sólo hay que hacer estos 3 pasos la primera vez que vayas a comprobar una firma, las demás veces sólo harás el siguiente).
4. Una vez importada nuestra firma, cuando quieras comprobar la de un libro la verás como un pequeño archivo aparte (cuando descomprimes el archivo .zip de cualquier libro, viene en él un archivo .doc que es el libro en formato Word, y otro con el mismo nombre y extensión .sig que es la firma del libro). Sólo tienes que hacer doble clic en la firma para comprobarla. Si el libro está como lo dejamos cuando se firmó verás la fecha y hora de firma, si se ha modificado por algún motivo, veras el mensaje: BAD SIGNATURE.
Si necesitas saber algo más sigue leyendo:
Introducción obligada:
Lo primero será especificar que necesidad tenemos de
seguridad: Deseamos que cualquiera pueda verificar que un libro, una grabación
o cualquier archivo publicado en www.gnosis2002.com
y verificado por los autores no es modificado después por nadie. Así, si el que
obtiene ese libro o archivo confía en el trabajo que hicimos recopilando la
obra de Samael Aun Weor en su día, puede comprobar que lo que le llega es lo
que nosotros dejamos. Esto es interesante porque los intermediarios en la
cadena son pocos:
Hay dos cuestiones: Una la confianza que se tenga en
nuestra mediación. Diré sólo esto en nuestra defensa:
La otra cuestión es: suponiendo que se confía en nuestra mediación
¿se puede estar seguro de que lo que nosotros hemos publicado permanece
inalterado? Afortunadamente la respuesta es sí: Existen sistemas de
autentificación digital que hoy por hoy son seguros, y nos hemos cuidado de
elegir la forma en que los usaremos para alargar lo máximo posible el que lo
sigan siendo en el futuro.
El resto del documento está dedicado a explicar qué
decisiones se han tomado para lograr esta seguridad, dar idea de cómo es de
segura, y plantear sus fundamentos comprensiblemente. Sólo comprendiendo todo
lo que sigue se podrá estar seguro en el futuro (cuando ya no sea seguro el
procedimiento usado) de lo que ahora se ha hecho.
El programa usado: PGP 6.5.8 CKT Build 8,
razonamiento de por qué se elige:
Puede que haya oído hablar del programa PGP (Pretty Good
Privacy, en castellano: privacidad bastante buena). Si no es así empecemos por
decir que es un programa que permite cifrar un documento digital mediante un
criptosistema simétrico combinado con otro asimétrico (simétrico significa que
usa la misma clave para cifrar y descifrar, existen también los asimétricos que
usan dos claves inversas entre sí: lo que cifra una, sólo con la otra se puede
descifrar). Lo que hace PGP es que cifra con una clave simétrica diferente para
cada mensaje, y luego manda esa clave al destinatario (junto con el mensaje
cifrado) de forma segura cifrando la clave simétrica con la clave pública del
destinatario, este último tiene su clave privada para descifrar, cualquiera de
las claves de un par pueden cifrar y descifrar entre sí, pero se usa siempre
una clave para cifrar –pública: no importa quien la conozca– y otra para
descifrar –privada: se ha de mantener en secreto, de este modo sólo el
destinatario pueda descifrarlo (ni siquiera el que cifró puede hacerlo porque
sólo con la otra clave asimétrica del par es posible descifrar lo que se ha
cifrado con una de ellas), así es como puede existir privacidad en el correo
electrónico y en general en cualquier intercambio de material digital. Al ser
únicos los pares de claves que cada persona usa, el programa también sirve para
certificar con una firma digital única cualquier documento digital de modo que
pueda saberse si ha sido alterado después de firmarse y, si se tiene confianza
en la firma, se sabe también si es de quien dice ser. Eso y algunas cosas más
permite el PGP, de todo ello se puede uno enterar en http://www.ugr.es/~aquiran/cripto/cursopgp.htm
que es un cursillo de PGP bastante ameno escrito por Arturo Quirantes Sierra,
(existe además toda una sección dediacada al tema del mismo autor en: http://www.ugr.es/~aquiran/cripto/pgp.htm).
PGP es simplemente una inteligente combinación de los dos
modos de cifrado (simétrico y asimétrico). El simétrico, robusto y rápido, para
cifrar y descifrar correo electrónico, y el asimétrico, más lento, para
compartir la clave simétrica de forma segura por un canal inseguro como
internet y para tener firma digital. Es lo mejor que hay hoy día en
criptografía fuerte aplicada y lo que usaremos para nuestra tarea de
"certificar" los archivos de la página. Lo que vamos a explotar de
PGP es su sistema de cifrado asimétrico para poder firmar los libros de la
página www.gnosis2002.com, los cuales
ha costado mucho recopilar y revisar, y al fin y al cabo son simplemente texto
que cualquiera puede alterar. ¿Para qué firmarlos? Pues para que cualquiera
pueda comprobar esa firma y estar seguro de que el texto que le llega es el que
nosotros dejamos en la página. (si todo esto de la
criptografía nos suena a chino, no está de más ver un curso profundo como el
que publica gratuitamente el profesor de la universidad politecnica de Madrid
Jorge Ramió Aguirre en: http://www.lpsi.eui.upm.es/SInformatica/descarga/SItemas.zip).
¿y Eso es posible? Sí es posible,
y aunque una explicación somera como esta no demuestra de manera satisfactoria
esa seguridad, servirá para dar una idea y plantear las decisiones tomadas.
Toda la criptografía asimétrica se basa en una parte de la
matemática discreta (la parte de las matemáticas que se ocupa de los
números enteros) llamada aritmética modular, en concreto en la
imposibilidad práctica de resolver dos problemas íntimamente relacionados: El
Problema de la Factorización de Enteros (PFE) y el Problema del Logaritmo
Discreto (PLD). Se ha demostrado que si se resuelve el PFE, la solución del PLD
es inmediata y viceversa, luego el debate de si es mejor o peor el
criptosistema Diffie-Hellman/elGamal (que se basan en PLD) que el viejo RSA
(basado en PFE) en el fondo es como discutir si cuando te quedas ciego el color
amarillo es mejor que el rojo: obviamente una vez ciego uno ya no se ve ningún
color, igual pasa aquí: por muchas razones que se argumenten en favor de uno u
otro si cae un sistema, cae el otro. Históricamente el fomento de uno y otro se
debe a cuestiones económicas (patentes USA).
Nosotros hemos optado por el criptosistema RSA ya que ha
superado la prueba del tiempo (es un estándar de hecho, se conoce y se
comprende bien, hay implementaciones muy probadas y de calidad, lo que es
importante porque usar algo muy novedoso también tiene sus riesgos).
Teóricamente los criptosistemas de última generación son más sólidos, pero en
realidad, como se basan en lo mismo, lo normal es que el día que se acabe
"el chollo" de la imposibilidad de resolver problemas computacionalmente
intratables como los mencionados PFE y PLD (por ejemplo cuando se implemente el
procesador quántico), la criptografía tal como la conocemos hoy se habrá
terminado.
Consultadas muchas referencias nos queda claro que no hay
nada mejor que PGP para tener servicios de criptografía fuerte, la única
cuestión es qué versión elegir.
PGP fue escrito por Philip Zimmerman en 1991, quien lo
divulgó en forma libre, lo que le valió 3 años de investigación criminal por
violar las leyes del imperio USA que afectan a la exportación de software
criptografico fuerte fuera de sus fronteras. Esa versión primera usaba claves
RSA con un tamaño máximo de 512 bits. Lo que pasó a partir de entonces está
bien explicado aquí: http://www.ugr.es/~aquiran/cripto/informes/info007.htm
y las diferencias entre las primeras versiones (las que dieron la forma actual
al programa) se comentan en: http://www.rjmarq.org/pgp/pgpverses.html
pero ahora, con la nueva versión 8.0.3 parece que toda esa historia quiere
olvidarse como si nada hubiese pasado, pasando así por encima de las cosas más
prometedoras que han habido en todo el proceso. Recomendamos consultar las
referencias citadas, pero en síntesis lo que nos afecta es esto:
El sistema RSA tiene dos formatos de clave en PGP: el
antiguo, llamado "RSA versión 3" o "RSA Legacy", y el
moderno, llamado hoy día simplemente "RSA" o "RSA v4". La
diferencia fundamental entre ellos es que la versión 4 permite el uso de claves
ACK, esta clave es una puerta trasera, está pensada para grandes compañías,
permite que la empresa pueda descifrar mensajes cifrados por un empleado que
por lo que sea no esté para hacerlo personalmente con su clave privada, es
decir, soluciona el: "¿y ahora que hacemos?" ante un mensaje que no
tenemos forma de descifrar por no tener la clave privada necesaria (si esto no
pudiese solucionarse, esos datos se han perdido). En relación con estas claves
ACK se produjo el mayor fallo de seguridad en la historia de PGP (documentado
aquí: http://www.ugr.es/~aquiran/cripto/informes/info024.htm)
porque su diseño poco cuidadoso incluyó una vulnerabilidad que teóricamente
está superada a partir de la versión 6.5.8 de PGP.
Para nuestro propósito no sólo no necesitamos claves ACK
sino que nos viene de maravilla que exista un formato antiguo de clave RSA que
no permite tales claves, así que elegimos el "RSA Legacy" para
nuestra firma digital.
Se verá más adelante que una clave RSA es tanto más segura
cuanto más larga porque para romper la clave por un ataque de fuerza bruta
(probar todas las posibilidades) hay que factorizar un enorme número producto
de dos primos, única manera de romper el sistema, y que es tanto más penosa
cuanto más largo sea el número o clave ¿pero cómo de larga la necesitamos
nosotros? Pues por ejemplo, la mayor clave RSA factorizada hasta ahora que se
sepa, es el RSA-160, un número concreto de 160 cifras decimales (se consiguió
el 1 de Abril del 2003), previamente se había conseguido factorizar el RSA-155
el 22 de Agosto de 1999 después de 7.4 meses, y para hacerlo se necesitó de
todo un despliegue de medios (ver informe en http://www.rsasecurity.com/rsalabs/challenges/factoring/rsa155.html).
Con los mismos ordenadores dispuestos para la faena, el RSA-140 cayó en sólo 9
semanas.
Todos estos números son claves públicas del sistema RSA
(las que usualmente cifran), claves que pueden ser factorizadas para obtener
fácilmente la clave privada una vez conseguido esto, (las claves son inversas
entre sí: lo que se cifró con una, se puede descifrar con la otra).
El número RSA-155 corresponde al producto de dos números
primos usados para generar un par de claves RSA de 512 bits (en concreto es la
clave pública del par, ya que esta es sencillamente el producto de los dos
números primos).
El número RSA-160 es una clave pública de 530 bits.
Todos estos son números verdaderamente grandes. Para
hacernos una idea veamos al más grande que ha caído hasta la fecha, el RSA-160
(todos los números van partidos en filas de 50 dígitos como máximo y están
expresados en el sistema de numeración decimal):
RSA-160 =
21527411027188897018960152013128254292577735888456
75980170497676778133145218859135673011059773491059
60249790711158521430207931466520284014061994699492
7570407753
Estos son los dos números primos de 30 dígitos que
multiplicados entr sí dan al anterior:
p=
45427892858481394071686190649738831656137145778469
793250959984709250004157335359
q=
47388090603832016196633832303788951973268922921040
957944741354648812028493909367
Pero ¿sólo conociendo los factores primos se averigua la
clave? Sí, porque una clave es la inversa matemática de la otra y la aritmética
modular garantiza por construcción que el inverso es único (esto se entenderá
al analizar el propio sistema RSA).
Entonces la clave cuanto más larga mejor. Las versiones
"oficiales" de PGP no permiten longitudes de clave mayores de 4096
bits, pero afortunadamente Imad R. Faiad (http://ipgpp.veniece.com/)
ya se ha preocupado antes que el que esto escribe por solventar ese y otros
problemas que cualquier paranoico obsesibo-convulsivo quisiera ver resueltos a
medida que aumentan sus nociones sobre criptografía. Su mejor modificación de
PGP (la versión 6.5.8 CKT build 8) permite claves RSA de hasta 16384 bits (no
pueden ser mayores con garantías porque usa para generar los números primos una
librería precompilada de intel que tiene buenas características pero que está
limitada a esa longitud, y dicho sea de paso: nos preocupa que esa librería se
halla construido con la perversa intención de poder luego adivinar las claves,
esto no se puede comprobar porque no disponemos del código fuente, pero vamos a
darle un voto de confianza a Imad R. Faiad que fue quien introdujo esa
modificación, en teoría, se trata de unas funciones de creación de números
aleatorios muy selectas que están precompiladas porque intel® no desea revelar
sus secretos, el tiempo dirá si esos números son mejores o peores que los
pseudo-aleatorios generados por otros procedimientos, pero por lo menos al usar
esa librería podemos generar las calves enormes que deseamos). Esta versión del
programa fue modificada a partir del código oficial de la 6.5.8 publicado en
1997 por Network Associates Inc. Tanto el código original como el modificado lo
facilitamos también desde la página con instrucciones de cómo compilarlo.
Suponiendo que dentro de por ejemplo 1000 años todavía exista la criptografía
basada en el PFE o PLD, alguien con conocimientos de informática puede
desentrañar de ese código las líneas que necesita para hacer un programa
moderno que entienda las firmas hechas ahora de manera no estandar por
nosotros, y hoy cualquiera puede instalarse esta versión de PGP ya compilada
para usarla (la 6.5.8 CKT tiene subversiones (Build), recomendamos build 8 para
todas las versiones de Windows excepto XP, ese necesita la build 9 beta 3).
Ya tenemos una clave exageradamente grande que nos deja
tranquilos por lo que al capítulo de la longitud de clave se refiere. Muchos
criptógrafos afirman que el uso de ese tipo de claves enormes es absurdo, y que
denota gran ignorancia en materia de criptografía, tienen razón porque el
sistema completo tiene otros puntos vulnerables además de la clave, pero
pensando en que la capacidad de cómputo aumente mucho más deprisa de lo que se
espera y que las otras vulnerabilidades puedan irse solucionando, no perdemos
nada en usar una de estas claves enormes para nuestro propósito ya que una vez
creada y usada, la clave nos identifica y es única por lo que sería una pena tener
que cambiarla más tarde.
Bueno, lo que queremos no es cifrar, sino firmar digitalmente los documentos, porque eso permite tanto saber que son de quien dicen ser como verificar si se han modificado después de firmarse. Eso último es lo mejor de todo, y depende de una función llamada Hash (resumen), lo que hace una función Hash es calcular una ristra de ceros y unos que depende de todo el documento digital, una huella que al menor cambio en el documento cambia también si es recalculada. Básicamente la función hash parte de un bloque conocido de ceros y unos, y divide el documento que va a resumir en tantos bloques igual de grandes que el de partida como sea necesario, luego hace operaciones lógicas a nivel de bits entre el bloque de partida y el primero del documento, el resultado lo opera con el segundo, y así sucesivamente. Al final queda algo que depende de todo el documento (teóricamente si cambiase un solo bit del documento original, cambiarían al menos la mitad de los valores resultado del hash). La firma consiste en cifrar esa huella prácticamente única con la clave privada RSA del firmante, luego el que quiera comprobar la firma puede descifrar con la clave pública correspondiente la huella, y compararla con la que obtiene al calcularla por el programa que verifica la firma a partir del documento, si son iguales la firma se considera válida. Hoy en día hay un estándar para la firma digital (claves del tipo DSS y función Hash SHA-1), pero como tenemos el código fuente, no vamos a ceñirnos al estándar sino a usar la firma más segura que sea posible usar.
Ya se ve que la función Hash va a ser muy importante para
nuestro propósito. De las posibles funciones Hash, las principales opciones son
estas:
MD5 (Message Digest versión 5):
desarrollada por Ron Rivest en 1992. Es el estándar de hecho actual. Mejora a
los anteriores MD4 y MD2 (1990), es más lento pero con mayor nivel de
seguridad. Su salida o resumen es de 128 bits. Aún seguirá mucho tiempo siendo
una función muy usada porque es rápida y en muchas aplicaciones no importa
tanto la seguridad como la rapidez, pero está comprometida desde 1996 porque
existe un ataque ideado por Hans Dobbertin que puede provocar colisiones
(salidas iguales de esta función para mensajes diferentes), lo que abre la
puerta a la posibilidad de falsificar firmas (que se sepa aún no se ha
logrado). No obstante, aunque eso no basta para calificarlo como un algoritmo
débil, hay otros que no tienen esa vulnerabilidad.
SHA-1 (Secure Hash Algorithm): pasó a
propiedad del NIST (National Institute of Standards and Technology) una vez
estandarizada la firma digital en 1994, pero fue desarrollada por la espantosa
NSA (la National Security Agency que se dedica a pasar por encima de todas las
libertades en nombre de la sacrosanta seguridad nacional: pincha los teléfonos,
trató de impedir que PGP existienes, y otras lindezas), la primera versión de
este algoritmo hash se llamaba SHA, pero la propia NSA la declaró vulnerable a
un ataque que nunca dió a conocer, en respuesta al mismo planteó la SHA-1.
Funciona de modo muy similar a MD5 pero con resumen de 160 bits y se considera
en general como una función hash extremadamente bien diseñada. Existen
versiones del mismo algoritmo que aumentan el tamaño del resumen de salida:
SHA-256 y SHA-512. Esto interesaba porque ya descartadas teóricamente las
debilidades en el diseño, la única vulnerabilidad previsible a largo plazo es
que 160 bits resulten poco tamaño para algunas
aplicaciones.
La alternativa europea es RIPEMD-160 (RIPE Message
Digest). Fue desarrollada en 1992 por un grupo encabezado por Hans
Dobbertin, Antoon Bosselaers y Bart Preneel, dentro del proyecto RIPE (RACE
Integrity Primitives Evaluation), en respuesta a la debilidad de MD5 ya
comentada que fue probada en 1996 precisamente por Hans Dobbertin (el mismo que
previamente había reventado MD4 (ideó un ataque que permite generar colisiones
(mensajes aleatorios con los mismos valores de salida al hacer el hash) en
cuestión de minutos para cualquier PC, por ese motivo MD4 está en desuso). El
resumen o revoltillo de salida es de 160 bits (la versión primera (RIPEMD)
causaba colisiones del mismo tipo de las de MD4 y MD5, posteriormente se
reforzó y se llamó RIPEMD-160). Al igual que SHA-1, RIPEMD-160 crea un
revoltillo de 160 bits. Existe una versión de 128 bits, y se planean versiones
de 256 y 320 bits. Es uno de los algoritmos hash más rápidos, no está patentado
y su código fuente es de libre acceso. Por el momento, se le considera seguro.
La función Hash usada por RSA en PGP es MD5, que ya no se
recomienda pero que se implementa por compatibilidad con firmas
"antiguas" RSA (las versiones modernas de PGP fomentan el uso de
claves DH/DSS (Diffie-Hellman para cifrado, Digital Signature Standard para
firmado) principalmente por seguir el estándar recien creado y porque hasta
hace poco RSA estaba bajo patente de la empresa RSA Security Inc. (tanto la
empresa como el criptosistema asimétrico RSA deben su nombre a las iniciales de
los que inventaron este sistema en 1977 y fundaron más tarde la empresa: Ronald
Rivest, Adi Shamir
y Leonard Adleman, esta empresa ha
explotado la patente hasta el pasado 20 de septiembre de 2000, desde entonces
el criptosistema RSA es de dominio público), de ahí el motivo verdadero por el
que en su día empezó a no recomendase el uso de claves RSA en PGP cuando el
programa pasó a ser un producto comercial (esto fue en torno a 1995, existía un
criptosistema equivalente libre de patentes: Diffie-Hellman, la discusión de la
conveniencia de un sistema u otro está en http://webs.ono.com/usr005/jsuarez/pgpdhrsa.htm).
Después de todo lo expuesto parece ser que SHA-512 es
nuestra mejor opción, porque parece la más sólida a largo plazo. A pesar de que
SHA es un invento de la Agencia de Seguridad Nacional Estadounidense (NSA), no
hay razón para desconfiar de ella por eso, porque al gobierno USA, aunque sí le
interesa poder espiar los mensajes encriptados, no le interesa por el contrario
que se puedan falsificar firmas. MD5 tiene además de esa demostrada debilidad
una limitación rebuscada pero real: tiene un tamaño máximo de mensaje firmable
de 264 bits (18.446.744.073.709.551.616 bits), en cambio SHA-1 o
SHA-512 no tienen ese tipo de limitación, además el "revuelto" de MD5
es de 128 bits, lo que significan 2128 posibles resultados
(3,4028236692093846346337460743177 × 1038), y SHA-512 tiene cono su
mombre indica 2512 posibles resultados: eso empequeñece la
posibilidad de que dos documentos distintos den la misma salida.
SHA-512 puede usarse con RSA precisamente gracias a la
versión 6.5.8 CKT build 8 de PGP, que permite usar cualquier función hash
disponible con cualquiera de los criptosistemas que soporta (entrando en Edit
> Options... > Advanced > Preferred Hashing Algorithm, y seleccionado
la función que preferimos para el tipo de clave que se precisa antes de generar
esta, una vez generada la clave queda marcado en ella que usa ese algoritmo
para la firma y los demás usuarios de PGP 6.5.8 CKT pueden verificar firmas sin
preocuparse de eso porque el programa ya sabe que función Hash ha usado esa
clave para firmar). Así que la "debilidad" de MD5 nos la podemos
ahorrar y usar nuestro criptosistema favorito con SHA-512: con eso ya tenemos
la posibilidad de usar una firma verdaderamente fuerte.
Puede que si uno ya tiene asimilados estos conceptos
piense que si queremos una firma tan fuerte, lo mejor es encriptar con la clave
privada todo el contenido del documento en vez del resumen o hash de 512 bits
que da como salida el SHA-512, eso supondría duplicar el espacio necesario para
distribuir los documentos con sus firmas pero sería más seguro y el espacio no
es un problema hoy día. A esto hemos de contestar que sin una función Hash,
verificar la firma llevaría demasiado tiempo porque requeriría desencriptar
todo un documento en vez de 512 bits, y eso haría la firma totalmente inútil ya
que en la práctica necesitaremos verificar la firma sobre todo para protegernos
de nosotros mismos y nuestros compañeros (la historia nos demuestra que serán
los propios gnósticos los que quieran modificar los libros, antes que un
siniestro atacante externo). El buen trabajo que hacen las funciones hash es
muy necesario, de hecho MD5 sería más que suficiente para detectar cambios en
el documento, lo que la hace insegura es una posibilidad teórica –que no
práctica– de que en el futuro podría ser modificado el documento sin que lo
detecte la firma (en el supuesto de un ataque intencionado para lograrlo).
Además SHA-512 esta fuera de sospecha porque su código fuente es abierto, más
sospechosa sería en todo caso la librería de generación de números aleatorios
de intel, pues es conocido que determinadas sucesiones realimentadas como las
que genera la ecuación logística, pueden dar números aparentemente aleatorios
que no son tales. Hasta yo puedo hacer eso, y si hemos decidido confiar en un
generador de números aleatorios que no podemos verificar, es porque aceptamos
implícitamente que toda seguridad de este mundo es vana. Sencillamente, estamos
haciendo esto porque es práctico para detectar errores, y cabría incluso la
posibilidad de que realmente sea seguro.
Bien, teniendo en cuenta todas las explicaciones
referenciadas o planteadas líneas arriba y hecha la experiencia de trastear el
código fuente tanto de la versión recomendada como de varias otras, luego de
pasar por todas las dudas razonables que planteadas en resumen son:
"¿puede uno estar seguro de que algún sistema de criptografía es
seguro?", cuestión inevitable que todos hemos de respondernos de un modo u
otro, resolvemos que vale la pena tratar de proteger los libros con estas
firmas, ya que el aspirante que no ha cruzado el umbral del misterio necesitará
de una seguridad razonable inicialmente.
Comprender el principio del RSA es fácil: se basa en el
hecho matemático de la dificultad de factorizar números muy grandes, (a esto se
le llama: "problema de la factorización de enteros" (PFE)). Para
factorizar un número (expresarlo en sus factores primos) el sistema más lógico
consiste en empezar a dividir sucesivamente éste entre todos los números primos
naturales menores que él en orden creciente, entre 2, entre 3, entre 5, entre
7..., y así sucesivamente, buscando que el resultado de la división sea exacto,
es decir, de resto 0, con lo que ya tendremos un divisor del número.
Ahora bien, si el número considerado es un número primo
(el que sólo es divisible por 1 y por él mismo), tendremos que para
factorizarlo habría que empezar por 2, 3, 5, 7... hasta
llegar a él mismo, ya que por ser primo ninguno de los números anteriores es
divisor suyo. Y si el número primo es lo suficientemente grande, el proceso de
factorización es en la práctica imposible, en eso se basa la seguridad de RSA.
Otra cosa es poder verificar una implementación real del sistema como PGP: eso
es considerablemente difícil. Para empezar el código fuente de PGP está escrito en C puro y duro como la inmensa mayoría de los
programas para Windows de principios de los 90. Implementa algoritmos de
multiprecisión (aritmética de números muy grandes) y usa formatos complicados
que no vienen documentados y es preciso conocer para poder analizar a cabalidad
que el programa hace lo que se supone que hace.
De todas maneras el que esto escribe lo ha trasteado un
poco y ha quedado convencido de la bondad del código: las partes básicas del
programa compilan sin mayor dificultad que incluir la librería precompilada de
intel que genera los números aleatorios en el archivo de proyecto que la
precisa. Quien quiera hacer la experiencia puede hacerla sin más que seguir
estas sencillas instrucciones:
Para poder hacer esta experiencia necesitamos tener e
instalar el compilador C++ de Visual Studio 6.0, y a poder ser los SDK y DDK
que podamos conseguir, pero esto último no será imprescindible para compilar
sólo el núcleo funcional del programa (los programas para generar y administrar
claves, firmar, encriptar y desencriptar). Hagamos esto sin más como preámbulo,
en caso de que no funcione, dentro de los fuentes de la 6.5.8 original hay un
archivo .pdf con las instrucciones ampliadas.
Recreamos el código fuente completo de CKT descomprimiendo
los fuentes modificados de 6.5.8CKT sobre los de la versión oficial 6.5.8,
debemos sobrescribir los archivos originales con sus homónimos modificados (los
dos paquetes vienen organizados en un árbol de directorios, se trata
simplemente de copiar uno sobre otro).
Abrimos en el Visual C++ el archivo de proyecto principal:
...\clients\pgp\Win32\PGPclient.dsw (los puntos suspensivos hay que
sustituirlos por el principio de la ruta, ya que sólo se especifica la ruta en
los directorios interiores del código fuente).
Una vez abierto, antes que nada, poner el visor de
proyecto de VC++ en FileView para que al hacer clic con el derecho sobre
un proyecto, nos aparezca un menú contextual que de la posibilidad de insertar
un archivo en el proyecto. Haremos eso sobre: PGPcdk files. Elegiremos Add
Files to Project y le daremos la ruta de la librería precompilada de Intel
al cuadro de diálogo que se abre:
...\libs\pgpcdk\priv\external\win32\IntelRNG\lib\sec32ipi.lib
Una vez añadido podemos hacer un Bach Build para
crear todos los Release y Release Auth Only. Eso construirá todos
los archivos del paquete básico del programa (seleccionar y pulsar: Rebuild
All). Los ejecutables construidos se quedan en la ruta:
...\clients\pgp\win32\PGPclient\Release
Dentro de esa ruta podemos abrir el PGPKeys.exe
pero se quejará de que no encuentra el fichero nosequé. Aceptamos y salimos,
entretanto se ha creado un nuevo fichero llamado PGPClient.dat,
seguidamente vamos a solucionar esto, abrimos el PGPadmin.exe y sencillamente
una vez abierto le damos a cancelar. Parece de tontos eso pero al hacerlo se
crea un fichero llamado PGPadmin.dat, y precisamente ese es el fichero
que pedía el PGPKeys.exe, al volverlo a abrir ahora funciona, (se queja de que
no tiene el driver de memoria, uno que sirve para que las claves en memoria no
puedan ser leídas por otros programas, pero da posibilidad de continuar sin
él), se comprueba que ahora podemos crear y administrar llaves. Todas las
funciones de firmado y encriptado están presentes.
Podemos ahora abrir el PGPtools.exe y firmar un
fichero con la clave que hemos creado.
También exportar la firma usada para luego importarla
desde otra versión de PGP (aunque una firma enorme como la que usa esta página
no funcionará en otras versiones).
Hubiese estado bien poder verificar las operaciones de
cifrado pero eso se nos ha resistido y nos hemos dado por contentos con esto.
Después de todo, el programa funciona y es cómodo, para meternos más a fondo en
sus entresijos necesitamos mayor documentación del código o muchas ganas de
perder el corto tiempo que dura la existencia humana, y eso no nos lo podemos
permitir. Sabiendo que tenemos el código funcional y que construye una
aplicación similar a nivel de bits a la que se instala precompilada, la
ausencia de denuncias de agujeros es tranquilizadora. Además la manera en que
Imad a modificado el código también es tranquilizadora (puso comentarios en todo
lo que modificó). A partir de este código fuente es posible crear una versión
simplificada del programa que pueda usarse en plataformas futuras, aunque dudo
que sea necesario tanto porque Faiad sigue manteniendo el código y hay muchos
entusiastas de esta versión. En todo caso todo eso es posible y si ha de
hacerse se hará, no estamos tan tirados como pudiese pensarse al hacer algo tan
rebuscado para "unas simples firmas digitales". El tiempo dirá si
hemos perdido el tiempo o tiene algún sentido lo intentado ahora.
Esta versión 6.5.8 CKT viene a ser libertad total de
elección y oferta en un sólo programa de todas las posibilidades de la
criptografía actual para aumentar la seguridad que ofrece el PGP original.
En cambio la versiones oficiales
tratan de imponer una solución intermedia, son en ese sentido no sólo menos
románticas, sino poco sensibles al entusiasmo que genera el programa PGP al
empezar a entenderlo y usarlo.
Solamente con esta versión nos podemos plantear qué
algoritmos queremos usar, en las demás esas decisiones ya han sido tomadas por
nosotros. Ya que es posible, preferimos elegir por nosotros mismos.
Consideramos que ha habido evolución del programa PGP
hasta la versión 6.5.8 CKT, y que ahora francamente está involucionando, así
que nos quedamos con esta versión.
Con esto queda en la medida de lo posible expuesto el
grado de confianza que nos merece toda esta cuestión y el sentido que tiene
firmar digitalmente el contenido de la página. Esperamos que nuestra firma
resista la prueba del tiempo.