# Use RSA keys to derive AES key

I have 2 end points where I would like to derive the same AES key.

Every end point has its own RSA key pair and RSA public key from the other end point, and I would like to combine them somehow on both sides to derive the same symmetric key. How it can be used to derive AES key with the same value on both sides?

I am looking for something like ECIES-KEM but for RSA.

EDIT:

From the RSA-KEM as suggested from Wiki: I have on endpoint A private key SK_A and public key PK_B. On the end point B I have private key SK_B and public key PK_A. As I understand the end point A should generate random m, where 1 < m < n. Then the m should be encrypted on end point A with PK_B and sent to end point B.

After that, both end point would be able to derive the same AES key using m and KDF. Is that correct?

• Do you want a dynamic key agreement (such that both sides can influence the resulting shared secret) or do you want a public key encryption (such that one side picks a key and encapsulates it for the other side)? – SEJPM Aug 2 '17 at 10:49
• I assume that dynamic. Both sides has RSA keys and they need to derive the same AES without further communication between them. – user1563721 Aug 2 '17 at 10:51
• How do you expect them to agree on something if they are not allowed to communicate? – Elias Aug 2 '17 at 11:07
• @user1563721 What exactly is it that none of the given solution or simple hybrid encryption provide? – Elias Aug 2 '17 at 12:37
• @RickyDemer Well, true but without further communication a shared key isn't very helpful so I thought a more general view of the system might be useful. – Elias Aug 2 '17 at 13:31

With RSA-KEM,* the sender knows a modulus $$n$$ and a public exponent $$e$$, and the receiver knows the private exponent $$d \equiv e^{-1} \pmod{\phi(n)}$$. To send a message $$m$$, the sender picks $$0 \leq x < n$$ uniformly at random, derives $$k = H(x)$$ for some hash function $$H$$, computes $$y = x^e \bmod n$$, and transmits $$y$$ alongside the authenticated ciphertext $$c$$ (e.g., AES-GCM) of $$m$$ under the key $$k$$. The receiver recovers $$x = y^d \bmod n$$, recomputes $$k = H(x)$$, and recovers $$m$$ from $$c$$ using the key $$k$$.
This protocol is non-interactive in the sense that the sender can package up $$(y, c)$$ and send it off to the receiver. There's no authentication of the sender built into the protocol; if you want the receiver to be able to verify which sender sent it, the sender could sign the message $$(n, e, y, c)$$ giving a signature $$s$$, and transmit $$(y, c, s)$$.
However, like ECIES-KEM, this protocol does not provide a static shared secret between the sender and receiver using their long-term key pairs. In contrast, in Diffie and Hellman's seminal 1976 public-key cryptosystem, Alice publishes $$g^a$$ in the telephone book, Bob publishes $$g^b$$ in the telephone book, and their static shared secret is $$g^{ab}$$.
This protocol also doesn't provide is deniability—the signature $$s$$ can be verified by a third party. In contrast, the Diffie–Hellman public-key cryptosystem does provide deniability because any authenticated ciphertext sent between Alice and Bob under a key derived from their static shared secret $$g^{ab}$$ could have been created by Alice or Bob: in a symmetric cryptosystem, the power to verify is also the power to forge.
Signing the recipient's key $$n$$ and $$e$$ in addition to the ciphertext thwarts Don Davis's misattribution attack on PGP and S/MIME. If you use the signing key for multiple purposes or contexts, you should make sure to identify the purpose as part of the message you are signing so that a signature used for one purpose can't be abused for an unintended other purpose. This is sometimes called ‘domain separation’.