In an answer to a question about RSA and PGP, PulpSpy noted this:

It is possible to generate an RSA key pair using GPG (for both encryption and signing -- you should not use the same key for both).

What is the reasoning behind this?

Perhaps my understanding of public key encryption is flawed, but I thought the operations went something akin to this:

  • When Bob wants to encrypt a message to Alice, he uses Alice's public key for the encryption. Alice then uses her private key to decrypt the message.
  • When Alice wants to digitally sign a message to Bob, she uses her private key to sign it. Bob then uses Alice's public key to verify the signature.

Why is it important to use different keys for encryption and signing? Would this not also mean you need to distribute two public keys to everyone with whom you wish to communicate? I imagine this could easily lead to some amount of confusion and misuse of keys.


It is mostly that the management approaches and timeframes differ for the use of signing and encryption keys.

For non-repudiation, you never want someone else to get control to your signing key since they could impersonate you. But your workplace may want to escrow your encryption key so that others who need to can get to the information you've encrypted.

You also may want a signing key to be valid for a long time so people around the world can check signatures from the past, but with an encryption key, you often want to roll it over sooner, and be able to revoke old ones without as many hassles.

  • 1
    Yup, that's one good reason. Another reason is that re-using the same keypair for both purposes is potentially insecure. – D.W. Mar 9 '11 at 5:37
  • 2
    "But your workplace may want to escrow your encryption key so that others who need to can get to the information you've encrypted." - this may be relevant for symmetric keys but not for PKI. – user93353 Feb 17 '14 at 9:40
  • 2
    @user93353 If a public key is only used for encryption, what would your objection to escrowing it in a workplace setting be? – nealmcb Feb 27 '14 at 0:24
  • 3
    @user93353 If your workplace escrows a signing key, then they can impersonate you, sign statements on your behalf, get you in trouble, etc. I've never heard of a good use case for that. So your signing key pair should be yours alone. If there is a need for escrow of an encryption keypair (to provide access to data created by you but owned by your workplace, e.g.) it should be a separate keypair. – nealmcb Feb 28 '14 at 16:22
  • 9
    @user93353 Workplaces often escrow your private encryption key. That way, when they fire you, you get hit by a bus, or you abscond with the boss's daughter, they still have access to your files. Any employer that allows encrypting work product with a key they don't hold in escrow is asking for trouble. – erickson Oct 3 '14 at 16:21

It is potentially insecure to use the same keypair for both signing and encryption. Doing so may enable attacks, depending on the particular public-key scheme you use. This kind of use is not what the system was designed for, so using the system in a way it was not designed "voids the warranty".

Don't do it. It's asking for trouble.

  • 18
    Can you provide some details? What kind of attacks break this usage? (Though I agree regardless about the system not being designed for this usage...) – AviD Mar 9 '11 at 9:20
  • 21
    Sure. In a poorly designed system, if you can ask for the decryption of any ciphertext C you want and get back the corresponding Decrypt(C), you may be able to forge a signature on the message M by letting C = Hash(M) and then asking for Decrypt(C). Modern systems aren't vulnerable to that particular attack, but it's difficult to know whether there may be more sophisticated versions of this kind of attack on any particular system. If you reuse a key for both encryption and signing, it typically invalidates any proofs of security or other vetting that's been done. – D.W. Mar 11 '11 at 6:39
  • 1
    I see. That makes sense, thanks! But I understand that currently, there are no known practical attacks? (Other than bad practice, and more importantly lack of assurance) – AviD Mar 11 '11 at 7:46
  • 3
    There may be practical attacks, depending on where (else) the keys are used. As DW says all you need is to be able to get any C decrypted for you - that could be possible in authentication handshakes where random nonces are used, for example. While it is probably possible to design that out of the authentication protocol, it's easier and safer to simply make it impossible by not using keys for multiple purposes in the first place. – frankodwyer Apr 19 '11 at 12:46
  • 2
    I agree that it's a bad idea. Nevertheless, S/MIME seems to provide both (encryption and signing) with a single key/certificate pair, if I'm not mistaken. – lxgr Jul 19 '13 at 13:00

There are some reasons that we should not use the same key for encryption and signing.

1- We need to backup our secret key for encrypted data, later we want to decrypt some old encrypted messages but we don't need to backup our secret key for signing. If attacker finds the key we can tell CA and make it as expired key and get new secret key for signing without need of backup.

