Generating More Secure GPG Keys: A Step-by-Step Guide

This is part of a series on GNU Privacy Guard:

  1. Getting Started with GNU Privacy Guard
  2. Generating More Secure GPG Keys: Rationale
  3. Generating More Secure GPG Keys: A Step-by-Step Guide (this post)
  4. Using an OpenPGP Smartcard with GnuPG

gpg_subkeysIn this post, I’ll will cover the generation of a new GPG key and removal of the primary key, one of two mitigation strategies mentioned in the previous post. The next post in the series will demonstrate the second strategy: using this new key with a SmartCard.

A Secure Environment

We’ll start by generating a brand new key in a fairly secure environment. To do this we’ll want to boot into a LiveCD or LiveUSB environment to reduce the likelihood of malware interfering with the key generation process or stealing our new secrets. We’ll also want to do this in an offline environment. I happened to use a Tails Live USB Stick and an old netbook with wireless networking disabled so I’ll describe a similar process here.

The FSFE SmartCard Guide

Once Tails has booted, we can open a Terminal shell and start generating our new key.

We’ll follow along with roughly the approach recommended by Free Software Foundation Europe. The “Fellowship SmartCard” provided to FSFE Fellows implements the same OpenPGP SmartCard standard as the current version (Last changed: 2013-04-23 08:19:15) of their Card HowTo is quite good.

The guide recommends setting up your card reader first. We’ll worry about that later. We’re already offline and booted into a trusted live operating system, so we can jump right into generating the key.

Generating the Primary Key

Expert Mode

Invoke gpg --gen-key with the --expert flag to expose some additional menu items.

$ gpg --expert --gen-key
gpg (GnuPG) 1.4.12; Copyright (C) 2012 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Please select what kind of key you want:
   (1) RSA and RSA (default)
   (2) DSA and Elgamal
   (3) DSA (sign only)
   (4) RSA (sign only)
   (7) DSA (set your own capabilities)
   (8) RSA (set your own capabilities)
Your selection? 8

Capabilities

Choose (8) RSA (set your own capabilities). Then set the capabilities of the key to only Certify by toggling Signing and Encryption off.

Possible actions for a RSA key: Sign Certify Encrypt Authenticate
Current allowed actions: Sign Certify Encrypt

   (S) Toggle the sign capability
   (E) Toggle the encrypt capability
   (A) Toggle the authenticate capability
   (Q) Finished

Your selection? s

Possible actions for a RSA key: Sign Certify Encrypt Authenticate
Current allowed actions: Certify Encrypt

   (S) Toggle the sign capability
   (E) Toggle the encrypt capability
   (A) Toggle the authenticate capability
   (Q) Finished

Your selection? e

Possible actions for a RSA key: Sign Certify Encrypt Authenticate
Current allowed actions: Certify

   (S) Toggle the sign capability
   (E) Toggle the encrypt capability
   (A) Toggle the authenticate capability
   (Q) Finished

Your selection? q

We’ll be using separate, short-lived subkeys for these purposes, but there are rare cases where you may be required to use this primary key for signing instead of a subkey certified by it (for example, if you need to prove ownership of this key to a party that doesn’t recognize subkeys).

As long as you have the private key material, it’s theoretically feasible to use keys for any purpose. But in practice, it simplifies things greatly if you have the capabilities you intend to use attached to the metadata for the keys when you generate them. Feel free to leave the Signing capability enabled if you’re worried about being hampered by this in the future.

Key-length

While the guide uses a 2048-bit key, we’ll use a 4096-bit key. Unless a larger key size isn’t well-suited for your needs (e.g. not being supported by software you need to use it with), it makes sense to use the largest key size available to ensure the key will be difficult to crack long into the future. And after all, a 4096-bit key is what Bruce Schneier is using these days.

RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048) 4096
Requested keysize is 4096 bits

Expiration

Though the intent is to maintain this primary key more or less permanently — or at least until 4096-bit RSA is no longer thought to be secure — setting an expiration date on this key (for far into the future) may still be prudent, in the case (by that time) we have lost both the secret key and any copies we had of its revocation certificate. When you have the private key, you can always push an expiration date back, so let’s set this key to expire in 3 years. If we’re still using it when that date approaches, we can set a new expiration date and distribute the updated public key.

