GnuPG/es

Esta pequeña guía le enseñará lo básico del uso de GnuPG, una herramienta para comunicaciones seguras.

Lo que aprenderá en esta guía
Esta guía asume que está familiarizado con la criptografía de clave pública, cifrado y firmas digitales. Si no es el caso, eche un vistazo al manual de GnuPG, capítulo 2, y luego vuelva a esta guía.

Esta guía le enseñará cómo instalar GnuPG, cómo crear su par de claves, cómo agregar claves a su anillo de claves, cómo enviar su clave pública a un servidor de claves y cómo firmar, cifrar y verificar o decodificar los mensajes que recibe o envía. También aprenderá cómo cifrar archivos en su computadora local para prevenir que la gente vea el contenido.

Instalación del software necesario
En primer lugar, necesita ejecutar. Muchas aplicaciones hoy en día tienen algún grado de soporte para gpg, así que es una buena idea definir crypt en su variable USE. Si quiere tener un cliente de correo electrónico que pueda usar gnupg, puede usar pine, mutt , Mozilla Thunderbird , evolution (evolution es una aplicación del tipo Microsoft Outlook para GNOME) y el cliente de correo KMail propio de KDE.

puede interesarle si usa KDE. Este pequeño programa le permite generar pares de claves, importar claves desde archivos ASCII, firmar claves importadas, exportar claves y algunas características más.

Crear su clave
Para crea su clave, debe ejecutar. La primera vez que lo haga, el programa creará algunos directorios; ejecútelo de nuevo para crear las claves:

En este momento tiene la posibilidad de elegir el tipo de clave que quiere usar. La mayoría de los usuarios elegirán la predeterminada RSA y RSA. Lo siguiente a elegir es el tamaño de la clave, recuerde que cuanto más grande se la clave, mejor. No use un tamaño superior a 2048 con claves DSA/ElGamal. Normalmente 2048 es más que suficiente para mensajes de correo electrónico normales.

Después del tamaño viene la fecha de expiración. Cuanto antes sea esta fecha, mejor. Sin embargo, la mayoría de los usuarios usan claves que nunca expiran o a lo sumo lo hacen en dos o tres años.

Elegir el tamaño de la clave

Ahora es el momento de introducir alguna información personal. Si va a enviar su clave pública a otras personas tendrá que usar su dirección real de correo electrónico.

Introducir información de usuario

Ahora introduzca la contraseña de su clave dos veces. Es una buena idea usar una contraseña segura. Si alguien consigue acceder a su clave privada y obtiene su contraseña, podrá enviar mensajes de correo electrónico en "su nombre", haciendo creer a todo el mundo que fue usted el que envió el mensaje.

A continuación, GnuPG generará su clave. Mover el ratón o reproducir un mp3 en segundo plano ayudará a acelerar el proceso porque esto genera datos aleatorios.

Generar un certificado de revocación
Después de crear sus claves debería crear un certificado de revocación. Hacer esto le permite revocar su clave en caso que algo desagradable ocurra (por ejemplo, que alguien obtenga su clave privada o contraseña).

La orden  muestra las claves en su llavero de claves públicas. Puedes usarlo para ver el ID de su clave y poder crear el certificado de revocación. Ahora es un buen momento para copiar todo el directorio .gnupg y el certificado de revocación (en escudo ASCII, ) a un medio seguro (dos disquetes o un CD-R que guarde en un lugar seguro). Recuerde que puede usar para revocar sus claves y hacerlas inutilizables en el futuro.

Exportar claves
Para exportar su clave, teclee. Casi siempre puede usar el ID de la clave o algo que la identifique (aquí hemo usado una dirección de correo electrónico). Juan tiene ahora un archivo que puede enviar a sus amigos, o poner en su sitio web para que la gente se comunique con él de forma segura.

Importar claves
Para agregar archivos a llavero de claves públicas, primero debe importarlas, luego comprobar la huella digital de la clave. Y después de verificar la huella digital debe validarla.

