Master key, also known as primary key, holds your trust.
If your key gets certified, those certifications will be issued on tuples of primary key and user ID. Outgoing certifications (on other keys) are also exclusively issued by your primary key.
What capabilities your primary key has depends on the algorithm chosen and what capabilities are actually enabled (you can change this when running GnuPG in the --expert mode).
All primary keys must have the certification capability C, but can have signature capability S (which must always be supported, as certifications are also signatures) and finally encryption capability E (which is not supported by all algorithms that fit a primary key, for example DSA can only be used for certifications/signatures, not for encryption).
Invoke gpg '
--full-generate-key' with the '
--expert' flag to expose some
additional menu items
$ gpg --expert --full-generate-key
Select the "RSA (set your own capabilities)" option to remove the 'Encrypt' capability from the key. Leave only the 'Certify' and 'Sign' capabilities.
Use separate, short-lived subkeys for generic sign and encryption.
Use a key-length of 4096 bit and set expiration to 3 years. If the key is still in use when the date approaches, set a new expiration date and distribute the new updated public key.
The UID (User ID) is composed by the name and e-mail of the key owner.
Real name: Davide Galassi Email address: email@example.com Comment: You selected the USER-ID: "Davide Galassi <firstname.lastname@example.org>"
A passphrase is required to protect the secret key. A passphrase is like a password but longer and can contain spaces.
At this point the keys is generated along with a revocation certificate.
The secret key is stored under
The revocation certificate under
The secret key file name is equal to the keygrip.
$ gpg --list-keys --with-keygrip
Subkeys make key management easier. You publish the subkeys on the normal keyservers, and everyone else will use them instead of the master key for encrypting messages or verify your message signatures. Likewise, you will use the subkeys for decrypting and signing messages.
The master key is used only in exceptional circumstances:
setpref) on a UID;
If a machine with a subkey is violated you can easily revoke the subkey without revoking the primary one.
Which subkey is chosen is implementation dependent, usually they will choose the newest non-revoked key capable of what you want to perform. If you add another subkey, this will be chosen. If you remove all subkeys, the primary key will be used -- given it has the necessary capability bits set. If the primary key does not support the required capability, the key cannot be used at all!
In GnuPG, you can enforce a specific subkey: by specifying the key ID followed by '!'. For example, if you want to enforce usage of subkey DEADBEEFDEADBEEF as a recipient, use the option --recipient DEADBEEFDEAEDBEEF!.
Subkeys can be arbitrarily revoked and regenerated without losing reputation in the web of trust.
--edit-key option should bring us to the gpg command prompt.
Is suggested to use the
--expert option as well to have more control on
addkey command for each subkey you want to add.
Use the "
RSA (set your own capabilities)" option and create one key to
sign only, one to encrypt only and one to authenticate only.
Set the expiration to a relative short date (e.g. 6 months).
When finished, use the
save command to exit the prompt.
The simples way to backup all the information is to copy the secret and
public keyrings (
to a removable media.
Export the key information in 'armor' format (printable base64 encoded data).
Export the secret key
$ gpg --armor --export-secret-key email@example.com > secret_key.asc
Export the public key
$ gpg --armor --export firstname.lastname@example.org > public_key.asc
Create a revocation certificate
$ gpg --armor --gen-revoke email@example.com > revocation_cert.asc
You can also decide to export, separatelly, the subkeys
$ gpg --armor --export-secret-subkeys firstname.lastname@example.org > secret_subkeys.asc
After that you've exported the secret subkeys in a separate file, delete the secret key (and subkeys) from the keyring.
$ gpg --delete-secret-key email@example.com
Re-import only the subkeys
$ gpg --import secret_subkeys.asc
If you run the
gpg --list-secret-key command you must see a "sec#" on the
first few lines of output. This indicates that the secret key is no more
The secret subkeys are known as laptop keypair.
At this point you can change the "complicated" and "super-secret" passphrase protecting the keyring with something more practical for day-by-day usage.
$ gpg --edit-key firstname.lastname@example.org passwd
(If your master key was removed you'll receive an error for that key)
This format is deduced from the length of the string and its content or the 0x prefix. Note, that only the 20 byte version fingerprint is available with gpgsm (i.e. the SHA-1 hash of the certificate).
When using gpg an exclamation mark (!) may be appended to force using the specified primary or secondary key and not to try and calculate which primary or secondary key to use.
The best way to specify a key Id is by using the fingerprint. This avoids any ambiguities in case that there are duplicated key IDs.
The key ID are the low 64 bits of its SHA-1 fingerprint.
The use of key IDs is just a shortcut, for all automated processing the fingerprint should be used.
You are ready to distribute your public key to a keyserver.
A good key server to load your public key:
To list the public keys
$ gpg --list-keys
To list the secret keys
$ gpg --list-secret keys
To see signatures
$ gpg --list-signatures
To see the fingerprints
$ gpg --fingerprint
To delete a public key
$ gpg --delete-key UID
To delete a secret key
$ gpg --delete-secret-key UID
$ gpg --import keyfile
Make a cleartext signature. The content in a cleartext signature is readable without any special software.
$ gpg --clear-sign filename
Make a detached signature.
$ gpg --detach-sign
The operation requires a private key. If multiple private keys are present,
the key is selected via the
-u <user> option.
To verify a signature
$ gpg --verify signaturefile
Encryption is done using the recipient (-r) public key. The public keys
available are listed in our public keyring (
$ gpg -r email@example.com --armor --encrypt message.txt
The output is stored in an ascii file
$ gpg --decrypt message.txt.asc
The private key passphrase is eventually asked.
To edit key some key metadata
gpg --edit-key UID
This command will leave you in the gpupg prompt. From here several commands
are availbale. The
help command is your friend.
A public key can be signed so that you are absoltely positive that this key is valid. With that reassurance you can start encrypting.
gpg --edit-key UID command for the key to be signed you can sign it
Edit the key to per renewed (be sure to have imported the secret master key)
gpg --edit-key [keyname]
Lists the available subkeys:
Choose the number of the subkey you want to edit; e.g. key 1
command> key [subkey]
Set a new experation date for the subkey.
Save and exit
If your laptop keypair is compromised, we need to revoke the subkeys on that keypair.
Given a gpg fresh install, import your master keypair from the backup.
$ gpg --import public_key.asc private_key.asc
Now use the
--edit-key option to enter the gpg prompt and to
interactively revoke your subkeys.
One key is selected giving the key number (respect to the lising order):
for example the command
key 2, within the prompt, select the second
> key 2 > key 3 > key 4
Once that the keys are selected revoke the subkeys validity with the
Follow the on-screen instructions and
save the modifications.
Now that your subkeys has been revoked, you have to tell the world about it by distributing your key to a key server.
proudly self-hosted on a cheap Raspberry Pi 2