# What are the security effects of reusing a public RSA key to encrypt large data by blocks? [duplicate]

I'm trying to figure out a way to do public key encryption on a very large piece of data.

For this, I of course want one side to do the encrypting but is unable to decrypt the data, and the other side to be able to decrypt data.

But for RSA encryption, there's a limit to the reasonable size-performance on how big it can encrypt.

I haven't really figured out a good solution to this problem, but the simplest one that comes to mind is to just reuse the public key to encrypt the data in blocks. Of course, this would create some sort of security problems, but as of right now I still don't exactly know what kind of security problems it would cause.

Could someone explain to me what problems this simple method would cause and perhaps also tell me of a way to achieve my goal of being able to do public key encryption on a large piece of data?

-

## marked as duplicate by Ilmari Karonen, Hendrik BrummermannAug 10 '13 at 13:44

It is possible but here is a good explanation of the reasons why it is not a good idea. crypto.stackexchange.com/questions/14/… – Arzaquel Aug 10 '13 at 7:15
Why can't you use standard hybrid encryption whee you encrypt the actual message with AES and the AES key with RSA? – CodesInChaos Aug 10 '13 at 11:58

I assume that by

I want one side to do the encrypting but is unable to decrypt the data

you meant a general "encrypting only" party, since if you are talking about a specific piece of data, it does not make sense to disallow the encrypting party from decrypting that data since that party had the data already in the clear.

If that is the case, then your goal might be achieved by first encrypting the data with a symmetric algorithm like AES, which can do big data rather efficiently, and then encrypt the symmetric key/PW with the RSA algorithm. That way, only the other party, who has the private key for the RSA algorithm, can decrypt the RSA-protected symmetric key and then proceed to decrypt the big data.

-
That's generally how SSL works: a public/private key pair for transmission of the symmetric key, and the data itself is encrypted using a symmetric algorithm (and MAC thrown in for good measure). As I understand it (meaning I'm probably incorrect), the principle concern for encrypting data with the same key is the danger of guessing at plaintext... I'm not sure how much of a concern that is with sufficiently strong keys or sufficiently variable data, though. – Pete Scott Aug 10 '13 at 2:32
Here's a partially related question (regarding reusing IV) that goes into some details about the danger of re-using IVs (which would apply to re-using Keys if you aren't using a random IV): crypto.stackexchange.com/questions/2576/… – Pete Scott Aug 10 '13 at 2:45
Ah, thanks, that would work for the problem that I'm trying to solve. I have read a lot of the hybrid answers but didn't think they would work for my case as I didn't think of just simply throwing the aes key away. Your answer explained that clearly though. – Canain Aug 11 '13 at 2:28
I think also the problem was that I didn't think of generating aes key on the fly for each instance which for some reason your answer made me realize that concept (this system needed to encrypt multiple data pieces separately using one key to be able to decrypt them all) – Canain Aug 11 '13 at 2:39