Usando GNUpg

El primer paso que se debe dar para un sistema de clave asimétrica es crear el par de llaves público/privado, usando el comando:

  gpg --key-gen

The first invocation will only set up the necessary configuration files; to actually generate the keys and enter your passphrase you will have to run it the second time.

You should normally use the default key type, DES + ElGamal. The passphrase can be long, so it should be easy to come up with something that's meaningful to you and easy to remember. The usual hints about using passwords apply: no simple dictionary words, nothing that someone who knows enough about you will think of trying, etc.

It's probably best for the key not to have an expiration date, unless you do plan to regularly change the public key. Even if there is no expiration, a key can be later revoked, i.e. marked as no longer used.

The default key size of 1024 bits is suitable for most users, but if you are worried that codebreaking technology will advance faster than we expect, or if you plan to use the keys to guard something truly important, you may want to choose 2048 (the tradeoff is somewhat slower processing).

The message about doing something while “entropy is generated” can be safely ignored. It takes quite a while for the key pair to be generated. You will also be asked to sign (certify) the new key yourself.

You should first check what's on your keyrings. If you type gpg –list-keys you should see something that looks like this:

pub  1024D/8D81599D 2002-08-01 Eric Behr <behr@math.niu.edu>
sub  1024g/C87C359C 2002-08-01

This describes your public key, whose unique ID is 8D81599D. The second line represents a “subsidiary key”. There may be many of those attached to the master key, e.g. when other people start certifying your public key. If you do gpg –list-secret-keys, you should see the listing of your secret keyring (which should now contain the same key IDs).

It's time to let the world know about this (if that's what you wish). The keys are stored in efficient binary form on your keyring, which makes it hard for humans to handle them. You can generate a text version of the public key as follows: gpg –armor –export your_key_ID (instead of the key ID such as 8D81599D you can also use the associated e-mail address, or even just the name; if there is ambiguity, the software will ask you which key you have in mind).

In most commands the –armor option tells gpg that you want the result to be in readable ASCII (suitable, say, for including it in a plain e-mail message), as opposed to a binary format.

This will print out something like this. It can be placed on your web page, given to friends, submitted to a “keyserver” such as www.keyserver.net or pgpkeys.mit.edu (just paste the whole text into the window), etc.

