31

When encrypting a file to send to a collaborator, I see this message:

gpg: using subkey XXXX instead of primary key YYYY

Why would that be? I've noticed that when they send me an encrypted file, it also appears to be encrypted towards my subkey instead of my primary key. For me, this doesn't appear to be a problem; gpg (1.4.x, macosx) just handles it & moves on. But for them, with their automated tool setup, this seems to be an issue, and they've requested that I be sure to use their primary key.

I've tried to do some reading, and I have the Michael Lucas's "GPG & PGP" book on order, but I'm not seeing why there's this distinction. I have read that the key used for signing and the key used for encryption would be different, but I assumed that was about public vs private keys at first.

In case it was a trust/validation issue, I went through the process of comparing fingerprints and verifying, yes, I trust this key. While I was doing that, I noticed the primary & subkeys had different "usage" notes:

primary:  usage: SCA
subkey:   usage: E

"E" seems likely to mean "Encryption". But, I haven't been able to find any documentation on this. Moreover, my collaborator has been using these tools & techniques for some years now, so why would this only be a problem for me?

43
+50

Update

While the original post below correctly explains why you might want to use separate encryption and signing keys, it does not do a great job answering the question of why you use subkeys instead of the primary key. The Debian Wiki provides a much more thorough answer.

To summarize, your primary key is your online identity, and your identity and reputation are built up by having other people vouch for that key being yours by signing it themselves. (You might think of it like being your Twitter handle, and your reputation being your Twitter followers, or you might object to that analogy, but I hope it gives you some sense of why you want to protect it.) So, since your primary key is super important and is built up over years, you want to protect it very much. In particular, you do not want to store it on a computer that might get stolen or hacked into; you want to keep your primary key off-line in a safe place.

This, of course, makes your primary key very inconvenient to use. So for day-to-day operations you want to use a key that is not such a big problem to replace if it gets compromised. This is why subkeys were invented.

A subkey is still a public/private key pair and is secure as long as only you have the private key. It is, cryptographically, just as secure as your primary key. The difference is that your reputation is only attached to it by your own signature, the signature from your private key. To use the Twitter analogy, the world trusts that you are your Twitter handle because all your followers say so (I know, it doesn't always really work that way, but analogies are hard!), and then with that trust established you can then much more easily convince the world you own your Instagram handle by just tweeting it and people will believe you because the tweet came from your account, which they trust.

You still want to keep your subkey safe, but now if it is compromised it is not the huge problem it would be if your primary key were compromised (or, in the analogy, someone hijacked your Twitter account). Now you can just revoke the subkey and issue a new one by signing a revocation certificate and a new subkey and posting them both on your public keyring (like tweeting "hey, my Instagram handle changed, don't use the old one, use this one instead"). This makes keeping your subkey on your laptop computer a more acceptable risk than keeping your primary key on it.

TL;DR Subkeys make key management much easier by separating the cryptographic functions of public keys from the trust and identity functions of (primary) public keys.


Original post

If you look into the details of the math of public-key encryption, you will discover that signing and decrypting are actually identical operations. Thus in a naïve implementation it is possible to trick somebody into decrypting a message by asking them to sign it.

Several things are done in practice to guard against this. The most obvious is that you never sign an actual message, instead you sign a secure hash of the message. Less obviously, but just to be extra safe, you use different keys for signing and encrypting. Also, keeping the encryption key separate allows you to keep the other arguably more important and definitely less frequently used keys off-line and more secure. That is the case with the keys you have inspected. By the way the flags mean:

  • e = encrypt/decrypt (decrypt a message you received encrypted for you to read)
  • s = sign (sign data. For example a file or to send signed e-mail)
  • c = certify (sign another key, establishing a trust-relation)
  • a = authentication (log in to SSH with a PGP key; this is relatively new usage)

Note that in all cases, "key", means a public & private key pair.

This should not be a problem for your friend if he has everything set up correctly, but setting up everything correctly can be more complex than it should be. So it may be that the best solution is for your friend to generate a new public-key that he uses for both signing and encrypting. Like I said, because the primary defense against attack is to only sign a cryptographically secure hash of a message, it is not a serious weakness to have such a key.

  • 2
    To make long story short: one should never ever encrypt and sign using the same key otherwise bad things will happen (c) – SaveTheRbtz Jun 21 '12 at 9:12
  • Thanks for confirming what I'd thought. I still want to know why this is going on, since the collaborator is telling me that this system has been working for them, and I've learned (via reading & gpg-users mailing list) that it's 99.99% likely that my personal key is irrelevant since I didn't sign that message. But you have answered my questions, so thank you! – Michael H. Jun 21 '12 at 19:50
  • 1
    Does it make sense to keep the master key (signing and encryption subkeys) offline, and generate subkeys (signing and encryption) for each computing device you use? A lot of the tutorials that deal with this only separate the signing keys, but leave the encryption key in the daily drivers. – CMCDragonkai May 3 '18 at 2:25
2

Reference for the flags

Alternate reference

Beyond that, I'm not likely to be much help. I've always found PGP/GPG to be overly complex for what little it accomplishes. Good luck.

  • 6
    Answers that contain only links are frowned on here because links die over time. We prefer at least a relevant extract to go along with the link. – John Gardeniers Jun 15 '12 at 5:32
  • That's a start; considering .. – Michael H. Jun 15 '12 at 5:43
  • 1
    @JohnGardeniers That seems sensible. I had considered just leaving the info as a comment, but the rules regarding reputation on SE sites with respect to the fact that I can submit answers before I can submit comments were confusing. For posterity's sake: E: Encryption S: Signing C: Creation of Certificates A: Authentication (with multiple edits because of my fat fingers) – user124776 Jun 17 '12 at 3:02
  • Lovely, somebody beat me to it. – user124776 Jun 17 '12 at 3:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.