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?

1 Answer
1

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 ScottAug 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 ScottAug 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.
–
CanainAug 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)
–
CanainAug 11 '13 at 2:39