To encrypt and/or sign messages to someone you need to have that person's public key on your keyring. This is done by getting it (e.g. from a keyserver), putting it in a file - say bobskey.txt, and then running gpg –import bobskey.txt (or you can just do gpg –import and simply paste the text while gpg is waiting, then hit Control-D which to most Unix programs indicates “end of file”). gpg should tell you how many keys it found and imported. You can use –list-keys again to see what got imported. If you see several “sig” entries, this means that Bob's public key was signed by other people. If you already have their verified keys on your keyring, this may increase your confidence in the public key you just imported. If not, you should try to verify the key with Bob (who knows, maybe it's his ISP who is masquerading as Bob, and wants to read his secret e-mail?).

To verify a key it's best to first generate a “fingerprint” of the key you imported, with gpg –fingerprint bobs_key_ID. This will spit out a string of hex digits such as 96CA 01D9 600C A35C 0286 7438 ECD6 2C4C AD86 58C3. You can now call Bob at home and (assuming you recognize his voice ask him to generate the fingerprint of his secret key, e.g. with gpg –fingerprint –list-secret-key bobs_keyID. The two should match exactly. You can now be confident that Bob's key that you have on the keyring is authentic. You might decide to sign it with gpg –sign-key bobs_keyID, then export the ASCII version of Bob's key and send it to him, or submit it to a keyserver. This way people who already trust that they have your authentic key, and trust you as a person, may choose to trust Bob's key without further validation.

All this sounds quite paranoid, but remember that in this area the confidence in the process can only be as strong as the weakest link in it.

So finally we have a valid public key for Bob on the ring, and we can send him a message. To encrypt a message meant for Bob's eyes only, do gpg –encrypt –recipient bob@somewhere.com file_name (the recipient can be specified using anything that uniquely identifies Bob's public key on your keyring: the key ID, Bob's name, etc.) This will create a file file_name.gpg containing encrypted and compressed binary version of the original. You can now mail it to Bob (as an attachment).

If you add the option –armor in the above command, the resulting text file will be called file_name.asc, and can be simply pasted into a mail message rather than attached.

You can also use the option –sign in such a command; in this case you will have to provide your passphrase, and the resulting message will contain the additional data telling Bob that it was indeed you who sent the message (assuming that Bob has your public key on his keyring).

There are situations when you don't have any specific recipient in mind, but you would still want to sign the data; for example, when you are sending an announcement to a mailing list or a newsgroup, and you want the skeptics out there to be able to verify that it's indeed from you. You can then do gpg –clearsign file, and a file.asc will be created, with the original message sandwiched between the components of the signature (this should only be done with ASCII files). The result can be sent as a regular letter by e-mail. To sign a binary file, such as a Word document or an executable program, simply do gpg –sign file, and the resulting file.gpg will contain the original along with a signature. You can then mail it as an attachment or post it on a Web page, and whoever receives it will be able to verify that it originated with you (and to check the integrity of the restored file at the same time). In some countries such digital signatures already have a full legal status, just like ordinary ones.

Finally, gpg can be used to perform the old-fashioned encryption of your own files. If you are worried about prying eyes of the system administrator, or that some other user might get at sensitive data because of improperly set permissions, you can use gpg –symmetric file to do it. You will be asked for a passphrase again, but this is completely separate from the one you chose to protect your secret PGP key, so it may be wise to use a different one in case one of these secrets is somehow compromised.

One example of when I use this is when I create a public key. If it so happens that I forget my GNUPG passphrase, or if a disk crash or system update wipes out my secret key, I want to be able to “revoke” or invalidate my old public key and start from scratch. But I can't do that without the secret key or passphrase! So after generating a public key, I also generate a “revocation certificate” for it, even though I plan to use the key for quite a while. This is done with gpg –armor –gen-rev keyID, which produces PGP data indicating that this key should no longer be used. When it is submitted (like any other PGP information) to one of the keyservers, they will mark my public key as expired. It's a good idea to have one of these lying around.

So far so good, but if I store this “just-in-case” revocation somewhere, it can somehow fall in the wrong hands, and the evildoer will all of a sudden be able to revoke my perfectly valid public key simply by pasting the revocation certificate into one of the keyservers.

The damage done this way to a typical user isn't great, but it can lead to confusion and some hassle (you have to redistribute the new public key and rebuild the “trust network”). So to avoid this I store the revocations in a form that is encrypted using the –symmetric flag, with some easily remembered simple password, just to make the evildoer's job harder.

GNUPG in e-mail and Usenet news

Two e-mail programs on our system are GNUPG-aware: mutt (similar to elm), and tkrat (a GUI mailer somewhat similar to Eudora or Outlook). The default settings should automatically make them use our gpg installation. We don't (yet) have a newsreader which would have a similar feature.

Note that on our system the commands pgp and gpg are synonymous. Also, wherever it makes sense, the –armor flag will produce ASCII rather than binary output; the –sign option will let you sign the message; the -v or –verbose flag provides more details on what's going on; and the –output option will let you choose a non-default filename for the result.

generate a new secret key:

gpg --gen-key

listing keys, with fingerprint:

gpg --fingerprint --list-keys

exporting cleartext public key to an ASCII file:

gpg --output file --armor --export behr@math.niu.edu

signing someone's public key with your secret key:

gpg --sign-key keyID

importing keys from file:

gpg --import file

encrypting a file (you must have the recipient's key on the keyring):

gpg --encrypt --recipient rickert@cs.niu.edu file

(then e.g. mail as an attachment)

decrypting a received file:

gpg --decrypt file

encrypting with a symmetric (non public) cipher:

gpg --symmetric file

(best to use a different passphrase than the one for private key) this produces file.gpg; then decrypt it simply with

gpg file.gpg

signing a text file (e.g. for mail), output in file.asc:

gpg --clearsign file

signing a file (binary output in file.gpg):

gpg --sign file

verifying a signed file without unpacking the original:

gpg --verify file

creating a detached signature (file unchanged, signature in file.sig):

gpg --detach-sig file

verifying a detached signature of a file:

gpg --verify file.sig