I know that you should never use RSA with any block cipher mode of operation, but theoretically, what's the best block cipher mode (safest) we can use with RSA encryption - without adding any kind of padding?

I already know that CTR is not the best choice and that ECB with RSA and without padding is a really bad idea cause we can see the repeated blocks, but between CBC, CTR, and OFB, I can't understand what would be the best choice.

  • 2
    $\begingroup$ None of those. Why not use an authenticated mode like GCM? And what's wrong with using RSA with a block cipher? I assume you mean using RSA to encrypt a key that a block cipher will use to encrypt. $\endgroup$
    – forest
    Commented Jan 7, 2019 at 1:17
  • 1
    $\begingroup$ It would be helpful if you could state what problem you are trying to solve. Your question does not mention block ciphers, but it does mention modes of operation. Are you asking about using RSA itself with one of these modes of operation? And if so, why? $\endgroup$
    – Ella Rose
    Commented Jan 7, 2019 at 3:06
  • $\begingroup$ @forest I'm fairly certain that OP is confusing block ciphers and modes of operation. $\endgroup$
    – Maeher
    Commented Jan 7, 2019 at 6:48
  • $\begingroup$ I'm sorry, I meant the modes of operation. It's a really confusiny topic for me $\endgroup$
    – Vin Iov
    Commented Jan 7, 2019 at 10:20

1 Answer 1


The question is asking for a block cipher mode of operation usable with RSA.

Caveat: this is unusual and (almost certainly) not a right or valid solution to the problem at hand. See last section for the secure, common, simple, fast alternative.

RSA with proper random encryption padding (like RSAES-OAEP) is believed to give IND-CPA and even IND-CCA2 confidentiality. But it has limited capacity: like 190-byte message for 256-byte cryptogram (using RSA-2048 and SHA-256). Above that limit, ECB can safely be used if one does not care about the large speed penalty (especially for decryption) and significant size penalty due to repeated use of RSAES-OAEP.

RSA without random encryption padding (textbook RSA) is not secure. In particular, it allows to check a guess of the plaintext. Also, care must be taken that a plaintext block should be at least 1 bit less than than the public modulus is.

None of the modes of operation used for symmetric block ciphers make RSA secure:

  • ECB, CBC, PCBC all inherit the weakness of textbook RSA that a guess of a plaintext block can be trivially verified by re-performing the encryption of that block (which requires the public key only), and comparing with the actual ciphertext block.
  • CTR, CFB and OFB are totally insecure. Anyone can trivially decipher, since decryption uses the block cipher in encryption mode only.

Secure variations would amount to a specialized random padding. I'll refrain from suggesting any.

An efficient (and the most used in practice) solution to the problem of encrypting large messages with RSA is hybrid encryption: symmetric encryption with a random key, and encryption of that key per RSA. A slightly different option is RSA-KEM, where the key is secured (not encrypted) using RSA.

  • $\begingroup$ Thank you for the explanation, but the real problem is that i don't want to use any kind of padding. In fact, I want to analyze the best usable mode with RSA even if it's not totally safe $\endgroup$
    – Vin Iov
    Commented Jan 7, 2019 at 10:24
  • $\begingroup$ Don't you mean IND-CCA2? $\endgroup$
    – forest
    Commented Jan 7, 2019 at 10:44
  • $\begingroup$ I now detail why none of the classical mode is safe with RSA. @forest: thanks for noticing my mixup, fixed now. $\endgroup$
    – fgrieu
    Commented Jan 7, 2019 at 11:03
  • 1
    $\begingroup$ Nit: RSA-KEM doesn't really encrypt the symmetric key used for the symmetric cipher with RSA, as you would first have to use the wrapped as key input material for a KBKDF to derive the secret key (both during RSA-KEM based encryption and during decryption). $\endgroup$
    – Maarten Bodewes
    Commented Jan 7, 2019 at 13:28

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.