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.


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?

  • 2
    $\begingroup$ 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)? $\endgroup$
    – SEJPM
    Aug 2, 2017 at 10:49
  • 1
    $\begingroup$ I assume that dynamic. Both sides has RSA keys and they need to derive the same AES without further communication between them. $\endgroup$ Aug 2, 2017 at 10:51
  • 2
    $\begingroup$ How do you expect them to agree on something if they are not allowed to communicate? $\endgroup$
    – Elias
    Aug 2, 2017 at 11:07
  • 1
    $\begingroup$ I doubt there is a solution that does not require communication between the parties holding the RSA keys, unless these keys share a common modulus (which would be an atrocity). $\endgroup$
    – fgrieu
    Aug 2, 2017 at 12:11
  • 1
    $\begingroup$ @user1563721 What exactly is it that none of the given solution or simple hybrid encryption provide? $\endgroup$
    – Elias
    Aug 2, 2017 at 12:37

1 Answer 1


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.

* I would say that this is the RSA analogue of ECIES-KEM, but if anything, I would guess that ECIES-KEM as a concept came after and in response to RSA-KEM as a concept!

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’.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.