views:

72

answers:

4

I need to encrypt a 100KB file using a public key. I've been reading some posts claiming that it is not practical to directly encrypt large files using a public key, and that the preferred method is to encrypt the file using a symmetric key and then encrypt this symmetric key using the public key. It seems that a naive solution would be to break the large file to pieces and encrypt each one of them using the same public key. My question is whether and why this solution is wrong?

+1  A: 

If I understand you right, you want to encrypt the file with someone else's public key, to be decrypted by their private key?

The advantage of using symmetric encryption and only using public key cryptography for the (symmetric) key is performance: symmetric cryptography is computationally much less resource-intensive (trade-off: you have to keep the key secret -- and that's what the second, asymmetric step is for).

Breaking up the file adds management overhead (how can you be sure how many chunks there will be? that you have transmitted them all?) and doesn't add any security. On the contrary.

chryss
keeping the shared key secret is solved by randomly generating a new one for every message, transmitting it to the recipient public-key-encrypted and then throwing it away.
Thilo
An alternative is to combine both.Step 1: Create any Randome-Key, for exampel a 64 Char String (512 Bit)Step 2: symetric encrypt your file with the Key from Step 1Step 3: encrypt the Key with any asymetric-encryption (public key)Step 4: add the result from Step 3 at the end of your enrypted file.To decrypt:Step 1: read and remove the last XXX Bit form the fileStep 2: decrypt the data from Step 1 with your private keyStep 3: decrypt the file with the key who are the result of Step 2
Floyd
Yup, I clarified the response - I was speaking in general terms about keeping the key secret, and that's what the publickey step is for.
chryss
+2  A: 

The hybrid approach you mention (generate a random symmetric key, use this to encrypt the data, and encrypt only the key asymmetrically) has a massive performance advantage.

You could "break the large file to pieces and encrypt each one of them using the same public key" as well, there is nothing wrong with that, but it is much slower.

Thilo
It is bad idea to splitting file, http://en.wikipedia.org/wiki/Watermarking_attack
TBH
@TBH: Yes, come to think of it, one could easily spot repeating blocks and such. On the other hand, this problem could be overcome by throwing in some random padding. I still maintain that the principal difference is performance only.
Thilo
In the performance point of view, the best you can do is exchange the AES (or Serpent) encryption key, and encrypt these data with symetrical-key.
TBH
+1  A: 

Splitting file into smaller pieces and then encrypting them with some asymmetric cipher has nothing to do with the runtime cost of the encryption process. Best practice is encrypting the data with a good symmetric cipher using a relatively strong key and encrypting the secret key you used in symmetric encryption with an asymmetric cipher(using your public key).

ardalahmet
If performance does not factor in, why is hybrid encryption a best practice?
Thilo
I mean performance would not increase if you split the file and again use asymmetric encryption. In hybrid approach you have the advantage of encrypting large data with a symmetric cipher, because symmetric ciphers are relatively more time-efficient in contrast to asymmetric ciphers. And say your secret key is 256-bits/32-bytes, you only have to encrypt 32-bytes of data with your asymmetric cipher. This approach is better than encrypting the whole file with an asymmetric cipher.
ardalahmet
A: 

Asymmetric cryptography is too slow, the most used approach is to encrypt random symmetric key with asymmetric, and encrypt your data with that symmetric key. And, as well, the best way is to use well-known protocol/standard for that purpose (OpenPGP for instance).

Nickolay O.
You ment GnuPG?
TBH
And GnuPG too - GnuPG is one of the implementations of OpenPGP stanard. There are also other commercial implementations, which can be more flexible and usable.
Nickolay O.