4

Say I have an encrypted zip file with data in it. I feel like I really want this data to be secured so inside that file, I place another encrypted zip with a different password, and then inside that one, I place a final encrypted file with yet a 3rd different password.

The questions I'd like answered:

  1. Assuming all 3 files are encrypted with the same cipher, such as Rijndael 256, is there any actual security benefit to doing this? ie if someone can decrypt the original file, would it be just as trivial to break the next 2?
  2. Would using 3 different encryption ciphers make this arrangement more secured?

NOTE: We're assuming here, that the intruder does not know and is unable to guess the passwords and thus must use alternate means to break in. The passwords are strong passwords which are not susceptible to dictionary attacks.

7

The problem with simply dogpiling one encryption algorithm on top of another and believing that everything will somehow be "more secure" is that if you haven't studied the algorithms in detail, you won't have a full understanding of their weaknesses, or enough understanding of the side effects of this operation. That's not intended as an insult, I'm simply inferring from the question that you're not a cryptanalyst, and you haven't done these studies.

Have a look at Triple DES. It was designed as a replacement for DES once it was recognized that DES was too weak to withstand ever-improving brute force attacks. DES has 8 byte keys, so logically since DES should withstand a brute force attack of 2^64, Double DES should withstand an attack of 2^128. So why use Triple DES and not just use Double DES? It turns out the estimate of strength is not even close to correct.

First, DES discards the top bit of each key byte, so DES has a key size of only 56 bits -- 55 bits once you factor out XOR reflection. An attacker can store the output of a brute force attack on the first instance of DES, then attack the second instance matching any of the stored outputs, creating a meet-in-the-middle attack. This results in an attack of 2^55 + 2^55, which is 2^56. All that work to run DES twice yields a one bit of improvement in strength.

So Triple DES obviously doesn't withstand an attack of 2^192. 3DES does improve this to 2^111 bits of strength, which is still plenty strong, but it's a far distance from the implied strength of 2^192.

It is not obvious that encrypting the output of one pass through DES with another pass is easily broken, yet cryptographers figured that out. Can you offer strong evidence that your two-layer encryption isn't similarly flawed?

Crypto is hard because the random-looking bytes coming out of an encryption algorithm look very much like they've been successfully scrambled. But there isn't an attribute you can test for to know if the encryption is effective or if it's breakable.

So the advice generally given is "do not invent your own crypto algorithms". Going along with that, it is not recommended to invent your own protocols, either; if you must, you have a lot of work to do to prove they're secure.

  • 2^55 multipled by 2^55 is not 2^56, it is 2^110 unless I'm misunderstanding your notation... – Ryan Kelso Mar 9 '17 at 15:18
  • 1
    Typo. I meant addition, not multiplication. – John Deters Mar 9 '17 at 16:12
  • This is the exceptional answer here by far and I appreciate the quick example given about DES. However, two answers here, this one included, mention "not inventing/rolling my own" algorithms when in the question, there is absolutely no mention of doing so. This piece is extremely overused and in my opinion for this particular question, baseless advice. I have no intention of "rolling my own," I am a researcher and the idea here would be to use 3 peer-reviewed, tested, secured algorithms created by professional cryptographers; and that's assuming that I'm going to even implement this. – the_endian Mar 9 '17 at 17:29
  • Sorry if I gave any offense. Your question didn't mention that you were doing the research, it only looked like you wanted to protect some data. However, the advice is not baseless. The landscape is littered with home grown crypto failures - WEP is probably the best known, but GSM's A5 is broken, the Open Smart Grid Protocol is broken, and every version of EMV up to 4.2 is broken. The advice stands. – John Deters Mar 9 '17 at 17:41
  • @JohnDeters No worries! Well, perhaps I've been fortunate enough to have been told that info probably 500x over now... Maybe others have not and this is exposing my ignorance, who knows. In any event, great answer, thank you! – the_endian Mar 10 '17 at 4:47
1

You made an assumption that the passwords used were sufficiently strong and not susceptible to dictionary attacks. I'll just list some other potential vulnerabilities.

  • If the encryption algorithm is somehow significantly broken, multiple layers of the same encryption would provide little benefit. Your second question provides a mitigation to this situation. All three algorithms would need to be compromised.
  • If the machine on which encryption or decryption is performed is compromised, the passwords or the unencrypted data could be stolen.
  • More steps to protect your data may increase the likelihood of human or machine mishandling. Perhaps once-encrypted or twice-encrypted copies of data are left lying around.

If you can protect yourself from the above, I would think your proposal can only improve security. "Defense in depth." Assuming a brute-force attack, using the same algorithm thrice, you could expect an attacker to take 3 times as long to decrypt your data. For three different algorithms, you could make the same estimate or consider the relative strength of each algorithm to calculate a more precise multiplier.

0

Your system is pretty close to snake oil. It does add a lot of complexity and manipulation to encrypt a file and to decrypt it. So a mere human being has a strong feeling that as it is complex, it must be secure.

Unfortunately, encryption and decryption are mathematical. And in mathematics, apparent complexity and actual robustness are loosely related. That's the reason why the rule here is do not roll your own, but rely on well known and heavily tested implementations of well known algorithms. If you want improved security, remain simple and just use long keys generated from long pass phrases. That's today state of the art.

-1

Yes, and no. It would only add additional time for them to crack the file seeing that they have the resources to break any round. Using bigger key sizes would make it more difficult and ensuring that your encryption implementation is sound.

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.