Using the same RSA keypair to sign and encrypt

Question

The RSA signature operation is basically the same as encrypting with the private key. In particular, both operations use the same kind of keys.

Is it safe to use the same RSA keypair both for encryption / decryption and for signing / verification?

Answer 1

The short answer is no. This is a general piece of wisdom in cryptography: never use the same key for more than one thing. A “thing” means a specific scheme where all the parameters are fixed apart from the key itself and the message size. Don't use the same key to encrypt and sign; don't use the same key with both PKCS#1v1.5 and PSS; don't use the same key with different hash functions.

If you use the raw RSA operation ($M^d \bmod n$ or $M^e \bmod n$), then no, it is unsafe to use the same key, because an attacker could trick the private key holder into signing a message $M$ (i.e. generating $M^d$) which is actually an encrypted message ($M = P^e$), thus allowing the attacker to recover the original plaintext ($(P^e)^d = P$). (The dual attack leads to a forgery.) However, the raw RSA operation has a whole range of other flaws that make it unsafe as an encryption or signature scheme.

Encryption and signature schemes based on RSA use padding modes. The standard padding modes include discriminants so that an encryption payload does not look like a signature payload. Therefore, it is technically safe, cryptographically speaking, to use the same RSA key pair for signature and encryption, provided that the key pair is used safely for signature and used safely for encryption. Here, I mean safe in a narrow sense, assuming a “perfect” world where everything that should stay secret, remains secret.

The thing is, the world is not perfect. Implementations of RSA can leak partial information through side channels. Keys get compromised. Protocols using RSA sometimes use it in ways that are very brittle.

Using the same key for both encryption and signature can exacerbates weaknesses. RSA has a history of weaknesses, not in the mathematical algorithm itself (once you use proper padding), but in the way it's implemented. Decryption, especially, requires a lot of care, because some inputs are invalid, and the mere act of revealing whether an input is valid or not can allow oracle attacks, the best known of which is due to Bleichenbacher. The way RSA decryption is used in TLS¹ exacerbates this because it creates a second reason for invalidity: a ciphertext can be invalid for the decryption operation, or can be valid for decryption but decrypt to something invalid. This has led to a long series of practical attacks against TLS cipher suites that use RSA decryption. Using the same key for both encryption and signature has two downsides. Most obviously, if a vulnerability in decryption allows the attacker to recover the key, then anything that relies on a signature is also broken. Less obviously, even if the attacker can't recover the key, but can get some partial information about the decryption of invalid ciphertexts, they may be able to forge signatures. This is the case, for example, with the CAT variant of Bleichenbacher's attack, so that even clients that do not accept RSA decryption ciphersuites are still at risk if the server uses the same key for RSA signature ciphersuites.

Another reason is key management. Signature keys and encryption keys have different requirements in terms of backups, access control, repudiation, etc. The fallback for a signature key in case of a catastrophic event is to destroy it to avoid future forgeries, so a signature key does not need to be backed up extensively. Conversely, the fallback for an encryption key is to keep it around to decrypt existing documents, so it needs to be backed up reliably. In case of a leak of a signature key, pre-existing documents are not affected; it is only newly produced signatures that must be repudiated. Conversely, in case of a leak of an encryption key, the confidentiality of all pre-existing documents is at risk, whereas new documents simply need to be encrypted with different keys. The constraints push in different directions, so the keys need to be managed differently, they need to be different.

¹ _{That is, ciphersuites whose name starts with TLS_RSA_. Ciphersuites whose name starts with TLS_(EC)DH(E)_RSA use RSA signature, not RSA decryption, and are a lot more robust.}

Answer 2

Short Answer: NO, it is not safe, do NOT do this.

Longer Answer: You are true that you can use your RSA keypair for both operations. This approach is used in many applications and scenarios. There are Web Services or Single Sign-On implementations, which enforce you to use the same key pair for both operations. X.509 certificates do not allow you (by default) to determine, if a given RSA key must be used for encryption/decryption or for signing/verification. It is possible to enforce this only with specific extensions or certificate fields, which are not mandatory...

However, in cryptography it is in general a very bad practice to use the same key for two operations. For example, if one of the operations gets compromized, it can break security properties of the other operations where the same key is used.

There is one practical example in the RSA key setting. Imagine a server which decrypts ciphertexts and signs messages with an RSA key. Imagine this server is vulnerable to a specific chosen-ciphertext attack (Bleichenbacher's attack), which allows an adversary to decrypt arbitrary ciphertexts without knowing server's private key. If the server uses the same RSA key pair for encryption/decryption and signing/verification, using this attack the adversary is also able to create arbitrary server signatures. This would not be possible if the server would use distinct RSA key pairs for these operations.

Please see our paper for more details: http://www.nds.ruhr-uni-bochum.de/research/publications/backwards-compatibility/ Section 4 discusses the problem of key reuse in public key setting. Section 5.3 shows practical examples of these attacks and their impact. Sections 5.4 and 5.5 discuss countermeasures and their application by different vendors.