116

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.

Community
  • 1
Iszi
  • 27,027
  • 18
  • 99
  • 163

6 Answers6

77

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.

nealmcb
  • 20,693
  • 6
  • 71
  • 117
  • 2
    Yup, that's one good reason. Another reason is that re-using the same keypair for both purposes is **potentially insecure**. – D.W. Mar 09 '11 at 05: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 09: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 00:24
  • @nealmcb - I wouldn't have any objection at all. – user93353 Feb 27 '14 at 23:50
  • 1
    @user93353 Is there something about your earlier comment on symmetric vs public keys that I'm missing then? – nealmcb Feb 28 '14 at 00:56
  • 1
    @nealmcb - Your answer says you shouldn't use the same key pair for encryption and signing. In PKI, you use your private key for signing & you use a public key for encryption. So what exactly is the problem with using the same key pair for encryption & signing? – user93353 Feb 28 '14 at 01:46
  • @nealmcb and if the workplace wants to escrow your public key - so what? I don't get your answer at all. – user93353 Feb 28 '14 at 01:46
  • 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
  • 11
    @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 03 '14 at 16:21
  • @nealmcb, Re "want to roll it over sooner"; why? Why not use one with more permanence? – Pacerier Jan 31 '18 at 15:08
  • 1
    @pacerier The longer an encryption key lives, the more chance there is of compromise, and the more content that it encrypts, the more problems a compromise causes. So frequent rollover has many benefits. So schemes exist to allow people to just need to trust one, very well-protected, root key, which in turn is used to identify more ephemeral encryption keys as being authentic. – nealmcb Feb 22 '18 at 05:06
  • @nealmcb This is **misleading** : `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`. Signed documents are most often timestamped by a Trusted Timestamp Authority (TSA), and a signed & timestamped document will be valid if it was signed within the validity period of the certificate. Then it doesn't matted if the signing key is valid for eg. only 72hours, as long as the document was signed & timestamped within these 72 hours, it is valid. – Ludovic C Apr 13 '21 at 19:58
  • @LudovicC Can you give some examples? Note that the question started with PGP. In my experience with signatures (PGP, signatures on software packages), use of TSAs is rare and adds complication, since the relying party then needs to validate the TSA also, and there are so many TSAs which vary widely in what validation would even entail. – nealmcb Apr 16 '21 at 15:12
37

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.

D.W.
  • 98,860
  • 33
  • 271
  • 588
  • 21
    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 09 '11 at 09:20
  • 24
    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 06: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 07: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 07:39
  • 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
17

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 our CA to revoke it and get new secret key for signing without need of backup.

  2. More importantly: 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 would 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).

Michael
  • 2,432
  • 2
  • 20
  • 37
Am1rr3zA
  • 3,083
  • 4
  • 18
  • 14
  • 2
    This seems specific to RSA, rather than applicable to all asymmetric ciphers. – yfeldblum Jan 23 '11 at 03:15
  • 3
    Also, why would the attacker have access to N and such? – AviD Mar 09 '11 at 09:22
  • 4
    @Avid Attacker by default have access to N, because when you want publish your public key you must publish (N, e). – Am1rr3zA Mar 09 '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
  • The GDC(N, r) = 1 requirement is not highly important. Should the attacker by chance pick an r for which this is not the case, he broke the encryption anyway. – kasperd Aug 30 '14 at 18:15
  • @kasperd "he broke the encryption anyway" only in the two-prime case. In principle the modulus could contain two large factors and a bunch of small ones. While that's generally not the case for normal RSA keys, malicious key generation is a concern in blind signature schemes. – CodesInChaos Aug 30 '14 at 18:24
  • @CodesInChaos That's interesting. I haven't tried doing the calculations to see if information would be leaked if N has more than two prime factors. – kasperd Aug 30 '14 at 18:52
  • @kasperd You leak information if you don't ensure that the (padded) message doesn't divide the modulus. This can be an issue if the modulus has a lot of small factors. – CodesInChaos Aug 30 '14 at 19:55
  • 2
    Some sources/links would be great here.. – alfonx Nov 11 '15 at 21:09
8

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/resources/certificate-solutions/learn/what-is-pki

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

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

schroeder
  • 125,553
  • 55
  • 289
  • 326
moo
  • 181
  • 1
  • 2
  • 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
6

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.

David Bakker
  • 61
  • 1
  • 1
5

RSA encryption is based on a trapdoor function, which is to say a pair of functions. I'll call them D and E. The functions are designed so that D(E(x)) = x and E(D(x)) = x (for any x). In other words, D and E are inverses. What makes it a trapdoor function is that if you have a public key, you can only compute E (practically speaking). If you have a private key, you can compute both D and E.

The way that encryption works is pretty obvious from that description. If Bob wants to send Alice an encrypted message, he computes ciphertext := E(plaintext). Then Bob sends ciphertext to Alice. Alice computes D(ciphertext), which is D(E(plaintext)), which is just plaintext.

Now, let's talk about how signing works. If Alice wants wants to sign message, then she computes signature := D(message). She then sends both message and signature to Bob. Bob then computes validation := E(signature). Since signature is D(message), then validation = E(D(message)) = message.

In other words: to sign a message, you act as if you're decrypting it, and that's your signature. To verify your signature, people can encrypt the signature and make sure they get back your original message.

I'll say that again: signing is the same operation as decryption.

This is the fundamental concern about separating signature and encryption keys. If somebody can get you to sign something, then they've just gotten you to decrypt it.

Suppose you're running a notary company. If somebody gives you $10 and a message (for instance, song lyrics), then you'll sign that message and send it back to you. If somebody later copies your song lyrics, you can produce the signature from the trusted notary company to demonstrate that you wrote those song lyrics.

Now suppose that Eve intercepted an encrypted message to your notary company. How can she subvert the encryption? She sends that same message to you for notarization! Now you run the signature operation (which, remember, is the same as the decryption operation), and send the result back to her. She now has the decrypted message.

In practice, protocols have steps that make this attack more difficult. For instance, PGP (by which I mean the protocol; gpg is the most common implementation here) doesn't sign the original message; it signs a hash of the message. But security proofs are best in simple situations. You don't want your proof about RSA's security to depend on the hash function. (For instance, many people used MD5 as the preferred hash for a long time, but today MD5 is considered quite broken.) Alone, RSA's security depends on the idea that you will not sign arbitrary messages with a key that's being used for encryption. Keeping that requirement in place is the best way to ensure PGP's security. (As I recall, this is the most frequently-repeated admonition about asymmetric encryption in Bruce Scheier's book Applied Cryptography.)

Now, let's talk about another question you asked: "Would this not also mean you need to distribute two public keys to everyone with whom you wish to communicate?"

A "key" means one thing to users, and a different thing to the crypto implementations. You only need to communicate one user-level "key", although that may contain many RSA public keys.

PGP has a concept of subkeys. My master key is a signing-only key. I have a separate encryption subkey. That subkey is signed by my master key. If you import my PGP key from the keyservers, or download it from my website, then you'll get my master key and all my subkeys. Even though you may have signed only my master key, my master key has signed my encryption subkey, so you know that it belongs to me too. That means that by downloading my PGP key (which encompasses many RSA public keys), you now have everything you need to both verify my signatures and to encrypt messages to me.

With subkeys, key management is more complex from a cryptographic standpoint (there's an extra key verification step to go through), but not from a practical standpoint (my PGP key includes my master key, as well as all my subkeys). The extra complexity is hidden in the implementation, and isn't exposed to the user.

Piquan
  • 151
  • 1
  • 1