0

Talking about cipher-suites that use RSA both for sign of DH parameters and for digital signature. The keys used for these process are the same, or is there a public and private key for each one?

If the keys are different, explain a scenario that could be dangerous to use the same key for encryption and signature.

What advantages a hacker could gain if the keys was the same?

Is there some situation where using the same key is good?

Why are they different?

Johnny Willer
  • 409
  • 1
  • 4
  • 13
  • possible duplicate of [Digital Certificate deployment: using two certs for each user?](http://security.stackexchange.com/questions/8559/digital-certificate-deployment-using-two-certs-for-each-user) – RoraΖ Sep 24 '15 at 14:08
  • 1
    _Are there_ any cipher suites that use RSA "for encryption of DH parameters"? ​ –  Sep 24 '15 at 14:09

1 Answers1

4

I suppose that you are talking about SSL. A SSL server supports several combinations of cryptographic algorithms called cipher suites. In particular, a given SSL server may support either or both of these key exchange mechanisms:

  • RSA: the server has a RSA private key; the client generates a random value (the "pre-master secret") and encrypts it with the server's RSA public key; the server decrypts the received value to get the pre-master secret.

  • DHE_RSA: the server has a RSA private key; the server generates a new random Diffie-Hellman key pair, signs the public part with its RSA private key, and sends that to the client; the client verifies the RSA signature (using the server's RSA public key) and completes the DH key exchange. (Variant: ECDHE_RSA: same principle, but the DH is done over an elliptic curve.)

So indeed, a given SSL server may potentially use the same RSA private key for both encryption (when using a RSA key exchange) and signatures (when doing a DHE_RSA key exchange). Note that the server may perfectly well have two RSA keys, one dedicated to encryption (RSA key exchange) and one for signatures (DHE_RSA key exchange); people just do not do that on a regular basis because having two distinct keys implies buying two distinct certificates.

In all generality, the same key should not be used for both encryption and signatures. Note that a big source of confusion is that RSA encryption and RSA signatures are two distinct algorithms, that just happen to use private keys that have the same format, and people found it smart to call both of them "RSA".

The two main reasons for not using the same private key for both encryption and signatures are the following:

  • Interactions between the encryption and the signature algorithm are not well-studied. There could exist some method that leverages encryption to forge signatures, or signatures to perform an underhanded decryption. In the specific case of a SSL server, it is usually believed that there is no such interaction, notably because when the server decrypts, it does not advertise the result back to the client, and also because when the server signs, it does so over a DH public key that the server generated itself, not over data sent by the client.

  • Normally, encryption keys and signature keys call for distinct life cycles; encryption keys should be escrowed, and signature keys must not be escrowed (see this for some discussion on the subject). Again, in the specific case of a SSL server, you do not need to escrow the RSA private key because the encryption is transient (data is decrypted when it arrives, not stored), so it is possible to manage the server's private key in a way which is fine both for an encryption key and a signature key.

Community
  • 1
Tom Leek
  • 168,808
  • 28
  • 337
  • 475
  • Thank you for the reply, some few question came to me, is DHE key pair sent in plaintext during handshake? I mean, sent not encrypted but only with a signature to confirm the issuer. Is there some type of chiper suite that uses RSA key exchange and RSA signature, for autentication? – Johnny Willer Sep 24 '15 at 17:14
  • 1
    The _public part_ of the ephemeral DH key pair is sent without encryption (this is a logical necessity: the point of DH is to establish a shared secret that will be used to encrypt the data). – Tom Leek Sep 24 '15 at 17:17
  • 1
    The server's public key is in the server's certificate, which is signed by a certificate authority. If the CA also uses a RSA key, then you have what you ask for: a RSA key used for encryption, authenticated with a signature relative to another RSA key (the CA key). – Tom Leek Sep 24 '15 at 17:19
  • 1
    There is no "ephemeral RSA" cipher suite in SSL, where the server would generates a new encryption-only RSA key pair to be used for key exchanged. There _used_ to be such a mechanism, but it was to support strict pre-2000 US export regulations, and the ephemeral RSA key was hopelessly weak by being constrained to be of 512 bits or less. Modern clients and servers do not support that (or at least _should not_ support that). – Tom Leek Sep 24 '15 at 17:21
  • Now, everything makes sense :) thank you so much, Tom! – Johnny Willer Sep 24 '15 at 17:24