Split File With 7zip

[Enrique Fats]

Efficientlymanaging large files is essential for effective storage and sharing. This helpdesk article provides guidance on how to zip files using 7-Zip on Windows or alternatively, Keka on your Mac and (please note that there are other options available, and these are just examples, offered as freeware at the time of writing).

Splitting Files becomes necessary when zipped files exceed 50 GB in size, as 50 GB is the maximum file size that can be shared for importing directly using your Power Diary Account via Setup > Data Import.

To access and share the split zip segments on Mac, simply double-click on the first segment (e.g., filename.zip.001). Keka will automatically detect the other segments and combine them to extract the original files.

By following these steps on both Windows and Mac, you can effectively zip and, when necessary, split large files for efficient storage and sharing with us for import into your new Power Diary Account. This process ensures that even files exceeding 50 GB can be managed effectively.

I've searched for this and can't seem to find or figure out how to do this. My requirement is fairly simple, I want to take an ISO file (roughly 5 GB in size), split it into 100 MB chunks, copy the chunks somewhere and then extract the actual ISO file itself, as an ISO file, the same as the original ISO file.

The only thing I've managed to accomplish so far successfully is the splitting and copying. When I get all of the parts to the final destination and extract, rather than getting the original ISO file, I wind up with the contents of the ISO file being extracted which is not my goal here.

I'm sure that I'm doing something simple here incorrectly but I can't figure out what I'm doing wrong.

Any help will be greatly appreciated!

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.

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?

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.

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.

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?

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?

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.

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

3a8082e126