Please specify how long the key should be valid.
         0 = key does not expire
        = key expires in n days
      w = key expires in n weeks
      m = key expires in n months
      y = key expires in n years
Key is valid for? (0) 3y
Key expires at Thu 03 Nov 2016 08:18:42 PM UTC
Is this correct? (y/N)y

uid

Next add a uid (name and e-mail).

You need a user ID to identify your key; the software constructs the user ID
from the Real Name, Comment and Email Address in this form:
    "Heinrich Heine (Der Dichter) <[email protected]>"

Real name: John Doe
Email address: [email protected]
Comment:
You selected this USER-ID:
    "John Doe <[email protected]>"

Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o

You can add additional uids later, if you wish.

Passphrase

You need a Passphrase to protect your secret key.

Enter passphrase:

Make sure to use a very strong passphrase here. Something long and hard to guess. If an attacker ever gets a copy of your secret key, this pass phrase should keep them from using it, or at least make it much more difficult.

Key Generation

We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.

..........+++++
.+++++
gpg: key 144A027B marked as ultimately trusted
public and secret key created and signed.

gpg: checking the trustdb
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0  valid:   1  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 1u
gpg: next trustdb check due at 2016-11-03
pub   4096R/144A027B 2013-11-04 [expires: 2016-11-03]
      Key fingerprint = 6E95 9C3A 35E7 6783 2BF4  BA32 21BB 9DA3 144A 027B
uid                  John Doe <[email protected]>

It’s important to have a lot of entropy available to this process, otherwise the keys produced may be more easily predicted. If you’re following along and you’ve generated keys on other machines before, you may have been surprised by how quickly this one was created. This is in part due to the fact that Tails uses haveged as a source of additional entropy.

On other systems, you may get a message like:

Not enough random bytes available. Please do some other work to give
the OS a chance to collect more entropy! (Need 87 more bytes)

And use mouse movements to generate this additional entropy.

Adding Subkeys

At this point, we have an OpenPGP key with only a 4096-bit RSA primary key for Certifying other keys.

$ gpg -k
/home/amnesia/.gnupg/pubring.gpg
--------------------------------
pub   4096R/144A027B 2013-11-04 [expires: 2016-11-03]
uid                  John Doe <[email protected]>

$ gpg -K
/home/amnesia/.gnupg/secring.gpg
--------------------------------
sec   4096R/144A027B 2013-11-04 [expires: 2016-11-03]
uid                  John Doe <[email protected]>

Now we can add the subkeys we’ll use for Signing, Encryption, and Authentication.

edit-key

Using --expert with gpg is like holding down alt/option on a Mac — it’s a good way to get at additional functionality that’s hidden from the default menus.

--edit-key should bring us to a prompt like this:

$ gpg --expert --edit-key [email protected]
gpg (GnuPG) 1.4.12; Copyright (C) 2012 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Secret key is available.

pub  4096R/144A027B  created: 2013-11-04  expires: 2016-11-03  usage: C
                     trust: ultimate      validity: ultimate
[ultimate] (1). John Doe <[email protected]>

gpg>

addkey

At this prompt, we’ll use addkey to add our subkeys. When we’re done, we should be left with a 4096-bit RSA primary key with the ‘certify’ capability and a three-year expiration and three 3072-bit RSA subkeys that expire six months from now with ‘sign’, ‘encrypt’, and ‘authenticate’ capabilities set accordingly.

We’ll invoke addkey for each of the subkeys we want to add.

gpg> addkey
Key is protected.

You need a passphrase to unlock the secret key for
user: "John Doe <[email protected]>"
4096-bit RSA key, ID 144A027B, created 2013-11-04

Enter passphrase:

As we did with the primary key, we’ll toggle the capabilities of each key we add such that we’re left with only the one capability we want for that key.

Please select what kind of key you want:
   (3) DSA (sign only)
   (4) RSA (sign only)
   (5) Elgamal (encrypt only)
   (6) RSA (encrypt only)
   (7) DSA (set your own capabilities)
   (8) RSA (set your own capabilities)
Your selection? 8