Ahora agregaremos la clave pública de Luis Pinto (un amigo mio) a nuestro llavero de claves públicas. Despúes de hablar con él por teléfono y de haberle preguntado por su huella digital, comparo esta huella con la salida de la orden. Como la clave es auténtica, la agrego al llavero de claves públicas. En este caso particular, la clave de Luis expira el 2003-12-01 entonces se me preguntará si quiero que mi firma en su clave expire en el mismo día.

Enviar claves a los servidores de claves
Ahora que tiene su clave, es buena idea enviarla a un servidor de claves. Hay un montón de servidores de claves en el mundo y muchos de ellos intercambian claves entre sí. Vamos a enviar la clave de Juan Nadie al servidor subkeys.pgp.net. Usaremos HTTP, por lo que si necesita usar un proxy para el tráfico HTTP, no olvide configurarlo. La orden para enviar la clave es:  donde   es el ID de la clave. Si no necesita un proxy HTTP puede quitar la opción --keyserver-options honor-http-proxy.

Puede también enviar las claves de otras personas que ha firmado al servidor de claves. Podríamos enviar la clave de Luis Pinto al servidor. De esta forma alguien que confía en su clave puede usar la firma que pusimos ahí para confiar en la clave de Luis.

Obtener claves desde los servidores de claves
Ahora buscaremos la clave de Gustavo Felisberto y agregarla al llavero de claves de Juan Nadie (solo en el caso que no se haya enterado que Gustavo Felisberto es la persona que escribió esta guía :&#41;).

Como puede ver en la respuesta del servidor tengo un par de claves que he enviado al servidor, pero actualmente solo uso B9F2D52A. Ahora Juan Nadie podrá obtenerla y firmarla si confía en ella.

¿Qué es un Agente GPG?
Hay casos cuando se está trabajando con ciertas aplicaciones donde usa su clave GPG muy frecuentemente, lo que significa debe teclear su contraseña muchas veces. Diversas aplicaciones solían ofrecer un mecanismo de cacheo de la contraseña para facilitar la vida de los usuarios. Esto, sin embargo, inhabilitaba el poder compartir esta caché con otros programas (¿Sería esto seguro?) y forzaba a las aplicaciones a reinventar la rueda una y otra vez.

Un agente GPG es una aplicación no incluida en GPG que se utiliza para mantener en caché la contraseña de forma estándar y segura. Permite a las aplicaciones usar GPG de forma concurrente: si teclea su contraseña mientras trabaja en una aplicación, otra puede trabajar con GPG sin pedir reiteradamente la contraseña para acceder a la clave, siempre y cuando el se configure correctamente el agente GPG.

Gentoo proporciona algunas aplicaciones de agente GPG. El paquete se puede considerar como referencia, y será el que usaremos en este documento.

Configurar gpg-agent y pinentry
GnuPG includes  and. is the helper application that gpg-agent uses to request the passphrase in a graphical window. It comes in three flavors: it can popup a window using the gtk+, Qt, or curses library (depending on your USE flags in ).

If you installed  with more than one popup window type, you can choose between them with  :

Now create a file called and enter the following lines which define the default timeout of the passphrase (e.g. 30 minutes) and the application to be called for when the passphrase should be retrieved the first time (e.g. the gtk+ version of pinentry).

Now configure GnuPG to use an agent when appropriate. Edit and add the following line:

Now your system is (almost) set to use the GPG agent.

Automatically Starting the GPG Agent
If you use KDE as your graphical environment, edit and uncomment the following (system-wide) or  (local user) and add the following command to it to have KDE automatically starting the GPG agent:

Additionally, uncomment the following in (system-wide) or add it to  (local user):

If you use a different graphical environment, put that line (the same one as mentioned above) in (if you use  ) or  (if you use XDM/GDM/KDM/...).

Encrypting and signing
Let's say that you have a file that you wish to send Luis. You can encrypt it, sign it, or encrypt it and sign it. Encrypting means that only Luis will be able to open it. The signature tells Luis that it was really you who created the file.

The next three commands will do just that, encrypt, sign and encrypt/sign.

This will create binary files. If you wish to create ASCII files, just add a  to the beginning of the command.

Decrypting and verifying signatures
Suppose that you have received a file which is encrypted to you. The command to decrypt it is. This will decrypt the document and verify the signature (if there is one).

Encrypting and decrypting without keys
It is also possible to encrypt files using passwords instead of keys. Well, the password itself will function as the key - it will be used as a symmetric cypher. You can encrypt the file using  's   argument; decrypting uses the same command as we talked about before.

GnuPG will ask for a passphrase and a passphrase verification.

Advanced Features
There are some nice advanced features in GnuPG. To find them, open the file.

Search for the above two lines and uncomment them. With this any time GnuPG needs to check a signature and it does not find the public key on the local keyring it will contact the key server at subkeys.pgp.net and will try to fetch it from there.

Another nice command is. This will contact the keyserver defined in the options file and refresh public keys in your local key ring from there, searching for revoked keys, new IDs, and new signatures on keys. You should probably run this once or twice a month so that if someone revokes his key you will be notified.

About email signatures
95% of the time you will use GnuPG with email, signing/encrypting your outgoing messages and reading signed/encrypted messages. So it is only fair that I talk about that first.

There are two ways two sign/encrypt a email with GnuPG, the old way and the new way :). In the old way messages would appear in plain text, with no possible formatting and attached files would be unsigned/unencrypted. Here is an example of a message signed the old way:

