# How is RSA key exchange protected against tampering?

The public key is defined by (N, e) where N is the product of two large primes and e is chosen such that e.d = 1 (mod phi(N)) where phi(N) is Euler's totient function. e is the encryption exponent and d is the decryption exponent.

Suppose x is the symmetric key which is encrypted as c = x^e mod(N). How is tampering with this ciphertext c prevented?

• This is textbook RSA we don't use it. We have paddings like PKCS#5v.1.5 and OAEP for encryption and PSS padding for signature. Let me find you a dupe. What exactly do you mean by tampering? RSA OAEP is Ind-CPA secure if you are talking about just integrity you need MAC. And at least these attacks are possible on textbook RSA that paddings prevent, padding doesn't cover the side-channel attacks, though. Jan 10 at 10:43
• I meant integrity. How MAC is implemented along with RSA? I am aware of MAC implementation in case of symmetric encryption but unable to imagine how MAC would be done in context of RSA and asymmetric encryption in general. Jan 10 at 10:59
• Encrypt-Then-MAC. Your question is basically dupe of this Should we MAC-then-encrypt or encrypt-then-MAC? and we don't use RSA for encryption even though they can be secure with proper padding. We use Hybrid encryption... What are you trying to achieve? Jan 10 at 11:01
• And, without the proper padding, you cannot prevent the textbook RSA against the attacks. Jan 10 at 11:17
• In symmetric encryption the integrity of message is protected by the schemes you described in your previous comment. So assuming that I don't use textbook RSA and I use an appropriate padding scheme , what prevents an attacker from changing the padded ciphertext. Is there something within the padding scheme that prevents tampering with the ciphertext? Jan 10 at 12:15

As indicated in the comments below the question, RSA is commonly not used as modular exponentiation of a symmetric key. Instead, either the key is encrypted using PKCS#1 v1.5 padding or - preferably - OAEP, or a shared secret with a randomized value in the range $$\big[0, N\big)$$ is used for the modular exponentiation. In the latter case an actual key is derived using a KDF (key derivation function), sometimes also simply called a "PRF" (see e.g. TLS 1.2). This is known as RSA-KEM.

There are basically two ways that tampering of the key through a man-in-the-middle (MitM) attack can be avoided:

1. establishing trust in the RSA public key;
2. verification of the shared secret and/or derived keys.

If you pre-share and trust a public key of a static key pair then you'd have a static key exchange, i.e. the public key is trusted, but you would not provide forward security. That means that every subsequent symmetric key can be calculated if the private key is known by the adversary.

The trust of the public key can be established in different ways. For a static key pair the public key could be trusted using PKI. If you need to trust an ephemeral public key the receiver could sign it with a private key which is part of a key pair that is trusted.

Another way is to verify the established session key afterwards. That can be done either explicitly or implicitly.

In explicit verification of the shared secret the party that decrypted the key uses it to generate a MAC over static data known by both parties and sends the MAC. That party can now be sure that the right symmetric key has been established.

In implicit verification the key is simply used to send authenticated messages back and forth. The verification of the authentication of these packages indicates that the right key has been established.

Of course, only the party of which the public key is trusted is authenticated. Similarly, if any MAC is verified, then that only shows that the party holding the private key has been able to decrypt. So if you need authentication of the remaining party then that needs to be handled separately.

In TLS this is performed by simply having the other party create a signature that can be verified. This also requires that the public key of that key pair is trusted in advance; in the end you need to always establish trust in something before you can authenticate the party.

TLS client authentication is hardly ever used. Instead it is replaced by authentication frameworks or password based authentication. Or the identity of the client is never established at all - until a purchase is made anyway.

Note that authentication of keys established using RSA key establishment is not different from establishing keys with, for instance, Diffie-Hellman - although with the latter there are two key pairs to consider. In the end, the same kind of techniques can be used.

• Imagine the following scenario. The server sends its public key to the client. The client verifies its authenticity using PKI. The client encrypts a symmetric key using the public key using PKCS v1.5. A man in the middle intercepts this packet and encrypts its own symmetric key using the server's public key. Will this cause any issue? Jan 11 at 6:30
• Yes, good comment. Actually, this is something that can happen on e.g. web browsers as well. The thing is that the client usually remains unauthenticated (TLS client authentication is not common). This is usually not a problem if the other side is e.g. a webshop: the client authenticates using username/password if they have an account (over the otherwise secured connection) and/or they provide their information simply during checkout. I'll adjust the answer later to indicate that the trust needs to be established for either party - but of course at least for the party sharing the public key. Jan 11 at 12:24
• I think I got it. My concern was that what if a man in the middle tampers with the PKCS v1.5 ciphertext which contains the symmetric key. But after decryption the plaintext may not be PKCS v1.5 compliant. Assuming that it is difficult to tamper with the ciphertext in such a manner such that it becomes PKCS v1.5 compliant after decryption, PKCS v1.5 provides a kind of message authentication code for the encrypted symmetric key. Am I correct in assuming this? Jan 12 at 10:26
• No, because an attacker may simply encrypt something else with the public key. So even if that tamper resistance is there - and it is - it doesn't matter, the attacker can just replace the ciphertext in its entirety. It is only possible to trust another party if they perform some kind of authentication procedure. That can be a private key operation or providing a previously established passphrase. Jan 12 at 16:14