Possible actions for a RSA key: Sign Encrypt Authenticate
Current allowed actions: Sign Encrypt

   (S) Toggle the sign capability
   (E) Toggle the encrypt capability
   (A) Toggle the authenticate capability
   (Q) Finished

Your selection? e

Possible actions for a RSA key: Sign Encrypt Authenticate
Current allowed actions: Sign

   (S) Toggle the sign capability
   (E) Toggle the encrypt capability
   (A) Toggle the authenticate capability
   (Q) Finished

Your selection? q

The FSFE guide uses 1024-bit subkeys because that’s all the v1 SmartCards supported. The OpenPGP SmartCard v2 actually supports RSA keys up to 4096-bits, but only recent versions of GnuPG have support for working with keys that large on the SmartCard. With the 1.x.x branch of GnuPG, we can transfer RSA subkeys up to 3072 bits to the SmartCard v2. While the 2.x.x branch of GnuPG supports transferring 4096-bit keys, we’ll stick to 3072-bit keys to ensure compatibility with the older codebase.

RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048) 3072

For reasons discussed in my Secure GPG Keys post, we’ll set these subkeys to expire relatively soon:

Please specify how long the key should be valid.
         0 = key does not expire
        = key expires in n days
      w = key expires in n weeks
      m = key expires in n months
      y = key expires in n years
Key is valid for? (0) 6m
Key expires at Sat 03 May 2014 08:24:29 PM UTC
Is this correct? (y/N)y

After specifying the key type, capabilities, bit length, and expiration, we’ll generate the actual subkey:

Really create? (y/N) y
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.

Not enough random bytes available.  Please do some other work to give
the OS a chance to collect more entropy! (Need 268 more bytes)
+++++

Not enough random bytes available.  Please do some other work to give
the OS a chance to collect more entropy! (Need 8 more bytes)
+++++

pub  4096R/144A027B  created: 2013-11-04  expires: 2016-11-03  usage: C
                     trust: ultimate      validity: ultimate
sub  3072R/E02EDE61  created: 2013-11-04  expires: 2014-05-03  usage: S
[ultimate] (1). John Doe <[email protected]>

gpg>

(Repeat this addkey process for the Encryption and Authentication subkeys)

While we’re still editing the complete key, we could also add addional uids, e.g. work e-mail address or other organizational addresses we might be known by. Typing adduid at the prompt will allow you to add additional uids.

We could even add a small (~120x144px, ~4KB JPEG) photo with addphoto if we wanted, but that’s probably not worth the effort of creating and bringing into our “air-gapped” environment right now.

When we’re finished, we’ll save the key to our keyring.

pub  4096R/144A027B  created: 2013-11-04  expires: 2016-11-03  usage: C
                     trust: ultimate      validity: ultimate
sub  3072R/E02EDE61  created: 2013-11-04  expires: 2014-05-03  usage: S
sub  3072R/A59563DA  created: 2013-11-04  expires: 2014-05-03  usage: E
sub  3072R/B2E31884  created: 2013-11-04  expires: 2014-05-03  usage: A
[ultimate] (1). John Doe <[email protected]>

gpg> save
$

Creating Backups

Backing up Keyrings

Next, we’ll want to prepare some backups. The simplest way to back up all of the information we might want would be to copy our secret and public keyrings (~/.gnupg/secring.gpg and ~/.gnupg/pubring.gpg) to removable media (e.g. a thumbdrive or CD-R).

Backing Up Secret Keys & Generating a Revocation Certificate

We can make things a little more future-proof and a little more usable for ourselves though if we actually export our secret key…

$ gpg -a --export-secret-key [email protected] > secret_key

…generate a revocation certificate…

$ gpg -a --gen-revoke [email protected] > revocation_cert.gpg

sec  4096R/144A027B 2013-11-04 John Doe <[email protected]>

Create a revocation certificate for this key? (y/N) y
Please select the reason for the revocation:
  0 = No reason specified
  1 = Key has been compromised
  2 = Key is superseded
  3 = Key is no longer used
  Q = Cancel
(Probably you want to select 1 here)
Your decision? 1
Enter an optional description; end it with an empty line:
>
Reason for revocation: Key has been compromised
(No description given)
Is this okay? (y/N) y

You need a passphrase to unlock the secret key for
user: "John Doe <[email protected]>"
4096-bit RSA key, ID 144A027B, created 2013-11-04

