Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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.

share|improve this question

4 Answers 4

up vote 27 down vote accepted

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.

share|improve this answer
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
"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
@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
@nealmcb - I wouldn't have any objection at all. –  user93353 Feb 27 '14 at 23:50
@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.

share|improve this answer
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
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
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
@AviD, I don't know. Could be. I don't know whether there are any known attacks. That would take a careful literature search, which I have not done. Even if the answer is "none known", I wouldn't rely upon it. When every cryptographer knows that's a bad way to design systems,that it violates the use conditions on proper use of a cryptosystem, I don't know if cryptanalysts are going to spend their time looking for practical attacks of this form, and even if you found attacks, I don't know if they would be publishable. Bottom line: Using a key for both purposes is not recommended. –  D.W. Mar 13 '11 at 7:39
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

We have some reason that we should not use same key for encryption and signing.

1- We need to backup our secret key for encrypted data, maybe later we want to decrypt some old encrypted message but we don't need to backup out secret key for signing. if attacker find the key we can tell CA and put it in expired key and get new secret key for signing without need of backup.

2- The second reason is more important, if we use same key for encryption and signing attacker can use this for decrypt our encrypted message, this is what he should do:
Attacker must choose random number r (r must have GDC(N, r) = 1, N is the number use for creating private and public key (N = p*q)) then he chooses new message m′ = m^e.r^e ((e,n) is public key) and send this message (m′) for signing to sender, when sender sign m′ we get m′^d ≡ (m^e.r^e)^d ≡ m.r (mod N) then we just to multiply it to r^-1 to get m (secret message).

share|improve this answer
This seems specific to RSA, rather than applicable to all asymmetric ciphers. –  yfeldblum Jan 23 '11 at 3:15
Also, why would the attacker have access to N and such? –  AviD Mar 9 '11 at 9:22
@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
"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
@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.
share|improve this answer

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.