1
$\begingroup$

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?

  1. Is the resulting ciphertext practically decryptable in anyway without the private key?
  2. 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.

Improve this question
$\endgroup$
2
  • $\begingroup$ "decryptable in any way without the private key" - this makes no sense, RSA is an asymmetric cryptosystem, you can't decrypt it without the private key. $\endgroup$
    – DannyNiu
    Apr 14, 2020 at 0:58
  • 1
    $\begingroup$ If you actually look at the source code in that link, it does compression before encryption. Practical exploits exist against such compressed then encrypted data (see: CRIME; BREACH). $\endgroup$
    – learnerX
    Apr 14, 2020 at 1:09

2 Answers 2

Reset to default
3
$\begingroup$
  1. 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.

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

Improve this answer
$\endgroup$
1
  • 1
    $\begingroup$ Yes. Additional notes: 1) Decryption does require the private key (the answer is correct), but decryption can still be possible without knowing the private key: it can be locked in a device. And in some attacks (Bleichenbacher's..), that can be a remote computer remotely abused to decrypt, even though it never reveals the deciphered plaintext/image. 2) The main influence of the padding type is that it influences how many blocks are necessary. For all except small images, there are more with RSAES-OAEP than with RSAES-PKCS1-v1_5, and the decryption time grows in near proportion. $\endgroup$
    – fgrieu ♦
    Apr 14, 2020 at 7:23
0
$\begingroup$

As you point out, you are supposed to use the RSA public key of a target recipient only to encrypt a secondary key that can be used in a much faster streamed block cipher like AES. The recipient uses the corresponding private key to derive the secondary key and go on to decrypt the file to plain in AES.

We tried encrypting very large files with BLOWFISH and TWOFISH but that was also unacceptably slow. The problem is always the management of the user population. To approach Health Information Privacy, for example, you also have to use technologies that can be audited. We tried a novel approach by publishing the decryption code alongside the cipher and relying on client side browsers to do the heavy lifting. This has the advantage that you don't have to distribute supporting software. Google RedTitan REDWRAP. The large file demo will give you an idea of speed.

Improve this answer
$\endgroup$
3
  • 1
    $\begingroup$ Where is the specification? Glancing at the Javascript source for the decoder, there seems to be no workfactor parameter in the password-to-key transformation. How are we supposed to be convinced that the system is adequately protected from brute-force password search? data << 8 | key.charCodeAt(k) to process password input reminds me of the issue documented in the last quote there. redwrap.exe? Perhaps in a VM... $\endgroup$
    – fgrieu ♦
    Apr 28, 2020 at 16:07
  • $\begingroup$ It would easily fail a brute force attack as it stands if the original password is weak - this can be forced by the originating program. In these designs the IV makes little difference to the confidence level and a salt or a complex client side password elaboration scheme don't help. Given that it is AES do you think publishing performance against the test vectors makes any sense? $\endgroup$
    – Peter Henry
    Apr 29, 2020 at 9:42
  • $\begingroup$ Previous comment was about the Blowfish version. The lack of specification, and of consideration for non-ASCII passwords, stands for the AES version. But this time the password is transformed into AES key without any attempt at entropy stretching. This is a cardinal mistake in password-based encryption, and makes the thing a lot more vulnerable to password search than the Blowfish version. As a comparatively minor aside, it looks like the SHA-1 of the plaintext is in clear (in a field bizarrely named HMAC), which would allow testing a guess of the plaintext, loosing CPA security. $\endgroup$
    – fgrieu ♦
    Apr 29, 2020 at 11:34

Your Answer

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

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