Revocation certificate created.

Please move it to a medium which you can hide away; if Mallory gets
access to this certificate he can use it to make your key unusable.
It is smart to print this certificate and store it away, just in case
your media become unreadable.  But have some caution:  The print system of
your machine might store the data and make it available to others!
$ 

…and export our public key.

gpg -a --export [email protected] > public_key.gpg

We’ll be sharing the public key later, but the secret key and revocation certificate are important to keep secret and safe. Put the secret key in a locked safe and guard it with Orks, or hire “Earl” to stand outside with a shotgun. Whatever you have to do.

The revocation certificate is also important to keep safe because if your primary key is revoked, you will lose all the Web of Trust signatures you will hopefully be carefully collecting for years to come. However, it’s more important that your revocation certificate should be accessible to you in case anything should ever happen to your primary secret key. It might be a good idea to keep a copy of this at your parents’ house, and another in a safe deposit box at your bank.

Paper Copies

Besides electronic media like thumbdrives and CD-Rs, it might also be a good idea to consider the enduring qualities of good, acid-free paper.

We could simply print off the ASCII-armored keys we exported, or we could use David Shaw’s Paperkey* to remove some of the redundant information from our secret key before printing. Unfortunately, Paperkey is not included in the packages pre-installed to the Tails live operating system we’re using.

Lack of SmartCard Support in Tails

Speaking of things lacking from the version of Tails we’re using, I found that using my OpenPGP SmartCard + Shell Token almost worked out of the box… but not quite. Eventually, I opted to use a Live USB stick from another Debian-based distro, CrunchBang, to handle getting the subkeys loaded onto the card. Since we’ve already created a backup of our keyrings to removable media, we can take that with us to this other, (mostly) isolated environment.

I say “mostly” because in order to get the SmartCard working with CrunchBang, I still had to install two packages not included in the default live environment. I was careful to do this when none of my secrets were on the machine, but it still is not ideal.

It may be worth creating a LiveCD/LiveUSB Linux distro specifically aimed at the purpose of generating GnuPG keys and working with OpenPGP SmartCards in an air-gapped environment…

For reference, here are the Tails bugs:

Note: This was my experience at the time of writing, but many improvements to Tails have been made since then. I’ve heard reports from others following this guide that Tails now has good SmartCard support.

Removing the Primary Key

Even without a SmartCard, we can separate the primary key from these subkeys and gain some security. I’ve heard a set of subkeys like this referred to before as “laptop keys,” as in, keys you can keep on your laptop while the primary key secret remains safely locked away.

Unfortunately, the current process for removing the primary key (in both gpg 1.x.x and gpg 2.x.x) is non-obvious. For reference, we’re starting from a keychain that looks something like this:

$ gpg -k
/home/amnesia/.gnupg/pubring.gpg
--------------------------------
pub   4096R/144A027B 2013-11-04 [expires: 2016-11-03]
uid                  John Doe <[email protected]>
sub   3072R/E02EDE61 2013-11-04 [expires: 2014-05-03]
sub   3072R/A59563DA 2013-11-04 [expires: 2014-05-03]
sub   3072R/B2E31884 2013-11-04 [expires: 2014-05-03]

$ gpg -K
/home/amnesia/.gnupg/secring.gpg
--------------------------------
sec   4096R/144A027B 2013-11-04 [expires: 2016-11-03]
uid                  John Doe <[email protected]>
ssb   3072R/E02EDE61 2013-11-04
ssb   3072R/A59563DA 2013-11-04
ssb   3072R/B2E31884 2013-11-04

First we export just the subkey secrets:

$ gpg -a --export-secret-subkeys [email protected] > secret_subkeys.gpg

Then we delete the entire (both primary and subkeys) secret part of our key from our keyring:

$ gpg --delete-secret-keys [email protected]
gpg (GnuPG) 1.4.12; Copyright (C) 2012 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.


sec  4096R/144A027B 2013-11-04 John Doe <[email protected]>

Delete this key from the keyring? (y/N) y
This is a secret key! - really delete? (y/N) y
$

This leaves us with the public part in our ~/.gnupg/pubring.gpg:

$ gpg -k
/home/amnesia/.gnupg/pubring.gpg
--------------------------------
pub   4096R/144A027B 2013-11-04 [expires: 2016-11-03]
uid                  John Doe <[email protected]>
sub   3072R/E02EDE61 2013-11-04 [expires: 2014-05-03]
sub   3072R/A59563DA 2013-11-04 [expires: 2014-05-03]
sub   3072R/B2E31884 2013-11-04 [expires: 2014-05-03]

But nothing in our ~/.gnupg/secring.gpg:

$ gpg -K
$

Then we re-import just the subkeys we exported (not the full secret key from earlier):

$ gpg --import secret_subkeys.gpg
gpg: key 144A027B: secret key imported
gpg: key 144A027B: "John Doe <[email protected]>" not changed
gpg: Total number processed: 1
gpg:              unchanged: 1
gpg:       secret keys read: 1
gpg:   secret keys imported: 1
$

And we’re left with our “laptop keys”:

$ gpg -k
/home/amnesia/.gnupg/pubring.gpg
--------------------------------
pub   4096R/144A027B 2013-11-04 [expires: 2016-11-03]
uid                  John Doe <[email protected]>
sub   3072R/E02EDE61 2013-11-04 [expires: 2014-05-03]
sub   3072R/A59563DA 2013-11-04 [expires: 2014-05-03]
sub   3072R/B2E31884 2013-11-04 [expires: 2014-05-03]

$ gpg -K
/home/amnesia/.gnupg/secring.gpg
--------------------------------
sec#  4096R/144A027B 2013-11-04 [expires: 2016-11-03]
uid                  John Doe <[email protected]>
ssb   3072R/E02EDE61 2013-11-04
ssb   3072R/A59563DA 2013-11-04
ssb   3072R/B2E31884 2013-11-04

Notice the # after sec: this denotes that the primary key secret is not in our keyring.

If we were not going to use a SmartCard to store these keys, we can export them and transfer them to our latop via removable media (USB stick).

$ gpg -a --export-secret-keys [email protected] > laptop_keys_secret.gpg
$ gpg -a --export [email protected] > laptop_keys_public.gpg

And import them onto our laptop:

$ gpg --import laptop_keys_public.gpg
gpg: key 144A027B: public key "John Doe <[email protected]>" imported
gpg: Total number processed: 1
gpg:               imported: 1  (RSA: 1)
$ gpg --import laptop_keys_secret.gpg
gpg: key 144A027B: secret key imported
gpg: key 144A027B: "John Doe <[email protected]>" not changed
gpg: Total number processed: 1
gpg:              unchanged: 1
gpg:       secret keys read: 1
gpg:   secret keys imported: 1

If we wanted to make sure that even these subkeys couldn’t be read from our laptop if it were compromised, then we’d want to transfer them to a SmartCard instead. Stay tuned!


Read the rest of this series on GNU Privacy Guard:

  1. Getting Started with GNU Privacy Guard
  2. Generating More Secure GPG Keys: Rationale
  3. Generating More Secure GPG Keys: A Step-by-Step Guide (this post)
  4. Using a GPG Key with a SmartCard (coming 12/2013)
