From what I can gather, when encrypting with RSA key pairs, you cannot encrypt more data than the length of the key (at least I can't find the implementation in the libraries I'm using). So then, in order to encrypt larger amounts of data, you need to break it into chunks and encrypt the individual chunks. Please let me know if I'm incorrect about this assumption.

If the above assumption is true, I see this as similar to encrypting data with AES using ECB mode. This is obviously a bad idea as indicated by the following famous image:

AES-ECB sucks

Are there implementations of stream cipher or block-chaining like equivalents when using RSA key pair encryption which provides the expected level of pseudo-randomness over the entire data being encrypted?

Please feel free to comment on any assumptions I have made that may be incorrect.

  • Also, keep in mind that I am already aware that "stream cipher" is specific to symmetric encryption. So no need to comment on that. – br3nt Jul 5 '18 at 2:29
  • 1
    Your assumption is incorrect. To encrypt a large file with RSA, you encrypt a single symmetric key (e.g. AES) and use that to encrypt the file. This is called a hybrid cryptosystem. – forest Jul 5 '18 at 2:29
  • Is that up to the developer doing the encryption to implement, or actual functionality offered by crypto libraries? Eg using libraries like openssl – br3nt Jul 5 '18 at 2:33
  • Libraries usually help abstract that away. If you use a particular protocol, like TLS, then all that happens behind the scenes. Otherwise you would use RSA (or another algorithm) to compute a shared secret, which with you would encrypt your data. Some libraries, like libsodium, make it easier. – forest Jul 5 '18 at 2:34
  • 1
    (1) if using openssl for SSL/TLS I concur with forest; if for messages like CMS/SMIME see the man pages for those routines, or the underlying EVP_{Seal,Open}{Init,Update,Final} routines which do hybrid encryption. (2) if you did use RSA directly for large data broken into chunks, which no one does and you shouldn't, the chunk size is less than the key size not equal, and all accepted RSA encryption schemes are randomized to provide semantic security; only 'naive' aka 'textbook' RSA would be risk penguinization and there are dozens of As already about NOT using naive/textbook RSA. – dave_thompson_085 Jul 5 '18 at 5:39

First of all, basically nobody encrypts messages directly with asymmetric primitives. Instead, in practice asymmetric cryptography is used for key encapsulation or for key exchange.

But to answer your question, the standard RSA-only encryption algorithm is RSA-OAEP, which involves randomizing the encryption (the values r and Y in the explanation in that page). So encrypting the same input block twice does not produce the same output, which avoids the ECB problem.

| improve this answer | |
  • "basically nobody encrypts messages directly with asymmetric primitives" This reeeeeally needs a qualification that nobody doing things correctly does it this way. I guarantee there's a non-trivial number of people doing this. – Steve Sep 4 '18 at 21:16

If you need asymmetric keys and have data that is to large the solution is house hybrid encryption, not to breakup the data and use multiple asymmetric encryptions.

The concept is to create a random symmetric key and encrypt there data using that key with symmetric encryption such as AES. Then encrypt that symmetric key with asymmetric encryption such as RSA or ECC. Then package the encrypted key with the encrypted data.

Aside: The Penguin image is an illustration that using ECB mode is not secure in most cases. In the case of RSA padding is used which essentially protects against similar "penguin style" security issues.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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