``GNU Privacy Guard'' (GnuPG) Mini Como <author>Michael Fischard v. Mollard <htmlurl url="mailto:fischer@math.uni-goettingen.de" name="fischer@math.uni-goettingen.de"> (versión alemana) &nl; Brenno J.S.A.A.F. de Winter <htmlurl url="mailto:brenno@dewinter.com" name="brenno@dewinter.com"> (versión inglesa) &nl; Horacio <htmlurl url="mailto:homega@ciberia.es" name="homega@ciberia.es"> (versión castellana) <date>v0.1.3, septiembre de 1999 <abstract> Este documento trata sobre la instalación, configuración y uso de <tt/Gnu Privacy Guard/ (<tt/GnuPG/), un sistema de codificación de código libre y desarrollo abierto, compatible con <tt/OpenPGP/. Con el fin de mantener este programa totalmente libre, se ha evitado el uso de algoritmos con patentes propietarias restrictivas, como las de IDEA y RSA. El documento original fue escrito en alemán por Michael Fischard v. Mollard, y posteriormente traducido, y revisado en algunos puntos, al inglés por Brenno J.S.A.A.F. de Winter. La traducción de este documento al castellano se ha llevado a cabo a partir de la versión inglesa. El capítulo 5 se ha añadido en la versión en castellano, y también se han incluido algunos recursos y otra información en castellano. Ésta es una revisión de la versión 0.1.2, y no incluye ninguna temática nueva, tan sólo su conversión de código HTML a código SGML para su posterior reconversión a otros formatos. También se han corregido algunos errores de forma o traducción. </abstract> <toc> <sect>Conceptos básicos <label id="GPGMiniComo-Conceptos"> <p> <sect1>Sistemas de claves públicas <p> Para poder entender mejor el sistema de codificación usado por los sistemas de <it/claves asimétricas/ (es decir, claves públicas y privadas), es necesario entender las diferencias con los sistemas de <it/claves simétricas/ (es decir, claves secretas). Los sistemas de cifrado con <em/clave simétrica/ son aquellos en los que la clave que se usa para cifrar una serie de datos es la misma que la que se usará para descifrar estos datos. En el caso del correo electrónico, el remitente cifraría el mensaje con una <em/clave secreta/, y para que el destinatario pueda descifrarlo, necesitaría haber obtenido previamente esta misma clave de un modo «seguro», o sea de modo que la clave no haya podido ser interceptada durante la entrega. Si no tenemos la completa seguridad de que el intercambio de la clave ha sido seguro, la validez de este sistema es nula. Por el contrario, los sistemas de cifrado con <em/claves asimétricas/ usan claves distintas para el cifrado y posterior descifrado de los datos. En un caso como el anterior, el remitente usaría la <em/clave pública/ del destinatario para cifrar el mensaje, y el destinatario descifraría el mensaje con su propia <em/clave privada/. Así pues, la <em/clave privada/ no debe ser accesible para <bf/nadie/ que no sea el propio dueño de la misma, mientras que la <em/clave pública/, puede ser entregada a cualquier persona. En un sistema de cifrado bien implementado, la <em/clave privada/ no debe derivar nunca de la <em/clave pública/. <sect1>Firmas digitales <p> El concepto de la <bf/firma digital/ se basa en la verificación de la autoría de un mensaje. Esto quiere decir que se puede comprobar que el destinatario del mensaje puede comprobar que el «supuesto» remitente es quien afirma ser. Para ello, el remitente, una vez compuesto el mensaje, lo firma usando su propia clave privada. El destinatario, una vez ha recibido el mensaje, comprobará la veracidad de éste, esto es, lo verificará usando la clave pública del remitente. Este método es de especial utilidad para reducir riesgos de seguridad en nuestros sistemas (nos podrían enviar un supuesto parche para un programa, y éste en realidad ser un virus o un troyano); también podrían enviarnos información o datos, como provenientes de una fuente lícita o fiable. En ambos casos, no sería muy difícil falsificar la dirección y nombre del remitente, pero sí imposible falsificar la firma digital de éste. Como ya hemos dicho, la verificación de un mensaje firmado digitalmente se lleva a cabo mediante el uso de la <bf/clave pública/ del remitente <bf/sobre el texto/ del propio mensaje. De este modo no sólo podemos verificar la identidad del autor, sino que también podemos comprobar la integridad del mensaje, ya que la firma digital ha sido generada con el <bf/texto/ y la <bf/clave privada/. Así pues, una alteración o modificación del texto «a posteriori», o cualquier manipulación del mensaje (especialmente si hacemos uso de las especificaciones MIME/PGP), daría como resultado un error en la verificación. <sect1>Anillos de confianza <p> Un punto flaco en los algoritmos de clave asimétrica es la transmisión del código público. Es posible que una persona ponga en circulación código con un identificador de usuario falso. Si se codifican mensajes con este pseudo código, el intruso los puede descodificar y leerlos. La solución <tt/PGP/ (y por consiguiente la solución <tt/GnuPG/) está en firmar los códigos. La clave pública de un usuario puede estar <bf/firmada/ con las claves de otros usuarios. El objetivo de estas firmas es el de reconocer que el UID (identificador de usuario) de la clave pertenece al usuario a quien dice pertenecer. A partir de ahí es un problema de cada usuario de <tt/GnuPG/ el decidir hasta qué punto se puede fiar de la firma. Una clave se puede considerar fiable cuando se confía en el remitente y cuando se sabe con seguridad que dicha clave pertenece a éste. Sólo cuando se puede confiar plenamente en la clave del firmante, se puede confiar en la firma que acompaña a la clave de un tercero. Para tener la certeza de que la clave es correcta hay que compararla con la <bf/huella digital/ por medio de canales fiables (por ejemplo, podríamos buscar el teléfono en la guía y llamarle, y que nos la dijera de palabra para poder compararla), antes de darle una confianza absoluta. <sect1>Límites de seguridad <p> Si lo que se desea es mantener la confidencialidad de los datos que se poseen, no basta con determinar qué algoritmo de cifrado se va a usar; también es necesario pensar en la seguridad general del sistema. En principio, <tt/PGP/ está considerado como suficientemente seguro, y hasta el momento no se sabe que haya habido ningún incidente en el que una clave PGP haya sido descodificada. Pero eso no significa que todo lo cifrado sea seguro; si la NSA (Agencia de Seguridad Nacional de los EE.UU.) hubiera conseguido descodificar una clave PGP mediante criptoanálisis, análisis del código, o cualquier otro modo, no es probable que lo hicieran público. Pero aún en el caso de que las claves PGP fueran a todas luces imposibles de descodificar, pueden ser utilizados otros tipos de ataques a la seguridad. A principios de Febrero fue detectado un troyano que buscaba las claves PGP en el disco duro, y las transfería al atacante mediante FTP. Si en este caso hubiéramos escogido una contraseña débil o fácil, un simple análisis que consistiera en un «ataque de diccionario» la descubriría en poco tiempo. Otra posibilidad técnica, aunque más difícil, es la de los troyanos que recogen entradas de teclado y las transmiten al asaltante. También es posible, aunque muy difícil, pasar el contenido de una pantalla a otra. En este último caso no sería necesario ningún análisis sobre datos cifrados, ya que se obtendrían antes de su cifrado. Por todo esto es necesaria una planificación de la seguridad que esté bien prevista y que minimice los riesgos. La idea no es la de recrear una atmósfera de paranoia entre la gente, sino dejar claro que para implementar un sistema seguro no basta con la instalación de un programa criptográfico, que si bien es un paso hacia un sistema más seguro, no es una solución completa. Troyanos como el aparecido en Marzo de 1999 (Melissa) probaron que muchas compañías no se encuentran preparadas en temas de seguridad. <sect>Instalación y configuración <p> <sect1>Código fuente de GnuPG <p> El sitio oficial para para la distribución de <tt/GnuPG/ es el sitio oficial de GnuPG, <htmlurl url="ftp://ftp.guug.de/pub/gcrypt/gnupg/" name="ftp://ftp.guug.de/pub/gcrypt/gnupg/">. En las páginas oficiales de GnuPG, <htmlurl url="http://www.gnupg.org/download.html" name="http://www.gnupg.org/download.html"> también se pueden encontrar enlaces a réplicas oficiales. Debido a restricciones legales no se permite bajar material criptográfico desde servidores localizados en los EE.UU., a los no residentes en este país. En EE.UU. existen unas leyes que imponen restricciones a la exportación de código criptográfico así como de programas que los incluyan. Por esta razón PGP se encuentra siempre disponible en dos versiones: una internacional y otra para los EE.UU. El código fuente para la versión internacional fue exportado en formato ascii imprimido en un libro. A continuación fue escaneado en Europa (Oslo) y recompuesto. Se puede obtener más información al respecto en la página internacional de PGP, <htmlurl url="http://www.pgpi.com/" name="http://www.pgpi.com/">. La versión internacional de PGP puede ser importada libremente a los EE.UU. siempre y cuando no se vuelva a reexportar fuera de éstos. Una vez se ha instalado una versión de <tt/GnuPG/ o <tt/PGP/, se debería verificar la firma digital que acompaña al fichero (Ver <ref id="fyv" name="Firmar y Verificar">). <sect1>Configuración <p> GnuPG se puede obtener como un paquete de binarios de Debian, <htmlurl url="http://www.debian.org/" name="http://www.debian.org/"> (<tt/.deb/), como un paquete de binarios de RedHat, <htmlurl url="http://www.redhat.com/" name="http://www.redhat.com/"> (<tt/.rpm/), o en código fuente. Los paquetes son archivos comprimidos de los ficheros binarios que se pueden instalar con las correspondientes herramientas, según la distribución. Si se necesita instalar GnuPG en otros sistemas operativos, entonces lo debe compilar uno mismo a partir de los fuentes. Se agradece que quien compile un paquete de instalación para un sistema o arquitectura diferente, lo haga de dominio público. Dado que la mayoría del desarrollo de GnuPG tiene lugar en máquinas x86 bajo Linux (<htmlurl url="http://www.linux.org/" name="http://www.linux.org/">, la migración a un sistema diferente no debería ser ningún problema. La lista de sistemas operativos que están soportados por GnuPG se puede encontrar en las páginas de GnuPG (<htmlurl url="http://www.gnupg.org/" name="http://www.gnupg.org/">. El procedimiento que se describe a continuación no es exclusivo de ninguna plataforma. Este procedimiento se puede usar para compilar e instalar GnuPG partiendo de un archivo comprimido del código fuente (<tt/loquesea.tar.gz/). Descomprimir y desempaquetar el paquete del código fuente con la orden (si estamos usando GNU <tt/tar/): <tscreen><verb> $ tar zxvf gnupg-?.?.?.tar.gz </verb></tscreen> El siguiente paso es cambiar al directorio que contenga el código fuente, y ejecutar el guión de configuración: <tscreen><verb> $ ./configure </verb></tscreen> Con este paso no debería suceder nada especial; si ejecutamos <tscreen><verb> $ ./configure --help </verb></tscreen> se pueden ver las opciones de configuración que existen para la compilación. Si durante la internacionalización (GET text) ocurriera algún problema, se puede incluir una versión que venga con código fuente, usando la opción <tscreen><verb> --with-included-gettext </verb></tscreen> o desactivarla usando la opción <tscreen><verb> --disable-NLS </verb></tscreen> <sect1>Compilación <p> A continuación, para empezar a compilar ejecutaremos la orden de compilación: <tscreen><verb> $ make </verb></tscreen> Compilación que deberá finalizar sin problemas. Si ocurriera algo anormal, se seguirán los siguientes pasos (en el mismo orden en el que se describen aquí): Primero, intentar solucionarlo por uno mismo (haciendo uso de la documentación existente); segundo, asegurarnos de que no es un error conocido (comprobar el fichero <tt/BUGS/ en <htmlurl url="http://www.gnupg.org/" name="http://www.gnupg.org">. Si estos pasos no resuelven el problema, enviar la pregunta a la lista de correo de GnuPG (en inglés) (ver <ref id="font" name="Fuentes de Información">). Por si el problema estuviera relacionado con la compilación, se debería intentar <tt/make clean/, ejecutar <tt/configure/ de nuevo, e intentar otra vez la compilación. Si nada de esto soluciona el problema, es el momento de preocuparse de verdad. <sect1>Instalación <p> Suponiendo que hayamos compilado el programa sin problemas, el siguiente paso es instalarlo. Para ello ejecutaremos la orden de instalación: <tscreen><verb> $ make install </verb></tscreen> que copiará el programa y las páginas de manual en el directorio de instalación. Si no hemos cambiado el directorio de instalación cuando ejecutamos <tt>./configure</tt>, éste será <tt>/usr/local/share/gnupg/</tt> por defecto. Es posible encontrar este directorio en el fichero <tt/options.skel/. Cuando se cambie <tt/options.skel/, si se copia a <tt>~/.gnupg/options</tt>, se usarán los ajustes típicos. Al crear <tt>~/.gnupg/</tt> la acción copiar debería ser automática. Todas las opciones posibles están bien documentadas, y tratar de explicarlas aquí no sería de utilidad. Se puede ejecutar GnuPG como <it/suid/ root. De este modo el programa se ejecutará con todos los permisos que tiene el superusuario, y se excluye la posibilidad de que ciertas partes del programa se guarden externamente y puedan ser leídas por cualquiera. Sin entrar a valorar los riesgos de ejecutar el programa como superusuario, se debería alertar de los peligros que conllevaría un troyano, ya que éstos, si se está ejecutando como superusuario, pueden dañar todo el sistema. Si por esta razón, o por cualquier otra, se decide no ejecutar GnuPG como root, es posible desactivar el aviso activando <tt/no-secmem-warning/ en <tt>~/gnupg/options</tt>. <sect>Uso y gestión de las claves <p> <sect1>Generación de una clave <p> Con la orden <tscreen><verb> $ gpg --gen-key </verb></tscreen> se genera un nuevo par de claves (el par se compone de clave privada y clave pública). La primera pregunta es qué algoritmo se va a usar. Para más información sobre algoritmos, ver la lista de respuestas a Preguntas de Uso Frecuente (PUF, FAQ en inglés) sobre <it/PGP DH vs. RSA FAQ/ en <htmlurl url="http://www.hertreg.ac.uk/ss/pgpfaq.html" name="http://www.hertreg.ac.uk/ss/pgpfaq.html"> o <ref id="BSchneier" name="Applied Cryptography">. El algoritmo recomendado por GnuPG es DSA/ElGamal, ya que éste no está patentado. La siguiente pregunta es la longitud de la clave. Esta parte depende de los requerimientos del usuario. Es necesario elegir entre la seguridad y el tiempo de los procesos. Cuanto mayor sea una clave, menor será el riesgo de que el mensaje sea descodificado si es interceptado, pero también aumentará el tiempo que empleará para el cálculo de los procesos. El tamaño mínimo que requiere GnuPG es de 768 bits, aunque mucha gente opina que debería ser de 2048 (que es el máximo con GnuPG en este momento). Para DSA 1024 es un tamaño fijo. Cuando la seguridad es una prioridad más alta que el tiempo, la opción es elegir el tamaño de clave más grande que se permita. El sistema nos pedirá a continuación que se introduzca el nombre, comentario y dirección de correo electrónico. El código se calculará en base a estas entradas. Esto se puede cambiar más tarde (ver <ref id="admon" name="Administración de Claves">). La dirección de correo electrónico que se escoja debería ser una válida, ya que se usará para firmar el identificador de usuario. Si esta dirección se modifica en algún modo, la firma no corresponderá. Finalmente, se puede introducir un comentario. El último paso consiste en introducir una contraseña. Nótese la diferencia entre los términos anglosajones para la palabra «contraseña»: el término &dquot;password&dquot; indica una &dquot;palabra de paso&dquot;, mientras que el término &dquot;passphrase&dquot; indica una &dquot;frase de paso&dquot;. Por tanto esta contraseña se debe componer de más de una palabra. Para que una contraseña sea efectiva (segura), deberá cumplir los siguientes requisitos: <itemize> <item>que sea larga; <item>que combine mayúsculas, minúsculas y números; <item>que contenga caracteres especiales (no alfanuméricos); <item>que sea difícil de adivinar. Por lo tanto, que no sean nombres, fechas significativas, números de teléfono, números de documentos, ... </itemize> En general, para una contraseña fuerte es aconsejable intercalar maYúsCUlas con mInúsCulas, números, otros caracteres no alfanuméricos, etc. Al escoger las palabras y frases debemos evitar aquellas palabras demasiado obvias, o fechas significativas, y nunca usar citas de libros o frases famosas. Dicho esto, debemos asegurarnos de que la contraseña que elijamos sea lo suficientemente difícil para que no pueda ser traspasada por un «ataque de fuerza bruta», ni siquiera por un «ataque de diccionario», pero lo suficientemente fácil como para que la recordemos. Si olvidáramos una contraseña nuestra clave quedaría totalmente inutilizada, y los criptogramas con ella cifrados, indescifrables. Ante esta posibilidad se recomienda crear siempre certificados de revocación junto con las claves (ver <ref id="revoc" name="Certificados de Revocación">). Una vez se han introducido todos los datos requeridos, empieza el proceso de generación de las claves, que tardará un tiempo dependiendo del tamaño de éstas. Durante este proceso el programa recoge datos aleatorios que usará para generar las claves; un modo para ayudar a generar estos datos es cambiando a una consola virtual diferente y usando el teclado mientras el proceso está en marcha. <sect1>Exportación de claves <p> La orden para exportar la clave es: <tscreen><verb> $ gpg --export [UID] </verb></tscreen> Si no designamos un identificador de usuario (UID) todas las claves presentes en el anillo de claves serán exportadas. El resultado es enviado por defecto a <tt/stdout/, pero con la opción <tt/-o/ podemos especificar que sea enviado a un fichero. Se recomienda usar la opción <tt/-a/ para que el resultado sea un fichero de 7-bit ASCII en lugar de un fichero binario. Al exportar la clave pública se amplía el abanico de personas con las que se podrá comunicar de modo seguro. La clave se puede exportar poniéndola en una página <em/web/, mediante <em/finger/, <em/ftp/, haciéndola accesible en un servidor de claves públicas, o cualquier otro método. <sect1>Importación de claves <p> Cuando se recibe la clave pública de otra persona hay que añadirla a la base de datos (anillo de claves) para poder hacer uso de ella. La orden para importarlas es la siguiente: <tscreen><verb> $ gpg --import [fichero] </verb></tscreen> Si se omite el nombre del fichero se leerán los datos de <tt/stdin/. El fichero puede contener una sola clave o varias a la vez, pertenecientes a la misma o a diferentes personas. <sect1>Revocación de claves <label id="revoc"> <p> Existen diversos motivos por los que se pueda querer revocar una clave. Por ejemplo, si la clave secreta ha sido robada, o si se ha olvidado la contraseña de ésta. En cualquier caso la orden de revocación es: <tscreen><verb> $ gpg --gen-revoke </verb></tscreen> Esto creará un <bf/Certificado de revocación/. Para ello es necesaria la clave secreta, de lo contrario cualquiera podría hacer un certificado y revocar una clave que no le perteneciera. En el caso anterior en el que la contraseña ha sido olvidada, se hace imposible generar un certificado de revocación. Por este motivo es muy aconsejable generar un certificado de revocación a continuación de la generación de la clave. Es primordial guardar este certificado en un lugar seguro para que nadie pueda usarlo y revocar la clave. <sect1>Administración de claves <label id="admon"> <p> Existe un fichero que es una suerte de base de datos, en el que se guardan todos los datos relacionados con las claves, incluidos los valores relativos al grado de confianza (<em/Ownertrust/); para más información sobre esto véase <ref id="firmk" name="Firmar las claves">. Con la orden <tscreen><verb> $ gpg --list-keys </verb></tscreen> se muestran todas las claves existentes. Para poder ver también las firmas en cada clave, utilice la orden: <tscreen><verb> $ gpg --list-sigs </verb></tscreen> (ver <ref id="firmk" name="Firmar las claves"> para más información). Para ver las huellas digitales (<em/fingerprints/): <tscreen><verb> $ gpg --fingerprint </verb></tscreen> Las «huellas digitales» sirven para confirmar la identidad de la persona. Esta orden nos muestra una lista alfanumérica que podemos comprobar, por ejemplo, por teléfono, con la persona en cuestión. Para ver el listado de las claves secretas: <tscreen><verb> $ gpg --list-secret-keys </verb></tscreen> Nota: el listado de las huellas digitales y las firmas de las claves secretas no es de ninguna utilidad. Para eliminar una clave pública: <tscreen><verb> $ gpg --delete-key UID </verb></tscreen> Para eliminar una clave secreta: <tscreen><verb> $ gpg --delete-secret-key </verb></tscreen> Existe otra orden que es relevante para trabajar con las claves: <tscreen><verb> $ gpg --edit-key UID </verb></tscreen> Para esta orden necesitaremos la contraseña, y podemos, entre otras cosas, editar la fecha de caducidad, añadir una huella digital y firmar la clave. <sect1>Firma de las claves <label id="firmk"> <p> Como se ha mencionado anteriormente en la introducción, existe un talón de Aquiles en el sistema: la autentificación de las claves públicas. Si se obtiene una clave pública errónea, ya se puede despedir uno del valor del cifrado. Para evitar estos riesgos está la posibilidad de firmar las claves. Cuando tenemos la certeza de que una clave es válida y pertenece a quien dice, podemos firmarla digitalmente, de modo que otros que confíen en nuestra firma la puedan dar por válida. Usando la orden <tscreen><verb> $ gpg --edit-key UID </verb></tscreen> para la clave que queremos firmar, nos llevará a la suborden <tscreen><verb> Command> sign </verb></tscreen> <bf/¡Sólo se debe firmar una clave cuando se esté ABSOLUTAMENTE SEGURO de que dicha clave es auténtica!/ En realidad, sólo se puede estar totalmente seguro cuando la clave se ha recibido en mano, o por ejemplo si se ha recibido por correo y a continuación se han comprobado las huellas digitales por correo. Una clave no debe ser nunca firmada con base en una suposición. Basándose en las firmas existentes en una clave y en el «grado de confianza», <tt/GnuPG/ determina la validez de las claves. El grado de confianza (<em/Ownertrust/) es un valor que el propietario de una clave usa para determinar el nivel de confianza para una cierta clave. Estos valores son: <itemize> <item>1 = Don't know (No sé, no conozco) <item>2 = I do NOT trust (Confianza nula) <item>3 = I trust marginally (Confianza marginal) <item>4 = I trust fully (Confianza plena) </itemize> Si el usuario no se fía de una firma puede indicarlo así, y rechazar la confianza en ésta. La información sobre la confianza no se guarda en el mismo fichero que el de las claves, sino en otro diferente. <sect>Codificar y descodificar <p> Después de haber instalado y configurado todo tal y como queríamos, podemos comenzar a cifrar y descifrar datos. Es posible que cuando estemos cifrando o descifrando un documento, tengamos más de una clave privada en nuestro anillo de claves privadas. Si esto es así, es necesario seleccionar una de ellas como activa. Para ello se puede usar la opción <tscreen><verb> -u UID </verb></tscreen> o bien la opción <tscreen><verb> --local-user UID </verb></tscreen> También podemos agregar la siguiente línea en el fichero de configuración <tt>$HOME/.gnupg/options</tt>: <tscreen><verb> default-key UID </verb></tscreen> Si se desea indicar el UID de un destinatario para cifrar un fichero con su clave, puede hacerse con la opción <tscreen><verb> -r </verb></tscreen> o la opción <tscreen><verb> --recipient </verb></tscreen> <sect1>Codificar <p> La orden para cifrar es la siguiente: <tscreen><verb> $ gpg -e [fichero] </verb></tscreen> ó <tscreen><verb> $ gpg --encrypt [fichero] </verb></tscreen> Estas órdenes cifrarían un fichero con la clave que hayamos definido por defecto en el fichero de configuración <tt/options/. Para cifrar un fichero con la clave de otro usuario: <tscreen><verb> $ gpg -er Destinatario [fichero] </verb></tscreen> Pero como ya hemos comentado anteriormente esto produciría un criptograma con el nombre de <tt/fichero.gpg/; se puede añadir la opción <tscreen><verb> --armor </verb></tscreen> para que el criptograma sea del tipo 7-bit ASCII: <tscreen><verb> $ gpg -a -er Destinatario [fichero] </verb></tscreen> que producirá un criptograma con la extensión <tt/fichero.asc/. Ya que los mensajes, ficheros, y otro tipo de datos que enviamos codificados van cifrdos con la clave del destinatario, existe el riesgo de que alguien lo haga suplantando nuestra identidad. Para evitar esto basta con firmar digitalmente todo lo que se cifre (ver <ref id="firmas" name="Firmas">). <sect1>Descodificar <p> La orden para descifrar es: <tscreen><verb> $ gpg [-d] [fichero] </verb></tscreen> ó <tscreen><verb> $ gpg [--decrypt] [fichero] </verb></tscreen> En este caso no es necesario emplear <tt>[--decrypt]</tt>, siendo opcional, ya que <tt/gpg/ usa por defecto <tscreen><verb> --decrypt. </verb></tscreen> En todos los casos que hemos nombrado aquí el resultado está direccionado a <tt/stdout/, pero puede ser redireccionado con la opción <tscreen><verb> -o [fichero] </verb></tscreen> a un fichero con cualquier otro nombre. <sect>GnuPG + PGP <p> Al ser <tt/PGP/ un programa más antiguo que <tt/GnuPG/, es normal que un nuevo usuario de <tt/GnuPG/ tenga ya instalado alguna versión de <tt/PGP/ en su sistema, y que desee mantener sus viejas claves después de actualizarse a <tt/GnuPG/. Pues bien, no sólo es posible importar el contenido de los anillos de claves sino que, alternativamente, es posible que <tt/GnuPG/ gestione los anillos de claves de <tt/PGP 2.6.3/ y <tt/PGP 5.0/. Hay otros «problemas» de compatibilidad sobre los que también trataremos en este capítulo, como son las firmas de tipo <bf/V4/ generadas por <tt/GnuPG/, o el uso por parte de <tt/PGP/ de los algoritmos propietarios <tt/RSA/ o<tt/IDEA/. Empezaremos por esto último. <sect1>Uso de algoritmos <it>no libres</it> <p> El uso de algoritmos con patentes restrictivas por parte de <tt/PGP/ representa un problema por cuanto la filosofía que inspira a <tt/GnuPG/ de implementar un sistema criptográfico libre. Así pues, las patentes sobre estos algoritmos imposibilitan una implementación total. Pero <tt/GnuPG/ también pretende cumplir con las reglas de los «estándares» de <it/OpenPGP/ <htmlurl url="http://www.d.shuttle.de/isil/gnupg/rfc2440.html" name="http://www.d.shuttle.de/isil/gnupg/rfc2440.html">. Existen extensiones para <it/RSA/, <htmlurl url="http://www.rsa.com" name="http://www.rsa.com"> e <it/IDEA/, <htmlurl url="http://www.ascom.ch" name="http://www.ascom.ch"> que pueden ser instaladas y que permiten cierto uso de estos algoritmos. Las claves generadas por <tt/PGP 2.6.x/ son del tipo <it/RSA/, y el algoritmo de cifrado que usa es <it/IDEA/ (también puede ser usado por <tt/PGP 5.x/). Es posible conseguir el código fuente de estos algoritmos en los ficheros <htmlurl url="ftp://ftp.guug.de/pub/gcrypt/contrib/rsa.c.Z" name="ftp://ftp.guug.de/pub/gcrypt/contrib/rsa.c.Z"> e <htmlurl url="ftp://ftp.guug.de/pub/gcrypt/contrib/idea.c.Z" name="ftp://ftp.guug.de/pub/gcrypt/contrib/idea.c.Z">. También existen los binarios instalables de estas extensiones para algunas distribuciones de <htmlurl url="http://www.linux.org" name="Linux">, como <htmlurl url="http://www.debian.org" name="Debian"> (comprobar para otras distribuciones). <sect1>Firma digital con GnuPG <label id="firmas"> <p> <tt/GnuPG/ es el único sistema capaz de implementar firmas digitales <bf/V4/ (de acuerdo con <em/OpenPGP/) y esta es la opción por defecto, pero en este caso <tt/PGP/ no es capaz de verificarlas. Es posible obligar a <tt/GnuPG/ a usar <bf/V3/, de dos modos: <itemize> <item>Indicándolo en el fichero de configuración <tt>$HOME/.gnupg/options</tt> añadiendo la línea: </itemize> <tscreen><verb> force-v3-sigs </verb></tscreen> <itemize> <item>Incluyendo esta opción cada vez que se desee firmar un mensaje en <bf/V3/: </itemize> <tscreen><verb> $ gpg [opción] --force-v3-sigs [fichero] </verb></tscreen> <sect1>Importación de anillos de claves PGP a GnuPG <p> Intentaremos explicar cómo exportar las claves públicas y privadas desde nuestros anillos de claves <tt/PGP/ a los anillos de claves <tt/GnuPG/. <bf>NOTA: este método se ha extraído del <it/PGP2GnuPG Howto/, <htmlurl url="http://technocage.com/~caskey/gpg/pgp2gnupgp.html" name="http://technocage.com/~caskey/gpg/pgp2gnupgp.html"> de Caskey L. Dickson y no lo he probado personalmente. La última actualización del mismo data de Diciembre de 1998. Por ello, y para poder integrar <tt/PGP/ con <tt/GnuPG/, recomiendo el uso del método que se explica en la <ref id="anillos" name="siguiente sección"> por ser más sencillo y fiable.</bf> Suponiendo que tengamos instaladas las dos versiones de <tt/PGP/ para <tt>Unix/Linux</tt>, tenemos pues sus respectivos anillos de claves públicas y privadas en <tt>$HOME/.pgp/</tt>: <itemize> <item>pubring.pgp -> fichero de claves públicas de <tt/PGP 2.6.x/ <item>secring.pgp -> fichero de claves privadas de <tt/PGP 2.6.x/ <item>pubring.pkr -> fichero de claves públicas de <tt/PGP 5.x/ <item>secring.skr -> fichero de claves privadas de <tt/PGP 5.x/ </itemize> A continuación usaríamos las órdenes que correspondan a cada versión para extraer la(s) clave(s) que deseemos. Así, para extraer una clave de <tt/PGP 2.6.x/: <tscreen><verb> $ pgp -kx UID fichero anillo </verb></tscreen> vg.: <tscreen><verb> $ pgp -kx Pepe clavepepe2 ~/.pgp/pubring.pgp </verb></tscreen> Esta operación generaría el fichero <tt/clavepepe2.pgp/. Para extraer nuestra clave privada, no tendríamos más que indicar nuestro UID y el fichero de las claves secretas <tt>~/.pgp/secring.pgp</tt>. No nos consta que haya modo alguno de indicar más de un UID con <tt/PGP 2.6.3/, si saben de alguno, por favor envíenmelo a <htmlurl url="mailto:homega@ciberia.es" name="homega@ciberia.es">. Una vez extraída la clave sólo queda importarla al fichero de <tt/GnuPG/: <tscreen><verb> $ gpg --import clavepepe2 </verb></tscreen> Para extraer una clave de <tt/PGP 5.0/: <tscreen><verb> $ pgpk -x UID -o fichero </verb></tscreen> vg.: <tscreen><verb> $ pgpk -x Pepe -o clavepepe5 </verb></tscreen> En este caso, el fichero por defecto es el de las claves públicas, y obtendríamos el fichero <tt/clavepepe5/ como hemos indicado. Una vez más, sólo queda importar la clave: <tscreen><verb> $ gpg --import clavepepe5 </verb></tscreen> Ya que <tt/PGP 5.0/ no nos permite indicarle el fichero sobre el que queremos operar, la extracción de la clave secreta se complica un poco. La solución viene dada por un sistema superior como GnuPG: Este procedimiento pone en riesgo la clave secreta durante un breve periodo de tiempo, así que no debería ser usado en un sistema multiusuario o público. Los pasos a seguir son: <itemize> <item>Extraer la clave pública correspondiente a la clave privada que queremos exportar, e importarla a <tt/GnuPG/. <item>¡Borrar la contraseña de la clave secreta! (se recomienda hacer una copia de seguridad del fichero <tt/secring.skr/): </itemize> <tscreen><verb> $ pgpk -e UID </verb></tscreen> vg.: <tscreen><verb> $ pgpk -e 0x614DB9FA sec 1024 0x614DB9FA 1998-03-22 ---------- DSS Sign & Encrypt sub 1024 0x2B9E0571 1998-03-22 ---------- Diffie-Hellman uid Horacio <homega@vlc.servicom.es> uid Horacio <homega@correo.com> 1024 bits, Key ID 0x614DB9FA, created 1998-03-22 "Horacio <homega@vlc.servicom.es> "Horacio <homega@correo.com>" </verb></tscreen> <tscreen><verb> Do you want to unset this key as axiomatic [y/N]? N Do you want to unset this key as axiomatic [y/N]? N Do you want to add a new user ID [y/N]? N Do you want to change your pass phrase (y/N)? Y Need old passphrase. Enter pass phrase: <introducir contraseña> Need new passphrase. Enter pass phrase: <dejar vacío> Enter it a second time. Enter pass phrase: <dejar vacío> Changing master key passphrase... Changing subkey passphrase... Do want to set this as your default key [y/N]? N Keyrings updated. </verb></tscreen> <itemize> <item>El paso siguiente será exportar la clave privada. Como ya hemos podido ver, <tt/PGP 5.0/ es incapaz de hacerlo, así que usaremos <tt/GnuPG/: </itemize> <tscreen><verb> $ gpg --export-secret-keys --secret-key-ring ~/.pgp/secring.skr 0x614DB9FA > miclave </verb></tscreen> Todo esto en una una sola línea; se creará el fichero <tt/miclave/. <itemize> <item>Ahora ya podemos importar la clave secreta a GnuPG: </itemize> <tscreen><verb> $ gpg --import < miclave </verb></tscreen> Acto seguido volveremos a introducir una contraseña a la clave desde <tt/GnuPG/. <sect1>Uso de anillos de claves PGP con GnuPG <label id="anillos"> <p> Es posible evitar todo lo anterior, manteniendo instaladas las diferentes versiones de <tt/PGP/ al mismo tiempo que la de <tt/GnuPG/. Siendo <tt/GnuPG/ un sistema superior y más reciente, puede reconocer los anillos de claves de <tt/PGP/ como propios. En el caso de <tt/PGP 5.0/, basta con añadir el camino completo a los ficheros de claves de <tt/PGP 5.0/, precedido por <tt/keyring/ o <tt/secret-keyring/, al final del fichero <tt>~/.gnupg/options</tt> según corresponda: <tscreen><verb> keyring ~/.pgp/pubring.pkr secret-keyring ~/.pgp/secring.skr </verb></tscreen> Los ficheros de claves de <tt/PGP 2.6.3/ son reconocidos por <tt/GnuPG/ por defecto. Si no fuera así, bastaría con repetir la misma operación anterior adaptándola a las circunstancias: <tscreen><verb> keyring ~/.pgp/pubring.pgp secret-keyring ~/.pgp/secring.pgp </verb></tscreen> Si a continuación hacemos un listado de las claves públicas con <tt/GnuPG/, observaremos que lee los tres ficheros, <tt>~/.gnupg/pubring.gpg</tt>, <tt>~/.pgp/pubring.pkr</tt>, y <tt>~/pubring.pgp</tt>: <tscreen><verb> $ gpg --list-keys /home/usuario/.gnupg/pubring.gpg -------------------------------- pub 1024D/57548DCD 1998-07-07 Werner Koch (gnupg sig) <dd9jn@gnu.org> pub 1024D/A95AF46C 1998-11-29 Brenno J.S.A.A.F. de Winter <brenno@dewinter.com> sub 3072g/A3CA62A0 1998-11-29 (... y demás claves públicas DSA/ElGamal...) /home/usuario/.pgp/pubring.pkr ------------------------------ pub 1024D/FAEBD5FC 1997-04-07 Philip R. Zimmermann <prz@pgp.com> sub 2048g/42F0A0A0 1997-04-07 (... etc DSS/Diffie-Helman...) /home/usuario/.pgp/pubring.pgp ------------------------------ pub 1024R/88A17FF5 1995-09-11 IRIS-CERT, Spain (... etc RSA...) </verb></tscreen> Lo mismo sucedería con las claves privadas: <tscreen><verb> $ gpg --list-secret-keys /home/horacio/.gnupg/secring.gpg -------------------------------- sec 1024D/42337AE6 1999-03-14 Horacio (comentario) <homega@vlc.servicom.es> ssb 2048g/1F177864 1999-03-14 /home/horacio/.pgp/secring.skr ------------------------------ sec 1024D/7992AB40 1998-05-04 Horacio <homega@vlc.servicom.es> uid Horacio <homega@correo.com> ssb 2048g/917366AE 1998-05-04 /home/horacio/.pgp/secring.pgp ------------------------------ sec 1024R/32D4A925 1997-09-23 Horacio <homega@vlc.servicom.es> </verb></tscreen> <sect>Firmar y Verificar <label id="fyv"> <p> Firmar y verificar firmas es una parte importante de los sistemas de criptografía de clave pública. El usuario puede firmar una serie de datos o un documento de varias maneras, para lo que usa su propia clave privada. Para verificar las firmas de otros usuarios, es necesario poseer previamente las claves públicas de éstos. <sect1>Firmar <p> Para firmar un fichero con la clave propia se usa la orden <tscreen><verb> $ gpg -s [fichero] </verb></tscreen> ó <tscreen><verb> $ gpg --sign [fichero] </verb></tscreen> Esta orden, además de producir una firma digital, también comprime el fichero, por lo que el resultado es un fichero de tipo binario (y por tanto ilegible). Para producir un fichero firmado legible (ascii), se usa la orden <tscreen><verb> $ gpg --clearsign [fichero] </verb></tscreen> De este modo, tanto la firma como los datos firmados, son legibles con un editor. Cuando queramos que la firma aparezca en un fichero separado, sobre todo cuando se trata de firmar un fichero binario, como por ejemplo un archivo comprimido, o un ejecutable, usaremos la orden <tscreen><verb> $ gpg -b [fichero] </verb></tscreen> ó <tscreen><verb> $ gpg --detach-sign [fichero] </verb></tscreen> Este es el modo que MIME/PGP usa para firmar los mensajes del correo electrónico. Este modo es muy útil cuando tengamos que firmar un binario, por ejemplo, para distribuirlo, ya que la firma se basa en el binario pero va en un fichero aparte. La opción <tt/--armor/ también puede ser de utilidad en estos casos. A menudo debemos cifrar y firmar un fichero a un tiempo. La orden que usaríamos en este caso sería <tscreen><verb> $ gpg [-u Remitente] [-r Destinatario] [--armor] --sign --encrypt [fichero] </verb></tscreen> La funcionalidad de las opciones <tt/-u (--local-user)/ y <tt/-r (--recipient)/ es la que se ha descrito ya anteriormente. <sect1>Verificar <p> Al descifrar un criptograma que también haya sido firmado digitalmente, la firma se verifica automáticamente. En todo caso es posible verificar la firma simplemente con la orden <tscreen><verb> $ gpg [--verify] [fichero] </verb></tscreen> <sect>Fuentes de Información <label id="font"> <p> <sect1>GnuPG <p> <itemize> <item>Página principal de GnuPG: <htmlurl url="http://www.gnupg.org/" name="http://www.gnupg.org/"> (en inglés) <item>Archivos de la lista de correo de GnuPG <htmlurl url="http://www.gnupg.org/docs.html" name="http://www.gnupg.org/docs.html"> (en inglés) <item>La información contenida en el paquete de instalación o de fuentes, sobre todo: </itemize> <tscreen><verb> $ gpg --help </verb></tscreen> <sect1>PGP <p> <tt/PGP/ es el programa de criptografía más antiguo y, de momento, más extendido. Se ha escrito mucha documentación en torno a <tt/PGP/. Mucha de esta información se puede usar para entender mejor el funcionamiento de <tt/GnuPG/. <itemize> <item>La página internacional de PGP, <htmlurl url="http://www.pgpi.com/" name="http://www.pgpi.com/">. Desde aquí es posible acceder a mucha información sobre <tt/PGP/ en varias lenguas (aunque principalmente en inglés). <item><it/PGP DH vs. RSA FAQ/, <htmlurl url="http://www.hertreg.ac.uk/ss/pgpfaq.html" name="http://www.hertreg.ac.uk/ss/pgpfaq.html">. Preguntas y respuestas sobre las diferencias entre los algoritmos &dquot;Diffie-Hellman&dquot; y &dquot;RSA&dquot;. </itemize> <sect1>Recursos en castellano <p> Existen multitud de recursos en la red para hispanohablantes. Aquí nombraremos un par de ellos desde los que podremos acceder a muchos otros: <itemize> <item>Página del boletín electrónico sobre seguridad Kriptópolis: <htmlurl url="http://www.kriptopolis.com" name="http://www.kriptopolis.com">. <item>Páginas sobre PGP de RedIris: <htmlurl url="http://www.rediris.es/pgp/" name="http://www.rediris.es/pgp/"> </itemize> <sect1>Servidores de claves <p> <itemize> <item><it/Keyserver Net/, <htmlurl url="http://www.keyserver.net/" name="Keyserver Net"> <item><htmlurl url="http://wwwkeys.eu.pgp.net/" name="http://wwwkeys.eu.pgp.net/" <item>Servidor de RedIris: <htmlurl url="http://www.rediris.es/cert/keyserver/" name="http://www.rediris.es/cert/keyserver/"> </itemize> <sect1>Libros <p> <itemize> <item><label id="BSchneier">B. Schneier, ``Applied Cryptography, Second Edition'', Wiley, 1996&nl; Deutsche Ausgabe unter dem Titel ``Angewandte Kryptographie'', Addison-Wesley, 1996 </itemize> <sect>Sobre este Documento <p> Copyright © 1999 J.H. M.G. (versión en castellano)&nl; Copyright © 1999 Brenno J.S.A.A.F. de Winter (versión en inglés)&nl; Copyright © 1999 Michael Fischer v. Mollard (versión original en alemán) Este documento es documentación libre y puede ser redistribuido o modificado bajo los términos de la Licencia Pública GNU, según publicada por la Free Software Foundation en su versión 2 (u otra posterior). Este documento se distribuye esperando que pueda ser útil, pero SIN NINGUNA GARANTÍA. Ver la <it/GNU Library General Public License/, (<htmlurl url="http://www.gnu.org/copyleft/gpl.html" name="http://www.gnu.org/copyleft/gpl.html">), o una traducción de ésta al castellano en <htmlurl url="http://visar.csustan.edu/~carlos/gpl-es.html" name="http://visar.csustan.edu/~carlos/gpl-es.html">, para obtener más detalles. Debería haber recibido una copia de la <it/GNU Library General Public License/ con la distribución del programa; si no es así, puede recibirla escribiendo a: <tscreen><verb> Free Software Foundation, Inc. 59 Temple Place - Suite 330 Boston, MA 02111-1307 USA </verb></tscreen> <sect1>Versiones <p> Versión original en alemán: La <bf/versión 0.1/ fue la primera versión en alemán. Todos los cambios para la versión original, en alemán, están documentados en un fichero diff: <htmlurl url="http://www.stud.uni-goettingen.de/~s070674/GnuPGMiniHowto/" name="http://www.stud.uni-goettingen.de/~s070674/GnuPGMiniHowto/"> <itemize> <item><bf/English version 0.1.0/, del 30 de Mayo de 1999. Esta versión es una traducción de la versión alemana al inglés, con algunos cambios. <item><bf/Deutsche Version 0.1.1/ <itemize> <item>Nueva sección <it/Límites en seguridad/ <item>Mejorada la explicación sobre firmas <item>Varios cambios sugeridos por Werner Koch (¡gracias!) </itemize> <item><bf/Versión 0.1.2/, del 29 de Mayo de 1999 (Anno 2752 ad Urbe condita). Esta versión en castellano es una traducción de la versión inglesa, y se han realizado algunos cambios. Se ha añadido el capítulo 5 sobre compatibilidad e interoperabilidad de <tt/GnuPG/ con <tt/PGP/. <item><bf/Versión 0.1.3/, del 28 de Septiembre de 1999. Reescrito a código SGML (LinuxDoc) desde el código HTML. Corrección de algunos errores en castellano. </itemize> <bf/Notas para la versión española:/ Cualquier comentario o corrección al documento que ayude a mejorarlo es bienvenido. Por favor, envíe cualquier sugerencia a <htmlurl url="mailto:homega@ciberia.es" name="homega@ciberia.es">. <bf/Notas para la versión inglesa:/ All remarks for this document can be send to Brenno J.S.A.A.F. de Winter <htmlurl url="mailto:brenno@dewinter.com" name="brenno@dewinter.com">. Comments help us make a better document and are greatly appreciated. <bf/Notas para la versión alemana:/ Anregungen, Kritik, Verbesserungen und Erweiterungen einfach an Michael Fischer v. Mollard <htmlurl url="mailto:fischer@math.uni-goettingen.de" name="fischer@math.uni-goettingen.de"> senden, damit dieses Dokument weiter verbessert werden kann. <sect>Anexo: El INSFLUG <label id="Insflug"> <p> El <it/INSFLUG/ forma parte del grupo internacional <it>Linux Documentation Project</it>, encargándose de las traducciones al castellano de los Howtos, así como de la producción de documentos originales en aquellos casos en los que no existe análogo en inglés, centrándose, preferentemente, en documentos breves, como los <em/COMOs/ y <em/PUFs/ (<bf/P/reguntas de <bf/U/so <bf/F/recuente, las <it/FAQs/. <tt/:)/ ), etc. Diríjase a la sede del Insflug para más información al respecto. En ella encontrará siempre las <bf/últimas/ versiones de las traducciones «oficiales»: <tt><htmlurl url="http://www.insflug.org" name="www.insflug.org"></tt>. Asegúrese de comprobar cuál es la última versión disponible en el Insflug antes de bajar un documento de un servidor réplica. Además, cuenta con un sistema interactivo de gestión de fe de erratas y sugerencias en línea, motor de búsqueda específico, y más servicios en los que estamos trabajando incesantemente. Se proporciona también una lista de los servidores réplica (<it/mirror/) del Insflug más cercanos a Vd., e información relativa a otros recursos en castellano. En <tt><htmlurl url="http://www.insflug.org/insflug/creditos.php3" name="http://www.insflug.org/insflug/creditos.php3"></tt> cuenta con una detallada relación de las personas que hacen posible tanto esto como las traducciones. ¡Diríjase a <tt><htmlurl url="http://www.insflug.org/colaboracion/index.php3" name="http://www.insflug.org/colaboracion/index.php3"></tt> si desea unirse a nosotros!. «Cartel» Insflug, <tt><htmlurl url="mailto:cartel@insflug.org" name="cartel@insflug.org"></tt>. </article>