current community

your communities

more stack exchange communities

company blog
Stack Exchange Inbox Reputation and Badges
tour help
Information Security Stack Exchange is a question and answer site for information security professionals. It's 100% free, no registration required.

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
up vote 62 down vote favorite
26

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
up vote 38 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
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
1  
"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
1  
@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
5  
@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
up vote 21 down vote

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
7  
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
19  
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
1  
@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
1  
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
up vote 8 down vote

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
1  
Also, why would the attacker have access to N and such? – AviD♦ Mar 9 '11 at 9:22
1  
@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
5  
"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
up vote 3 down vote

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.

share|improve this answer
up vote 2 down vote

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.

References

  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

share|improve this answer
    
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

Your Answer

 
discard

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.