2
$\begingroup$

I'm having trouble location information about whether or not encrypting a file's header is good enough. The files in question are media files that range in size from 500mb to 4GB.

If I had no performance or time constraints, I would simply encrypt the entirety with AES256. However, with my current implementation (in C#), it takes about 3 minutes to decrypt a 2GB file. This is about 2m45s beyond my time limits.

How vulnerable is that file's contents without the file header?

Apologies if this question is silly, this is my first foray into file security.

$\endgroup$
  • $\begingroup$ 1) What are your security goals? Encrypting only part of the file will not be acceptable under most security goals. 2) A desktop computer should be able to get under 15s as long as IO keeps up. $\endgroup$ – CodesInChaos Jan 9 '15 at 15:24
  • $\begingroup$ Basic security to discourage attempts to use the file. It would be ideal if the entire file could be encrypted but the time to decrypt cannot exceed 15s, so I find myself limited. I also considered some sort of hybrid encryption - AES256 file header and something very fast (and less secure) for the remainder of the file. $\endgroup$ – erode Jan 9 '15 at 15:32
  • $\begingroup$ 1) On my computer C#'s AesCryptoService provider takes about 15s for 2GB when using AES128. If you're willing to use native interop you should be able to speed that up a lot, especially if it uses AES-NI. 2) If performance matters, use AES-128 not AES-256. It's still very secure and about 1.4 times faster. $\endgroup$ – CodesInChaos Jan 9 '15 at 15:45
  • $\begingroup$ You might consider replacing your AES implementation with a better (faster) one; as CodesInChaos says, a fast AES implementation should be able to run a lot faster than > 1 minute per Gigabyte. $\endgroup$ – poncho Jan 9 '15 at 15:45
  • $\begingroup$ I expect disk I/O to be the limiting factor. I have tested 2 libraries (Bouncy Castle, SharpAesCrypt) and will now test with .NET AesCryptoProvider which is fully unmanaged and might provide better performance. $\endgroup$ – erode Jan 9 '15 at 15:48
1
$\begingroup$

It depends on the format. The size suggests it is a video. However, video formats seems to be designed to be seekable. That means, the attacker seems to be able to:

  1. Create some header (guessing the resolution and some other information)
  2. If the beginning was damaged, play and seek in the file.
$\endgroup$
  • $\begingroup$ Yes, the files are videos. I am mainly concerned that merely encrypting the file header would leave the actual video content vulnerable to a savvy individual who knew, or could guess the file format. So it would appear that partial encryption may not be viable. $\endgroup$ – erode Jan 9 '15 at 16:33

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.