Creating PGP Key With Subkeys

The point of digitally signing and encrypting documents is not the goal of this post. It will be discussed why and how subkeys should be used.

Subkeys

By default, when you create a new public/secret key pair you create, actually, two key pairs:

• a master key used for signing documents and other keys and
• a subkey for encryption.

After that, subkeys can be added for encryption or signing.

The point on creating another subkey for signing is that you should keep you master key really safe, as it is the one that "proves" your identity. If any of your subkeys is compromised, you can revoke them and create a new subkey on the same master key, without losing all your web of trust as it would happen if your master key is compromised. There's no limit on how many subkeys can be created and how many subkeys that are expired or revoked on a master key.

How To

Initial Setup

Put these configurations into ~/.gnupg/gpg.conf

fixed-list-mode
keyid-format 0xlong
with-fingerprint
personal-digest-preferences SHA512 SHA384 SHA256 SHA224
default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 BZIP2 ZLIB ZIP Uncompressed
cert-digest-algo SHA512

This will ensure that your key will be generated using stronger preferences.

Generate Master Key

If you do not already have a master key pair, create one:

$ gpg --gen-key

Generate Subkeys

Then, use the --edit-key to add more keys:

$ gpg --edit-key mykeyid
     ... some output and require your key password
gpg > addkey

It will prompt which kind of key you want. It was only added new RSA signing subkeys with 4096 as key size and valid for an year in a total of two: one for the laptop and another for the Android phone. New encryption subkeys were not created for each device because, this way, there was not a way of decrypting everything everywhere (and people would not know which key is to be used when encrypting things for me - that is why more than one encryption key does not make much sense).

Setting Expiration Dates

It is reasonable setting expiration dates for the keys. If the password is forgotten or the key is lost other way, people will notice the key is no longer valid.

If it was not set on subkey creation, this is how to set expiration date:

Use gpg --edit-key command.

Select the keys with key key_index where the key_index is based on the list from edit-key output. Then use the command expire. You will be prompted for the valid period of the key. Save modifications with save.

For example, to modify key 1 expiration date:

$ gpg --edit-key keyid
...
gpg > key 1
...
gpg > expire
 ... set the date for expiration
gpg > save

Export All Secret Keys

All secret keys will be exported to mysecretkeys file, ASCII armored, with this command:

$ gpg --armor --export-secret-keys masterkeyid > mysecretkeys

Exporting Only Secret Subkeys

To export only secret subkeys:

$ gpg --armor --export-secret-subkeys masterkeyid > mysecretsubkeys

And to export only some secret subkeys:

$ gpg --armor --export-secret-subkeys subkeyid1! ... subkeyid2! > partialsecretsubkeys

The exclamation marks (!) are mandatory.

Deleting Unwanted Subkeys

After exporting secret keys, delete subkeys that are not supposed to be on the device. Use gpg --edit-key command.

Once in edit-key mode, to select a key,then use ``key key_index` to select the keys to be deleted. Once all keys that will be removed are selected, use the delkey command.

Creating Revocation Certificates

Revocation certificates are supposed to be used when your key is compromised, and will invalidate the key.

To create a revocation certificate:

$ gpg --gen-revoke keyid > revocationcertificate

Importing Subkeys On Another Hosts

To import a key, or only subkeys, on another host is as simple as:

$ gpg --import mykeys

where mykeys is the file where the keys were exported.

Properly Storing Keys and Revocation Certificates

The master key should be kept really safe. Store the exported keys and revocation certificates on a USB stick and printed on paper. Keep another copy on a safe place, like your parent's home.

This way, if a device fail, the keys are not lost forever. If a key is compromised, there is a way to revoke it. If a key is compromised because one of the backups is compromised too, there is another bakcup to revoke the key.

External Links

• http://blog.dest-unreach.be/wp-content/uploads/2009/04/pgp-subkeys.html (accessed 2014-03-11);

• https://wiki.debian.org/Subkeys?action=show&redirect=subkeys (accessed 2014-03-11);

• https://we.riseup.net/riseuplabs+paow/openpgp-best-practices (accessed 2014-03-11): this one have a lot of "tests" to check if the key is secure;

• https://alexcabal.com/creating-the-perfect-gpg-keypair/ (accessed 2014-03-11).

Revision History

Post built on: 2014-03-12 23:38:22
Last modified on: 2014-03-12 23:37:30
First published on: 2014-02-21

Revision	Date	Description
1.00	2014-03-12	Initial Version. Published.