A plain text signature

Messages this way are no good in today's world, where we have nice GUIs and email readers that understand html.

To solve this an addition to the MIME (Multipurpose Internet Mail Extensions) was created. This adds a field to the email that tells the mail reader that the full content of the message is signed and/or encrypted. The problem with this is that not all mail readers support this. And some even mess up the content; Microsoft's Outlook is famous for not working with this.

Kgpg
Kgpg is a nice GUI for GnuPG. In the main screen you can paste the text that you wish to sign or encrypt, and you can also paste the ASCII armored text that you which to decrypt.

From within the main screen you can decrypt text (you will have to provide your password), encrypt other files, paste new text to sign....

Seahorse
Seahorse aims to be a GnuPG GUI interface for the Gnome desktop. The software has been evolving fast, but it still lacks many important features that can be found in Kgpg or the command line version.

KMail
If you have the  USE flag set, KMail will be compiled with gpg support, and will be able to encrypt and decrypt inline PGP mails automatically as well as encrypting OpenPGP/MIME mails. If you want to decrypt OpenPGP/MIME mails as well (which you probably want) you need to have a running GPG agent.

You can verify if KMail is properly configured by going to,  ,  ,. You should see a GpgME-based backend listed and you should be able to fill the OpenPGP checkbox. If it is listed but grayed out, click on. If the GpgME-based backend remains grayed out, KMail is not working properly.

If you still are unable to get KMail to behave, please see the KMail PGP HowTo page for more information.

Claws-Mail
This mail reader is very fast with big mailboxes, has all the nice features one wants in mail readers and works pretty well with gpg. The only problem is that it does not work with the old PGP signatures, so when you receive those kind of mails you have to hand check the signatures.

To use your gpg key with Claws-Mail just go to the account configuration and select the privacy tab. Once there just choose which key to use, probably most users will go with the default key.

Basic Public Key Cryptography
The concept of public key cryptography was originally devised by Whitfield Diffie and Martin Hellman in 1976. When I first heard the words "public key" and "cryptography" in the same sentence back in '93 I thought to myself that it would be impossible to do such a thing. In those days there was no Internet (well there was, but not for me) so I went to the public library and asked for books on Cryptography. I must say that I was 16 at the time so the clerk there looked to me in astonishment and brought me a book for children on substitution cyphers (those where you change a letter for another like the famous Caesar Cypher or ROT-13 (Tragbb Ebpxf, naq lbh xabj vg vf tbbq orpnhfr lbh ner ernqvat guvf qbp.), ( if you cannot read the preceding text)). I was very upset with this and started to search for more info. It is good to have mathematicians in the family, because as soon as I talked to one of them I was introduced to a new world.

And now a bit of mathematics:

Mathematical Concepts

If I give you the number 35 and I tell you that this number is the product of two prime numbers it is easy to find that it was 5 and 7. But if I tell you the same for 1588522601 you will spend alot of time (or CPU cycles) to find it was 49811*31891. And if this number is really really big this task becomes "impossible". So now if I give the world my large number that is the product of two primes I know something about that number that no one else knows.