2- The second reason is more important. If we use the same key for encryption and signing, the attacker can use this to decrypt our encrypted message, this is what he/she should do:

The attacker must choose a random number r, where

      r must have GDC(N, r) = 1,
      and N is the number used for creating private and public key (N = pq)

Then the attacker chooses a new message (m′) and sends this for signing to the sender:

      m′ = m^e.r^e ....(here (e,n) is the public key)

When the sender signs m′ we get

      m′^d ≡ (m^e.r^e)^d ≡ m.r (mod N)

Now the attacker only needs to "divide" it by r to get m (the secret message).

  • 2
    This seems specific to RSA, rather than applicable to all asymmetric ciphers. – yfeldblum Jan 23 '11 at 3:15
  • 3
    Also, why would the attacker have access to N and such? – AviD Mar 9 '11 at 9:22
  • 3
    @Avid Attacker by default have access to N, because when you want publish your public key you must publish (N, e). – Am1rr3zA Mar 9 '11 at 10:48
  • 8
    "when sender sign m′ we get m′^d" Why? To sign something with RSA, you don't simply apply the private key operation to it. You hash it and you apply padding. So your attack doesn't work. (There are exceptions, using a key for blind signing and encryption would be open to that attack, but blind signing is a special application, and not normal signing). – CodesInChaos May 13 '12 at 21:51
  • 2
    @CodesInChaos The description of the risk with using the same key for both signing and encryption is overly simplified. But in the field of security a simplified example of why something could be a problem should be taken serious. On the other hand you want rigorous proofs, before something is considered secure. If all you have is hand-waving arguments for and against the security of a practice, one need to err on the side of caution. – kasperd Aug 30 '14 at 18:13

Reasons for using separate keys for signing and encryption:

  1. Useful in organization were encryption key needs to be backed or kept in escrow in order to decrypt data once an employee/user of the organization is no longer available. Unlike the encryption key the signing key must never be used by anyone other then the employee/user and does not and should not need to be kept in escrow.
  2. Allows having different expiration times for signing an encryption keys.
  3. Given that the underlying mathematics is the same for encryption and signing, only in reverse, if an attacker can convince/trick a key holder to sign an unformatted encrypted message using the same key then the attacker gets the original.


  1. https://www.entrust.com/what-is-pki/

  2. https://www.gnupg.org/gph/en/manual/c235.html

  3. http://www.di-mgt.com.au/rsa_alg.html

  • Any links/source for 3 available please... – alfonx Nov 11 '15 at 21:10
  • @alfonx I may have forgotten the original links I got those points from but I have edited in references in order. I hope that helps. Not sure if all of those are the most reliable references but the points make sense if you have worked PKI. – moo Dec 7 '15 at 20:59
  • 1
    @moo point 3 is only a good remark on the asymmetric RSA key concept. However the attack doesn't exist in real world documents signing practice (like PGP which this question is considering). This is because PGP only sign a message digest (aka a secure hash) of the original message, instead of applying the private key on the whole message. – Johnny Wong Jul 21 '17 at 23:45
  • @JohnnyWong agreed that a real world attack using this concept would depend on the implementation. The OP did mention GPG/PGP as an example, however it seems to me that the OP wanted a more general reasoning for this practice. Given that implementations change often enough I think this point is very important to be understood for anyone dealing with PKI and I am choosing to not remove point 3. Perhaps I could have put a note about this but I think that our comments now serve that purpose. Thanks. – moo Jul 27 '17 at 18:56

To me, the main reasons are related to key management, rather than cryptographic security per se.

For asymmetric crypto, especially the period during which you want a public key to be valid may strongly depend on the intended use of that key. For example, consider a system in which a component must authenticate itself towards other components. Next to that, that component must also regularly create a signature over some data. In theory, a single private key could be used for both purposes. However, suppose the PKI Certificate Authority for security reasons wants to limit the period during which successful authentication can take place based on a single certificate to two years. At the same time, data retention laws may require that data is kept for five years, and that the signature over that data must be verifiable during that entire period. The only (sound) way to solve this problem is to give the component two private keys: one for authentication and one for signing. The certificate of the first key will expire after two years, the certificate for signing will expire after five years.

Similar reasonings can be applied to symmetric cryptography: if you use different keys for different purposes, you can decide upon all questions of key management (e.g. the frequency of the master key roll-over, the period to back up keys, etc.) based upon the requirements of a single purpose. If you use a single (master) key for a multiple purposes, you may end up with conflicting requirements.

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.