arrow3 Comments
  1. Hauke Laging
    Nov 24 - 6:32 pm

    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
      Nov 25 - 11:10 am

      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

  2. Hauke Laging
    Nov 25 - 8:02 pm

    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…

Mobile Theme