Imagine I wish to upload my sensitive personal information (photos, document scans, list of passwords, email backups, credit card information, etc.) on Google Drive (or any other cloud service).

I want to make sure this entire bunch of data is as safe as possible (against hackers that would in some way get their hands on this data, and against Google and its employees, and also in the future, i.e. if I delete this data from Google I want to be sure they won't be able to 'open' it even if they keep its backup forever).

So in this case instead of uploading all this data right away to the cloud, I will instead make one folder containing all the data I want to upload, and then I will compress this entire folder using 7-Zip and of course password-protect it using 7-Zip.

I will do this not once, but a few times, i.e. once I have the 7-Zip password-protected archive ready, I will compress it once again using 7-Zip and use a completely different password. I will do this five times. So in the end my data is compressed five times and it has been password-protected using 7-Zip by five completely different unrelated passwords. So in order to get to my data I have to extract it five times and provide five different passwords.

What I will then do is that, I will take this five-times-password-protected archive, and I will compress it once again using 7-Zip and yet a different sixth password, but in addition to that this time I will also choose to split the archive into smaller chunks.

Let's say in the end I end up with 10 split archives, where each of them is a 200 MB archive except the 10th one being only a 5 MB archive.

The assumption is, all those six passwords are at least 32-character passwords and they are completely unrelated and they all contain lower/upper case, numbers, and symbols.

Now I take those nine 200 MB archives and put them in one container and encrypt the container using VeraCrypt (assuming the three level cascade encryption) and then upload this container to my Google Drive.

I keep the 10th archive (the 5 MB one) on a completely different service (say on Dropbox -- and that Dropbox account is in no way connected/linked to my Google account at all) (also encrypted by VeraCrypt).

- Have I created a security theater? Or have I really made it impossible for anyone to access and extract my data? After all they have to pass one level of encryption by VeraCrypt and even after that the archives are six times password protected and one of the archives (the tenth one) is stored somewhere else!

- If someone gets access to my Google Drive and downloads all those nine archives, is there any way for them to extract the archive without having the last (the tenth) 5 MB archive? Can the data in any way be accessed with one of the split-archives missing?

- Even if someone gets their hand on all those 10 archives together and manages to bypass the VeraCrypt encryption in any way, will it be still feasible to break the six remaining passwords?

  • 69
    You're over complicating things and complexity is an enemy of security. 7zip has native AES-256 bit encryption so a single strong, unique password should be plenty. Even if you're as interesting to someone who could potentially crack that encryption as you might think, odds are they'll try to target you as you're processing the data and not when it's at rest as that's the path of least resistance.
    Commented Mar 24, 2017 at 13:25
  • 8
    One obvious thing i didn't see mentioned in the answers is that guessing three passwords of one bit each is much easier than guessing a single three bits password (via bruteforce). In other words, a longer password is more robust than many smaller ones because there's no intermediate feedback one can take advantage of. Commented Mar 24, 2017 at 20:10
  • 20
    Note that using 5 passwords of length X is significantly worse than using one password of 5*X length. It is as if I twice in a row asks you to guess one number between 0 and 10, which would take at most 20 guesses, compared to guessing a single number between 00 and 99. If your passwordlength X gave e.g 2^25 combinations, then cracking your scheme would involve doing that 5 times, so doing 5*2^25 ~ 2^27 amount of work. But instead making one 5*X password would give 2^25 * 2^25 * 2^25 * 2^25 * 2^25 = 2^125 amount of work.
    – epa095
    Commented Mar 24, 2017 at 21:24
  • 6
    @Bakuriu: Yes, I am assuming that the attacked can break each layer by itself, which is exactly the situation we are in here. The suggestion is to use 7-Zip and iterate the zipping with different passwords, 5 times. Then you are certainly able to distinguish whether you were able to crack the "outer" password or not. A 7-zip archive contains more than just the raw data, it also has metadata-fields which enable you to recognise if your decryption-attempt of the outer zip was successful. If I enter the wrong password 7-zip is able to detect that and provide an error.
    – epa095
    Commented Mar 24, 2017 at 21:48
  • 4
    Obligatory XKCD Commented Mar 25, 2017 at 18:10

8 Answers 8


First of all, that multi-encryption scheme is ridiculous.

The algorithm used by 7-Zip is AES-256 which is considered secure. But if someone would find a flaw in it which would make it breakable, then they would likely be able to break all your encryption layers with equal effort.

So either you trust the encryption algorithm used by 7-Zip, then one application would be good enough. Or you don't trust it, then you would do another encryption pass with a different algorithm. Layering the same algorithm multiple times often doesn't have as much effect as one would think, as the meet-in-the-middle attack on Triple-DES demonstrated.

Regarding splitting up an encrypted file: It is often possible to rescue some data from a 7-Zip archive if parts of the archive are missing. 7-Zip uses AES in CBC mode to emulate stream-cipher behavior (every 128-bit block is combined with the previous 128 bit block). That means if someone is missing a part of the message, they can't decrypt anything which follows (unless they have a known plaintext somewhere), but everything which comes before it. That means if you want to prevent an attacker from decrypting the archive by withholding a part of it, you need to withhold the first chunk, not the last one.

  • Interesting and helpful information. You point out that "[...] they would likely be able to break all your encryption layers with equal effort." This is in fact a question rooted deep in my inquiry as well: you say with "equal" effort. So for example, if it takes them 10 months to break that encryption, then here equal effort means that they should spend 50 more months to break the rest of the passwords. So in this scenario that multi-encryption has been beneficial. Isn't it so?
    – Neli
    Commented Mar 24, 2017 at 16:45
  • 2
    @Neli: Only if broken via brute force. If they can break the first in 10 months via any other method, it will take them ~0 more months to break the rest of the passwords. Commented Mar 24, 2017 at 16:49
  • 4
    @Neli That's one example, but not the only one. You also have to account for events like someone totally defeating the 7zip encryption. For example because 7zip has a backdoored implementation or because (very unlikely) someone discovers some flaw in AES which makes it trivially breakable. If your only goal is to bide time for brute forcing, you can get better results by using an algorithm with a longer key length and by using a longer passphrase.
    – Philipp
    Commented Mar 24, 2017 at 17:12
  • 18
    @Neli that time increase only sounds appealing until you realize that adding a single character to the password will increase time to brute-force by about 300-800 months (depending on what character class you choose from). So in terms of number of characters you need to memorize vs. strength against brute force, doing multiple passes is a particularly poor approach.
    – Tgr
    Commented Mar 24, 2017 at 21:29
  • 1
    Case study in exploits: MD5 hashes were thought to be secure. It was thought that all the computing resources in the world couldn't create a single collision in the lifetime of the human race. That was back in '92 when it was invented. Nowdays, because the algorithm has been broken, it now takes 11 hours to generate a collision of your choosing. If you layered 500 of these MD5 hashes on top of eachother, it'd still take just a year to break.
    – Cort Ammon
    Commented Mar 26, 2017 at 16:35

This is over engineering on a scale I've never seen. This is a BAD THING ™ because it increases the complexity of your solution without adding any security benefit.

The encryption mechanism is either safe, or it is not. You will not be more protected by encrypting multiple times. If the encryption is secure, it's useless to add additional layers of encryption. If there is a flaw in your security model, for example, your encryption keys could leak, multiple layers of encryption will not fix this flaw.

It's the same for splitting the archive: it serves no purpose. It doesn't improve nor decrease the protection of your documents.

You should look at the bigger picture: Where do you save your passphrase? Who can access it? What's your backup solution if you cannot access or remember you passphrase? Is your computer safe from malware (that would render any encryption useless)? Is your solution so complex that you will never use it?

  • 2
    You will not be more protected by encrypting multiple times. => I would think there are two caveats with this statement: (1) if some passwords lead to weak keys (possibly), then using multiple layers makes it less likely to accidentally hit a weak key and (2) encrypting multiple times with different algorithms would protect better against one of them having a flaw. Of course, since AES256 is considered secure this is all contingent on the existence (now or in the future) of a weakness in AES256. Commented Mar 24, 2017 at 15:27
  • I assume secure algorithms. If you use weak passwords, chances are that all your passwords are weak, thus the security will not improve substantially with multiple layers of encryptions (I let you do the math).
    – A. Hersean
    Commented Mar 24, 2017 at 15:37
  • 1
    I am NOT talking about weak passwords, I am talking about passwords leading to a weak AES256 key, similar to the issue that plagued DES. Commented Mar 24, 2017 at 15:44
  • The purpose of splitting was to make the archive unextractable in an easy way. That is to say, if you have 10 archives and one of them is missing, and you do have the password then there's no easy way in 7zip itself to extract that data. Thus, I assumed this might add some level of security.
    – Neli
    Commented Mar 24, 2017 at 16:51
  • @matthieu-m You'll have to use those passwords on purpose. If they exists for AES, they will be really hard to find. You cannot realistically accidentally use one. Just do the math.
    – A. Hersean
    Commented Mar 25, 2017 at 10:48

First off, breathe. Encryption efforts often fails if you forget to breathe. Something about going unconscious causes us to have a hard time encrypting things!

Second, it sounds like you are in need of a threat model. A threat model describes what sort of adversaries you are worried about facing. Without a threat model, all security is security theater because you're basically flailing around wildly hoping that your uncontrolled actions stop an opponent you know nothing about. Are you trying to stop your sister from reading your diary, or are you trying to hide from the mob? Have you made enemies with any three letter agencies lately?

Have you considered whether or not your adversary is willing to engage in rubber hose cryptanalysis?


This is why a threat model is so essential. Consider this. It is generally accepted that an AES-256 encrypted file protected with a suitably long password is uncrackable by anything short of a government agency, and its generally assumed that the government agencies cannot crack it either. Thus a single layer of AES-256 will most certainly protect you from anything up to the sorts of shady characters who are willing to beat you with a rubber hose until you cough up the password. There's no reason to do anything more than one layer of AES-256 unless you have a threat model to back it up.

Now why do you think that splitting the file will help you? You're using some of the strongest encryption tools on the planet already. Why would withholding one section really help? Sure, if you're up against an attacker who knows of some currently undisclosed crack of AES-256 but doesn't know how to reverse engineer a 7zip split file format, that might help. So could tin foil.

I would not say that what you have is security theater. The first step is good: store the data in an encrypted format with a good strong password. The rest of the process, however, is security theater. Don't waste your time putting layers upon layers of encryption.

The worst case scenario is that your overzealous effort prevents you from accessing the data because you made it 10x more difficult to get to your own data. The likelihood of a mistakes in the process which renders your data inaccessible is great, and you gained no appreciable actual security for it.

  • 2
    @Nat The tricky part is finding techniques which would actually be secure 50 years from now. If your threat model includes 50 years of progression in computer hardware and cryptographic knowledge, then you see pretty quickly that there's a really good chance your seven layers of encryption increased the time it took to decrypt from 2 second to 14 seconds. It's a bit harder to increase the time to 2^7 seconds. It may be worth noting that, if a major government wants to keep something secret for 50 years, it stores it in a vault and puts guards at the door.
    – Cort Ammon
    Commented Mar 26, 2017 at 5:47
  • @Nat This is why I say just do 1 layer of AES. If there are no new cryptographic attacks to AES in the next 50 years, then layered AES will increase complexity exponentially. That guarantee fails if there are cryptographic attacks (which, if history is any indicator, there will be). It also fails, for instance, if you do what the OP is doing, using multiple layers of password protected 7zip files, which will not be exponential. You really have to do it right, or not at all.
    – Cort Ammon
    Commented Mar 26, 2017 at 6:29
  • 9
    And, at some point, you have to admit that when the encryption you are seeking to apply to your data is more than the US government applies when encrypting its top secret/SCI information for transmission over the internet, you probably shouldn't be storing the data in dropbox.
    – Cort Ammon
    Commented Mar 26, 2017 at 6:33
  • 3
    +1 for the last paragraph. Encryption is good when you want your data be accessible to (1) you and (2) nobody else. When you care only about (2), rm(1) is much better than AES. Commented Mar 27, 2017 at 5:25

I'm not as familiar with 7-Zip to fully understand its capabilities. However, assuming it is only a password-protected zip file, then no, this is not secure. However, I see some comments where 7-Zip may offer AES based encryption which would be secure (assuming that no bugs exist with the implementation of 7-Zip so it created a true and valid AES encrypted file).

In short, anything that can be downloaded and cracked offline should be assumed that it can be cracked with enough time. Assuming that your 7-Zip file is encrypted with AES-256 (again, no bugs) you would be at the mercy of the entropy of your passwords and the speed of the attacker's machine.

Instead of creating 5 or 6 levels of split archives, using a single archive of high-entropy password would be sufficient. Splitting the archive does nothing as you only have to be able to 'unlock' the first one to be able to decrypt the chain of archives.

Ultimately, the answer to your question is that is purely sufficient to use 7-Zip with AES-128 or 256 as long as you are using a truly random and secure password with as much entropy as possible. 64-characters of uppercase, lowercase, numbers and symbols with no discernible patterns or repetition is perfectly acceptable. Just don't write down the password on a sticky-note and leave it on your monitor. Use a real password manager to keep track of that 64-character password and make sure you use a nice secure master password on that password manager. You're only as secure as the least secure method -- sticking your password as a plain-text file on your desktop is not secure.

Keep in mind also, that it might be easier as an attacker to just gain access to your PC to capture this same data -- keep in mind who you're trying to protect yourself from. In this case, the above is perfectly acceptable for something like Google Drive/Dropbox and worries about them getting exposed (or nosy employees).


All the answers given so far are great! However, I think there is one possibility yet to be mentioned. I noticed in the original question that the OP mentioned password length (32-character passwords) and putting an item on a second cloud service that would be needed to decrypt the original data.

I believe VeraCrypt supports keyfiles and this would address a couple of things in the original question.

  • Increase the brute force difficulty (assuming attacker does not have keyfile or the password)
  • Allow for the keyfile to be stored in a separate location (2nd cloud service) from the encrypted data.
  • Less bandwidth since you don't have to transfer actual data to the 2nd cloud service. (unless you want to)
  • Limitation: It would not be helpful if a non-brute-force AES vulnerability is found that does not require the key/password to decrypt.

This is fine. Some parts are probably redundant (using the same crypto system more than once) but if you instead had the first zip and then added some raw data, and then put all of that into a zip and so on it would make sense, so it's like pass the parcel with your oldest files in the middle.

Then for the step where you take out a chunk to make it un readable it's possible but not as simple as you put it. You would have to use an implementation of Shamir's secret sharing, or XOR the final compressed encoded file with random data, then save the result online and the random data elsewhere.

  • I don't get the down vote, Neli asked if 7zip is secure, which if the AES-256 is implemented correctly it is. Sure doing it multiple times doesn't increase that security but doesn't make it worse. Also even the file splitting method he proposed does add some amount of protection, if someone said "I zipped a movie and split it into 10 parts, here is 9 of them tell me what happens in the movie" I'd tell you I need the 10th bit or NSAs help.
    – daniel
    Commented Mar 24, 2017 at 14:06
  • 4
    Am not the one who downvoted, but you say it yourself "doing it multiple times doesn't increase that security but doesn't make it worse". It does not increase security, therefore it is not more secure than any other method. What OP is trying to do is increase security, which does not happen by this process.
    – Marv
    Commented Mar 24, 2017 at 14:45
  • He does seem to be thinking that doing it 5 times automatically make it 5 times more secure, which may not be true (which Philipp put better than me). But depending on things it could add some security (such as if AES-256 was partially broken, but it took 1 year to break it, then his folder would take 1 to 5 years to get to). Stacking encryption is done, but usually this means stacking different algorithms for a good reason.
    – daniel
    Commented Mar 24, 2017 at 15:16
  • Setting up automated multi-pass encryption is time wasted during which you could have done something that actually has a security benefit, so it's not fine: it decreases your security compared to what you could achieve with same amount of resources by following best practices. (Such as stacking different encryption methods, as you say. Which has the added benefit that you can use some widely trusted encryption software as one of your passes, instead of having to hope that the - not exactly security-oriented - 7z software implements encryption correctly.)
    – Tgr
    Commented Mar 24, 2017 at 21:43
  • But this does have a security benefit, just no one here that hasn't already found a crack for AES-256, or a flaw in its implantation in 7zip can say how big that benefit is. The thing he should do is take the first of the split archives (1 of 10 or whatever) each time he encrypts, and then it really does increase the security to a degree no one can calculate. And like i said at the start if you want it impossible use a one time pad.
    – daniel
    Commented Mar 24, 2017 at 23:48

Your zip split method is absurd and does not add any protective value. Simply use a well understood, well tested, strongly encrypted compression method and you will be as secure enough to meet your stated need. If you can't trust the compression (Zip or whatever) separate the compression of the data from the encryption container if it makes you feel better. Multiples and splits you describe add complexity without adding meaningful security (like key strength or process vetting). You won't solve faulty implementations of compression + encryption by doing it multiple times.


In addition to the other answers, I wanted to point out that you would have to store the passwords somewhere. If they get the passwords, they can easily access the data. If you wanted to secure them, you would have to encrypt the passwords, and store their passwords somewhere, etc.

  • 1
    this is actually covered by other answers, too
    – schroeder
    Commented Mar 25, 2017 at 13:13
  • I didn't see anything, but I was just skimming it. Should I delete it, or keep it? Commented Mar 25, 2017 at 13:46

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .