18

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?

Peter Mortensen
  • 877
  • 5
  • 10
Neli
  • 229
  • 1
  • 2
  • 6
  • 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. – DKNUCKLES Mar 24 '17 at 13:25
  • This of course entirely hypothetical and a matter of self-interest, I do understand that most hackers won't even go near this type of personal data moreso when they become aware it is heavily encrypted and the effort is not at all worth the reward. But I still wish to know whether this hypothetical case would be would offer a higher level of security and a huger headache for a decent professional overly-experienced hacker. – Neli Mar 24 '17 at 13:29
  • 1
    @DKNUCKLES "who could potentially crack that encryption" Right now most likely no one can crack AES. But it's likely someone will be able to crack it 30-40 years in the future. I believe that's what OP meant with "as safe as possible (...) also in the future". – user31389 Mar 24 '17 at 15:08
  • I also want to comment that Google and possibly other companies have resources to create multi-GPU hash brute forcing compute clusters. See [link](http://www.eweek.com/security/researchers-from-google-cti-break-sha-1-hash-encryption-function) making the suggestion to use the most lengthy passphrase possible. – user4317867 Mar 24 '17 at 19:12
  • 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. – Patrick Trentin Mar 24 '17 at 20:10
  • I would consider to use tresorit instead of e.g. google drive. It's already a end-to-end encrypted cloud service with a zero knowledge policy on the company side. – Artery Mar 24 '17 at 20:21
  • The **last** piece of an archive being missing is really the easiest case to defeat, assuming a block-chaining cipher -- it won't stop folks from extracting content from the others if they're willing to write a little of their own code. If you're going to keep a piece somewhere harder-to-get-to, make it the *first*. (That said, I'm in wholehearted agreement with the "useless-security-theater" assessments). – Charles Duffy Mar 24 '17 at 21:06
  • 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 Mar 24 '17 at 21:24
  • @epa095 I don't think that is correct. You are assuming that the attacker can break the layers "one-by-one" (i.e. he guesses the first 0-10 number, and then, after correctly guessing that one, guess the other). However an encrypted file is practically just random data, so the attacker either breaks all encryptions in one go, or none of them. (Because he has no way of telling whether he correctly broke a single encryption layer) Hence it's like guessing two 0-10 numbers *but having to say both numbers at the same time*, which requires 100 trials to solve for sure. – Bakuriu Mar 24 '17 at 21:27
  • 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 Mar 24 '17 at 21:48
  • You should remember to check option *"Encrypt file names"* (which is not enabled by default). Otherwise you will leak information by exposing ***all*** folder and file names... – Peter Mortensen Mar 25 '17 at 06:14
  • 4
    [Obligatory XKCD](https://xkcd.com/538/) – Gallifreyan Mar 25 '17 at 18:10

8 Answers8

88

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.

Community
  • 1
Philipp
  • 48,867
  • 8
  • 127
  • 157
  • 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 Mar 24 '17 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. – Mooing Duck Mar 24 '17 at 16:49
  • That's the meet in the middle attack already mentioned, so depending on how its broken they might have to do some operation 5 times, or they might do some operation once and get some key at the end that is your 5 keys combined into one. – daniel Mar 24 '17 at 16:53
  • 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 Mar 24 '17 at 17:12
  • This answer's incorrect with regards to [meet-in-the-middle attacks](https://en.wikipedia.org/wiki/Meet-in-the-middle_attack), which are infeasible against 256-bit keys due to the astronomical amount of storage that'd be required to perform such an attack. – Nat Mar 24 '17 at 21:06
  • @Nat the meet-in-the-middle attack comment was specifically about 3DES. – Philipp Mar 24 '17 at 21:07
  • @Philipp It's irrelevant to layering AES-256 and this question in general. – Nat Mar 24 '17 at 21:08
  • 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 Mar 24 '17 at 21:29
  • @Neli Another way to look at it is to consider moore's law. If it continues we (roughly) double our computing power every 1.5 years. So If it would take 10 months to break the encryption at any given date, it would take 10 months to break your 6-layered system 3.8 years later. And, of course, it would take 5 months to break the whole 6 layered system in 5.3 years. And that's assuming *literally* the best case (i.e. no exploits found) – Cort Ammon Mar 26 '17 at 16:31
  • 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 Mar 26 '17 at 16:35
  • Moore's law has been dead for a long time. The next CPU upgrade gives maybe a few hundred extra MHz, maybe even a few dozen. In the past, when Moore's law still applied, a 3.5 MHz CPU was superseded by a 16 MHz CPU. Imagine if your 3.2 GHz processor was superseded a few years later by a 14.6 GHz processor! If only... – forest Dec 09 '17 at 04:57
  • Also note that @Tgr's explanation really gets at the core of the issue. If you have a password with 80 bits of entropy, it is far better to lengthen it by another 80 bits than it is to add another "layer" of encryption with its own 80 bit key. The difference is between exponentiation and multiplication. Doubling the length of a password for a single cipher increases strength by 2^(n*2). Doubling the cipher layers (same exact password size increase) only increases strength by 2^n*2. Obviously the former is far better! – forest Dec 09 '17 at 05:00
38

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?

David Refoua
  • 153
  • 1
  • 13
A. Hersean
  • 10,046
  • 3
  • 28
  • 42
  • 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. – Matthieu M. Mar 24 '17 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 Mar 24 '17 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](http://crypto.stackexchange.com/questions/12214/can-you-explain-weak-keys-for-des). – Matthieu M. Mar 24 '17 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 Mar 24 '17 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 Mar 25 '17 at 10:48
  • @Neli If an attacker manager to find 9 out of 10 archives, do you really think he will not be able to find the missing one? And if he doesn't, he might still decrypt some of the 9 ones he has (because you think the encryption is weak, this means an attacker can break it in your security model). You will be better served by using just one strong encryption scheme with a good security policy to protect the secrets (the key or password). – A. Hersean Mar 25 '17 at 10:54
  • If an attacker will try to brute-force it, won't having multiple encryptions be beneficial in this case? (beneficial = slow the attacker down a lot) A similar principle to how PBKDF2 does it. – Radu Murzea Mar 27 '17 at 12:16
  • @razu-murzea brute-forcing 9 more times is faster than brute-forcing a password with a random character added. PBKDF2 doesn't just derive the password 10 times. Just increase the length of your password and you will be better protected than by increasing the complexity of your encryption scheme. – A. Hersean Mar 27 '17 at 14:56
28

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?

XKCD (XKCD)

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.

Tobias Kienzler
  • 7,578
  • 10
  • 43
  • 66
Cort Ammon
  • 9,206
  • 3
  • 25
  • 26
  • 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 Mar 26 '17 at 05: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 Mar 26 '17 at 06: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 Mar 26 '17 at 06: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. – el.pescado - нет войне Mar 27 '17 at 05:25
4

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).

Peter Mortensen
  • 877
  • 5
  • 10
Andrew
  • 371
  • 1
  • 6
3

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.
Paul
  • 41
  • 2
1

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.

daniel
  • 774
  • 3
  • 12
  • 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 Mar 24 '17 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 Mar 24 '17 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 Mar 24 '17 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 Mar 24 '17 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 Mar 24 '17 at 23:48
1

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.

ex-university-cyber-guy
  • 21
  • 1
1

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.

Solomon Ucko
  • 117
  • 1
  • 5