Conversation
  • Hauke Laging says:

    it’s theoretically feasible to use keys for any purpose

    That is not correct. It is technically impossible if the key type doesn’t match (e.g. DSA cannot encrypt). And GnuPG doesn’t allow you to encrypt for RSA keys which have the signing capability only.

    It makes sense to give signing and encryption capabilities to the mainkey if you do not have a separate high security key. A good key has a key policy which, of course, needs to be signed by the mainkey to make sense.

    While the 2.x.x branch of GnuPG supports transferring 4096-bit keys

    That is not correct. You need 2.0.18 or above.

    [mainkey] When you have the private key, you can always push an expiration date back, so let’s set this key to expire in 3 years. […] For reasons discussed in my Sure GPG Keys post, we’ll set these subkeys to expire relatively soon

    It doesn’t make much sense to use different expiration periods on mainkey and subkeys. You need the offline mainkey anyway when the subkeys expire. Changing the mainkey expiration date, too, is not an additional effort worth mentioning.

    but the secret key and revocation certificate are important to keep secret and safe

    Why should you create a revocation certificate if you have stored the secret mainkey secretly and safely? Because you might forget the passphrase?

    Not related to hardening keys but I would like to advertise this articly by me.

    • Mike English Mike English says:

      Hello Hauke,

      I recognize your name from the gnupg-users list. Thank you for taking the time to correct and clarify these points! I appreciate you sharing your expertise.

      It is technically impossible if the key type doesn’t match

      Thank you for this correction. I overstated the flexibility available to users in this regard.

      When it comes to RSA keys with signing and/or certification capabilities, my understanding is that GnuPG limits their use to the capabilities specified, but that if the source were patched, the ability to modify those capabilities could be added to the program. Sign and certify are effectively the same operation, but on different types of data, correct? Hence a ‘theoretical’ possibility. Is this correct, or am I still missing something?

      You need 2.0.18 or above.

      Again, thank you for clarifying. I should have said recent releases on the 2.x.x branch.

      Why should you create a revocation certificate if you have stored the secret mainkey secretly and safely? Because you might forget the passphrase?

      Not only might the passphrase be lost, but it’s also possible that the secret key could be stolen. If I believe that the secret mainkey has been compromised AND I have no access to it, I would want another means to revoke it as soon as possible. I’ve recently become aware of a way to assign other trusted persons the ability to revoke your key on your behalf. This may be another good solution for such a scenario (given that you know enough people regularly using GPG to make it practical to find someone you can trust with that responsibility).

      Regarding expiration, there’s a social/communication aspect I’m still a bit unclear on:
      If I expire my keys often, they quickly become cluttered on keyservers and seeing all of the expirations may startle newer users. I’ve been thinking that striking a balance by expiring and replacing the subkeys frequently, but setting a longer expiration on the mainkey might make the key’s appearance less confusing. Using a signed policy document may be a better way to convey how one intends to use a set of keys.

      Thinking about all of this has also raised another question for me:
      If I only use a set of subkeys on a SmartCard and consider them to be secure (stored only on the SmartCard and with my mainkey), then I may want to set short expirations on those keys, but update those expirations frequently rather than entirely replacing the keys. Does this make sense? Are there any reasons I would want to treat the encryprtion subkey differently?

      Thanks also for the link to the article about spreading awareness of OpenPGP. Through your OpenPGP Courses site, I also found a very good Concepts/Getting Started article that I wish I had encountered sooner. It covers many things I had learned on my own by digging through the gnupg-users mailing list archive and various other blog posts and forum discussions. In the future, I’ll direct more people to that wiki page.

      -Mike

  • Hauke Laging says:

    if the source were patched, the ability to modify those capabilities could be added to the program

    I guess it would even be possible to patch gpg in a way that it ignores the capabilities (if technically possible).

    Sign and certify are effectively the same operation, but on different types of data, correct?

    Yes. You could say that certifications are signatures which affect the OpenPGP infrastructure. The nomenclature isn’t consistent, though: “self-signature” not “self-certification”. OpenPGP nomenclature is evil anyway (“owner trust”, validity and their level names).

    If I believe that the secret mainkey has been compromised AND I have no access to it, I would want another means to revoke it as soon as possible.

    Sure but it still doesn’t make sense if you store the key and the revocation certificate together…

    If I expire my keys often, they quickly become cluttered on keyservers and seeing all of the expirations may startle newer users.

    But how do you (let alone new users) notice that? With –list-sigs? That’s what –import-options / –edit-key clean has been invented for.

    If I only use a set of subkeys on a SmartCard and consider them to be secure

    Keys on smartcards are not secure. They cannot be stolen but they can be abused. Quite easily the decryption keys and even signing keys with card readers without PIN pad.

    I may want to set short expirations on those keys, but update those expirations frequently rather than entirely replacing the keys. Does this make sense?

    I do not see such a relation between the validity period and the subkey replacement period. It would not make sense to have a shorter replacement period than expiration period, though.

    Are there any reasons I would want to treat the encryprtion subkey differently?

    There are legal arguments. There may be situations in which you are forced to give your secret key to the authorities (though from a technical perspective it would be enough to give them the session keys they need). I you change the encryption subkey frequently then they can decrypt less of your communication. Under the assumption that the courts restrict the authorities to certain periods. If they say “We need the keys which have been used sometime in the last five years” that doesn’t make a difference.

    I also found a very good Concepts/Getting Started article

    I wrote those articles because I was looking for one that explains the concepts without being closely bound to a certain software. gpg shell code (and worse: output!) in between doesn’t make a text more readable. It’s funny to see which languages they were translated to (and to which not). The original must be written in English. I obviously translated my English text in German then. And the Danish translation has been made because one of the main translators there whom I was in contact with is from Denmark. But the other languages seem to have some political message…

  • Tehmasp Chaudhri says:

    Good stuff dude! Thanks.

  • Blake Mortensen says:

    I have an expiring key and I’ve edited the key and exported a new ascii file containing the public key. I’m getting reports from some of those I’ve shared the file with that listing the key does not show the new expiration date. They’ve tried deleting the key and re-adding and still shows the same expiration. I’ve practiced this on multiple servers in my own realm and not seeing the results they are. Any hints?

  • dadoug says:

    Here’s a script to facilitate this process: https://github.com/dadoug/gneasy-genkey

    • Mike English Mike English says:

      Neat script, dadoug!
      I like that it includes touches like QR code generation and expiration reminders.

      Thanks for sharing!

  • John says:

    Hi,

    This part: “(Repeat this addkey process for the Encryption and Authentication subkeys)”

    Is not clear what I need to choose for those keys:

    (S) Toggle the sign capability
    (E) Toggle the encrypt capability
    (A) Toggle the authenticate capability

    • Mike English Mike English says:

      Hi John,

      I see below that you were able to figure this out, but for the benefit of others (and because someone else e-mailed me with a similar question), I’ll elaborate here.

      The menu for selecting subkey capaibilities is somewhat confusing. Selecting e, s, or a from the menu _toggles_ each respective option. When adding subkeys, watch what’s listed after “Current allowed actions:” to make sure it matches what you want for that subkey.

      So, for example, if “Current allowed actions:” lists “Sign Encrypt”, and we want our subkey to only be used for Encryption, we’d press “s”, and then see only “Encrypt” listed.

      Or if we started from “Sign Encrypt” and we wanted a key to be used only for Authentication, we’d press ‘a’ (see “Sign Encrypt Authenticate”), then ‘s’ (“Encrypt Authenticate”), then ‘e’ to get just the “Authenticate” capability enabled for that subkey.

      Hope that helps!
      -Mike

  • John says:

    Thank you for you tutorial, I figure out how to setup the capabilities.

  • Peter says:

    Hi Mike,

    How to sign someone else’s key or add an uid without the master private key ?

    • Mike English Mike English says:

      Hi Peter,

      Neither of these actions are possible without the master private key.
      This means that I am not able to immediately sign keys, change my key expirations or uids, etc. while away from my master private key. I tend to do these activities in batches to make getting the key out (in an air-gapped environment) and exporting the signed public material worthwhile.

      -Mike

  • Ruud says:

    “Not enough random bytes available. Please do some other work to give
    the OS a chance to collect more entropy! (Need 282 more bytes)”

    I’m getting to this point and then, notting.. what ever i do, moving the mouse, typing something,.. nothing..
    Do you have any tips Mike?

    • joe says:

      If this is on a server – you might need to install rngd-tools if you have /dev/hw_random or similar hardware device – otherwise installed haveged.

      These tools are meant to increase the entropy of /dev/random.

  • Following the steps, we end up with multiple files like this:
    a. secret_key
    b. public_key.gpg
    c. secret_subkeys.gpg
    d. laptop_keys_secret.gpg
    e. laptop_keys_public.gpg

    Two clarifications:
    1. Isn’t the “public_key.gpg” the same as the “laptop_keys_public.gpg”?
    — Since we did not touch the pubkey (no keysigning or anything), it should be the same, correct? Or did some part changed after we removed the master_privkey?

    2. Isn’t the re-imported “secret_subkeys.gpg” the same as the “laptop_keys_secret.gpg”?
    — Since the secret_subkeys were re-imported and nothing else was changed before it was re-exported as “laptop_keys_secret.gpg”, then it should be the same, right? Or there was also a change made after it was re-imported, thus the need to re-export it?

    Thank you.

  • Comments are closed.