Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question
up vote 16 down vote accepted

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.

share|improve this answer
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! – khedron Jun 21 '12 at 19:50

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.

share|improve this answer
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 .. – khedron Jun 15 '12 at 5:43
@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 posting your answer, you agree to the privacy policy and terms of service.

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