This is the basis for Public Key Cryptography (PKC) implementations today. As an (unrealistic) example, I give anyone my number and that someone will use if for cyphering a message to me. Anyone can see the cyphered message, because I am the only one who knows a shortcut to read it, anyone else will first have to "split" that big number to be able to read the message, and it is a "fact" that it is impossible to do that in a short amount of time (todays methods and the fastest computers in the world would take thousands of years to do that). In this setup the two large prime numbers would be called the PRIVATE KEY, and the large non prime number is the PUBLIC KEY.

In practice this is not 100% accurate with reality, but will give a good idea to the newcomer. For more information, check Wikipedia on the Diffie-Hellman protocol. For even more info go to the public library and grab a copy of the "Handbook of Applied Cryptography" by Alfred J. Menezes, Paul C. van Oorschot and Scott A. Vanstone. This book is also available online for free at the above site.

One consequence of the above is that if you cypher a message to me, and you loose the original uncyphered message you will no longer be able to retrieve it from the cyphered version.

Signatures
We already saw how someone can send us a cyphered message if they have our public key. But how do we know that the author of the message is really who he claims to be? Or in other words: If I receive an email from you how do I really know it was you and not someone else claiming to be you?

Remember me saying that PKC was not as simple as I had said? The idea is that when you cypher a message to me you sign it with your private key so that, when I receive it, I can first use your public key to check your signature and then use my private key to decypher the message. As you can see we could not do that in the setup I described before.

It's also very important to sign messages so that you don't have to cypher them beforehand. Now you can create messages that can be read by anyone, but that come with your "branding". And if any single character is changed in the message it can (and will) be detected.

Key Servers and Signed Keys
But let's say that I have no previous contact with you until you send me a message: how do I get your public key, and how do I really know it is yours?

To solve this problem public Key Servers were created. When you create your key pair (Public and Private key), you send your public key to the key server. After this everyone can retrieve your key from there. This solves the problem of finding the key. But how do I really know that that key is the author's key? For this another concept must be introduced, and that is key signing:

Key signing means that if I have the public key of another person, and I know for sure that it is really that persons key (it is my personal friend, someone I know in real life, etc.) I can sign that public key and send it to keyservers, that way I am telling the world: "This key really belongs to the person it claims to belong.". That way persons that have my public key and trust me can use that trust to trust other keys.

This can sometimes be confusing so let's see a real world situation.

Let's imagine a 3 person situation: John, Mary, and Lisa. John is a good friend of Mary but does not know Lisa; Lisa is a good friend of Mary but does not know John. One day Lisa sends John a signed email. John will fetch Lisa's Public Key from the keyserver and test the message, if all went ok he will see that whoever wrote that message also created that key. But how do I know it was really the person it claims to be?

He then sees that it is signed by Mary, which he can check because he already has Mary's key and he trusts that key. With this ring of trust he continues to conclude that the email he received was really written by Lisa.

You are now ready to use this guide, you can go back to chapter 1 and learn how to use gpg.

Some problems
I had some problems with photos in keys. Check the version you are using. If you have GnuPG 1.2.1-r1 and up you are probably OK, older versions may have problems. Also most keyservers don't like keys with photos, so you are better if you don't add photos.

The latest versions of gnupg don't seem to work with the  that was used so send all keys in your keyring to the public server.

What is not here
is a very complex tool, it lets you do much more than what I have covered here. This document is for the user who is new to GnuPG. For more information, you should check the GnuPG Website.

I did not write about other tools like,  ,   and maybe Windows tools, but I will probably extend this document in the future.

Créditos
El Manual GnuPG de John Michael Ashley es un buen libro para principiantes.

Swift (Sven Vermeulen) por animarme a reescribir esta guía.

A todos los miembros del equipo #gentoo-doc, tíos, moláis.

Gracias a Tiago Serra por apoyarme en el estudio de la privacidad.

Agradecimientos
Nos gustaría dar las gracias a los siguientes autores y editores por sus contribuciones a esta guía:


 * Gustavo Felisberto
 * John P. Davis
 * Sven Vermeulen
 * nightmorph