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. |