ÚLTIMA ACTUALIZACIÓN DE ESTA PÁGINA: 6 DE FEBRERO DE 2016

 Firmas PGP:
Descarga desde aquí la Firma PGP del sitio y todo lo que necesitas para verificarla

En pocas palabras:

Todos los libros en teoría libres de errores o revisados exhaustivamente (fecha de primera edición en color rojo) 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 por qué de elegir esta versión).

Todo lo que se necesita está comprimido en un solo archivo. Para saber cómo instalar y configurar el PGP te recomendamos leer el manual que encontrarás en él. Si PGP sólo te interesa para comprobar nuestras firmas, no tienes más que:

1.      Bajar el zip con todo lo necesario. Una vez instalado el programa se verá un candado en la barra de tareas.

2.      Dentro hay un archivo .asc que es nuestra firma, para agregarla busca en el menú P G P de la lista de programas de Windows y 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 .asc (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 necesitas bajarla del enlace correspondiente al libro que encontrarás aquí. Una vez bajado el archivo de firma (.sig) y puesto en el mismo directorio del .odt 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:

La garantía de seguridad que ofrece el contenido de este sitio:

Lo primero será especificar que necesidad tenemos de seguridad: Deseamos que cualquiera pueda verificar que un libro publicado en esta web 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:

  1. El maestro Samael escribe sus libros en castellano, la misma lengua materna que los autores Augusta y Francisco (Augusta incluso es Colombiana como él).

  2. Las primeras ediciones son publicadas por Julio Medina Vizcaíno, que era quien tenía el dinero para hacerlo en los primeros tiempos del movimiento.

  3. Augusta obtiene muchas de estas primeras ediciones porque antes incluso de ser estudiante gnóstica era familia política de Julio Media V.

  4. Augusta y el que esto escribe, decidimos montar la página www.gnosis2002.com para de paso que nosotros mismos nos estudiamos la obra original del maestro y nos preocupamos de ver si hay diferencia substancial con las ediciones que se están publicando actualmente (principios del siglo XXI), dejarla disponible para todos. Y sin prisa alguna, poco a poco, vamos puliendo pacientemente todos los errores que comporta una tarea como esta.

  5. Una vez estamos seguros de haber corregido todos los errores, o al menos satisfechos del trabajo de revisión realizado, firmamos digitalmente los archivos. Mediante el sistema de firmas cualquiera que venga a obtener en el futuro estos libros y grabaciones en audio, puede estar razonablemente seguro de que le llegan tal y como nosotros los dejamos.

Hay dos cuestiones: Una la confianza que se tenga en nuestra mediación. Diré sólo esto en nuestra defensa:

  1. Nunca hemos comerciado con esta recopilación, y si alguno lo ha hecho, de nosotros la obtuvo gratis. Todo el trabajo lo hemos dado siempre gratis a través de la Web (vamos: que por dinero está claro que no lo hacemos).

  2. Al que esto escribe particularmente, lo que le interesaba era conocer las versiones originales, poder estar seguro de que la enseñanza de Samael como era en su origen, y estudiar a partir de ahí. Y además conocer toda la obra del maestro, ya que sólo conocía una pequeña parte.

  3. A mi compañera, le anima el poder tener una ocasión clara de servicio a la humanidad en el sentido de colaboración con el experimento solar.

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 que 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 puede 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.890m.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 politécnica 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 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), pero actualmente se ha desarmado a la gente pobre de sistemas de criptografía limitando las capacidades de los programas criotográficos comunes por medio de las leyes y de ofrecer malas soluciones con mejor presencia que las buenas.

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. 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 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 claves 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 que el imperio permite a sus esclavos 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, ampliamente usado en las plataformas GNU.

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. Más aún: la fortaleza de la criptografía que ofrece esta versión está incluso perseguida porque documentos cifrados con ella pueden quedar fuera del alcance de los poderosos y algunos han pagado con cárcel que esa posibilidad vea la luz mientras otros se esfuerzan en que deje de verlas, 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.

Francisco Caparrós Pujalte, autor de gnosis2002

Página principal