1

I'm writting a script that can encrypt files in a folder. It takes like 30s to encrypt a 1GB file, so I wondering if it's safe when I encrypt some bits of a file and leave the rest unencrypted? I want the script to run as fast as possible.

  • 2
    "Safe" in what way? – schroeder Sep 10 '16 at 7:30
  • @schroeder "safe" mean no one can't get the content of it. for example, if it's a video, I want no one can watch it. – Thành Long Bùi Sep 10 '16 at 8:48
  • 2
    Is it safe to only apply privacy settings to 10% of your facebook posts? Whatever part of the file you don't encrypt will be visible. – Mike Ounsworth Nov 4 '16 at 13:57
  • 30 seconds for 1GB is a little steep. Here's some reference Go code that does it in 2 seconds on my old i3: gist.github.com/libeclipse/a930de7c6af7878f585b3f0028d18c4e – Awn Nov 4 '16 at 17:27
5

That fully depends on the contents of the file. If this is encrypted text where the key for decryption is placed at the beginning of the file it might be enough to encrypt only this information since it is essential to interpret the rest of the data. But in most other cases it would probably be a bad idea to encrypt only a part.

For example imagine that this is a document containing passwords in plain text. In this case it is obvious that encrypting only part of it would be a bad idea because it would only protect a small number of passwords and leave the rest exposed. But also with most video or audio files it is possible to recover the majority of the content even if some parts are corrupt (or encrypted).

  • so, except of improving my script, are there any other methods to increase the encrypting speed? Because I might have to encrypt 1xx GB of data. – Thành Long Bùi Sep 10 '16 at 6:40
  • 2
    @ThànhLongBùi: encryption speed depends on the algorithm used, its actual implementation, speed of CPU, disk, RAM etc. Thus you need to find out first where the actual bottleneck is, i.e. CPU bound, disk bound, RAM bound... – Steffen Ullrich Sep 10 '16 at 7:09
  • You could implement your own DRM scheme (or, more realistically, apply someone else's) This would prevent anyone playing the video without the appropriate "license" that unlocks the DRM. DRM is applied at encoding time and is likely to be more efficient than a brute-force encryption. Though you would need to validate that. – Julian Knight Sep 10 '16 at 12:44
3

Imagine that you have a photo and want nobody to see it. So you open up an image editor and only blur a small part of it.

I can bet everyone can still guess what's on the photo.

This is exactly what you're trying to do with encryption, and this is also why it's a bad idea.

-1

Modern hardware with AES-NI can do AES encryption at the speed well in excess of 1-2 GB/s. By comparison, your hard disk probably can only write at 50MB/s-100MB/s or SSD about 500MB/s-1GB/s. In other words, with properly implemented hardware accelerated encryption, it's unlikely that encryption speed is your bottleneck here.

If you have a huge file (tens of gigabytes or larger), and you want to be able to edit parts of the file without reencrypting/rewriting the entire file, that's a totally different problem. To be able to do this efficiently and securely, you need to understand about block cipher encryption modes. You'd want to have your encryption system to use encryption mode that supports random access securely, such as XTS mode. Note that encryption mode that supports efficient random access are often considered by some people to be not as strong as serial access encryption mode. You should research and consider if the supposed weaknesses of random access encryption is of concern to your particular scenario.

The easiest way you can use encryption mode that supports random access efficiently, is to mount the encrypted file as a block device/disk using full disk encryption software, like TrueCrypt/VeraCrypt, LUKS, or BitLocker.

  • You might be right, but it doesn't answer the question at all. – user81147 Nov 4 '16 at 14:25
-3

30s is not a ton of time, so let it encrypt the entire file, if possible. If it freezes the OS (assuming you know you what that means), then let it encrypt 512 megabytes, or about 1/2 of the file, in that 30s. It seems just as safe to me, and saves you half the lost memory for essential processes. Any less and you risk attackers gaining this information. In short, you can encrypt a small part of the file, given that you encrypt exactly 1/2 of the bytes in this order:

 GARRISON
+ANANANAN
---------
 GNREIFOA

of which GARRISON is an arbitrary letter combo, ANANANAN is an arbitrary 2-letter Vigenere key that has an A in it. That A ensures every other letter encodes to itself. I wouldn't recommend using AAAANNNN, because enough of the plaintext is visible for you to decode the encrypted text by using a known plaintext attack. More than this is unnessecary, and (50+ MB) less than this makes it easier for attackers to crack the encryption. I am using text, but how do you think you are going to type 500 million (using UTF-16, 1 billion in ASCII and UTF-8) characters into notepad?! Using a Vernam cipher or an XOR (not reusing the key) may well be suitable for what you describe. XORing a message shouldn't take that long

  • 1
    Didn't answer the question – user81147 Nov 4 '16 at 14:25
  • does that help? I mean, I know how to encrypt, so go figure. If all you want to encrypt is a message, then use a 2-key vigenere. If you are encrypting 100 gigabytes, then you can use another method. – Garrison Pendergrass Nov 7 '16 at 13:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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