Using RSA encryption to encrypt large files The following post discusses the use of RSA for file encryption:

https://medium.com/@ismailakkila/black-hat-python-encrypt-and-decrypt-with-rsa-cryptography-bd6df84d65bc

The file encrypted is a JPEG image. My question is: what if we were to encrypt larger files say, 10 MB, in a similar manner and are able to reach acceptable encryption speed with a modern i7 processor? 


Is the resulting ciphertext practically decryptable in anyway without the private key? 
What factors affect the speed of encryption in this case? The RSA key size? The block size? The padding type?


Note: I do realize that RSA is not meant for file encryption in this manner and that a hybrid encryption scheme is more suitable (encrypt data with a session key, then encrypt session key with the RSA key). Please do bear with me and assume that we must encrypt a large file with RSA. I'm merely trying to understand the practical impacts and limits in doing so and I realize that hybrid encryption is more appropriate here.
Is the resulting ciphertext practically decryptable in anyway without the private key? 
  


No, you would need the private key. There is no practical limit on the amount of times that you can encrypt with a public key. I would make sure that the randomness within the padding is at least 128 bits though. Also note that decrypting many times with a private key makes the algorithm more vulnerable against side channel attacks (which often rely on statistics). Furthermore, it disallows you to protect the private key with a PIN or password for each decryption.


  
  What factors affect the speed of encryption in this case? The RSA key size? The block size? The padding type?
  


Yes, yes and yes.

The RSA key size is of utmost importance because larger key sizes will affect performance hugely. Furthermore, RSA key sizes grow very fast if you require more key strength. RSA-3072 is providing about 128 bit security, but you need to go over 16Kbit of key size to reach 256 bits. And those kind of operations are certainly very slow, specifically when it comes to private key operations.

The block size used for the plaintext differs from the one for the ciphertext (i.e. the input is always smaller than the output) due to the padding requirements. The block size for the plaintext is generally 11 smaller than the key size for the less secure PKCS#1 v1.5 padding and differs by the hash value for OAEP. The block size of the ciphertext is identical to the size of the modulus in bytes.

The padding type is generally not much of a problem when it comes to encryption speed. RSA private key operations are rather slow, and the unpadding won't take much time compared to them. The generation of the padding however relies on a secure random number generator. Random number generation can be fast, but it might also block or slow down the system by other means.



Note that performance is only one reason why direct encryption with RSA should be shunned. The expansion of the ciphertext compared to the plaintext is another big reason. And as indicated, requiring the private key to be available for batch operations may well put it at risk.