Best practices

The large set of options offered by CZIP X allows to plan the protection of your digital documents in an extremely detailed way; The ZipGenius Team hereby offers some best practices that you can use as a good reference.

Encrypt pre-made ZIP archives instead of single files.

The CZIP technology is clearly based upon the ZIP compression format, as much as it creates a temporary ZIP archive with the files you have selected before effectively encrypting them; on the other hand, when CZIP X decryptes a CZX file, it effectively decrypts a ZIP file and decompress its contents automatically.

In order to increase the protection level, you may select an already made ZIP archive as a single file to encrypt.

Using self-locking/self-erasing archives.

The basic form of defense is choosing to create a self-locking CZX archive because, if someone fails to enter the passphrase for three times, CZIP X will lock the archive by setting the chances available to zero; the contents of the archive won’t be touched, so they will still be virtually recoverable, so this option is conceived to protect documents with relatively low importance.

For more important documents that need to be shared with unknown recipients, you’d better choose to create a self-erasing archive: in this case, three wrong passphrase will lead CZIP X to permanently destroy the encrypted data and no content will be recoverable, not even by The ZipGenius Team. The encrypted data will be overwritten several times by random data, so the passphrase that used to decrypt the archive, at that point will become perfectly useless.

Archives not reusable.

The user can decide to set an archive to be not reusable: when the recipient will decrypt the archive using the right passphrase, CZIP X will decrypt the archive and, then, with no warning to user, it will permanently destroy the encrypted data.

CZIP X will warn about what happened just after every encrypted data has been wiped.

This options will override any other setting, so the archive can either be a standard or self-locking/self-erasing archive, but with this option set, all data will be wiped after the first successful decryption.

Non shareable archives.

This is the most important innovation introduced by CZIP X, even though it is an exclusive feature of the application and it not available in the CZIP 4.0 libraries that The ZipGenius Team makes available for third-party developers.

When the user creates a non shareable archives, it is creating an encrypted archive that is strictly tied to:

  1. the device running CZIP X;
  2. the actual user of the device.

When someone tries to decrypt a non shareable archive using a different device or logged as a different user from the one that made the archive with the same device, the decryption will always fail, even using the right passphrase.

This is possible thanks to some information that CZIP X takes from the hard and software setup of the device, thus the decryption of such an archive may fail also if you modify that setup of your device. This explains why CZIP X allows to export the hardware data.

Non shareable archives can be useful in several cases. The following are some examples.

– Example #1: Bob wants to store important documents in a cloud storage.

Bob is a modern professional and he usually stores all his work stuff in a third-party cloud storage service (like OneDrive or Dropbox); however, Bob learned that several accounts of that cloud service have been violated and many files got stolen. Luckily, his account was not compromised but Bob knows what a disaster would have been if that happened to him: he is the responsible for lots of personal data and secret information from his customers and contacts.

First of all, Bob changes the password of his account, the he downloads all his documents to his PC. Soon after, Bob begins to use CZIP X to create a non shareable archive for each group of documents; he also exports the hardware data from his PC to a USB stick that is put in a safe box, then he uploads all the encrypted archives back to his cloud storage account. Finally he deletes all those documents from his PC.

Mike, the hacker that firstly got into the cloud storage accounts, violates again the service and this time Bob’s account is also involved. When Mike gets access to Bob’s account meets a list of files with the “.czx” extension: he downloads and analyzes them only to find that they are encrypted archives made with CZIP X. Mike reads the CZIP X documentation and discovers what “non shareable archives” are. In order to violate those contents, he should:

  • know the right passphrase;
  • use the hardware data taken from Bob’s computer.

Mike doesn’t know any of the above info. He might try a brute force attack on each archive but he’s aware of the kind of problems:

  1. each attack would require a lot of time for each encrypted archive;
  2. the combinations to try out are multiplied because CZIP X has used the hardware data from Bob’s PC and Bob himself has used  complex passphrases with value higher than 65 – which is “Good” for CZIP X.

So Bob will stay safe: his files have been accessed by an unauthorized person but the contents are protected in a truly efficient way. Mike got those files but they are useless for his scope because he would need a huge amount of time to decrypt them.

– Example #2: Bob and Alice shares encrypted archives between them because they trust reciprocally.

Bob and Alice are co-workers that both think that storing work-related documents in a cloud storage is not so safe; however, their friendship dates back to the era of the primary school and they blindly trust each other. Both install CZIP X in their digital devices and start creating encrypted and non shareable archives from the documents of the coworker. So Bob uses his own passphrase to encrypt Alice’s documents and Alice uses a different passphrase to encrypt Bob’s stuff: one will ask to the other to decrypt an archive when it will be necessary to pick a document. When they stop encrypting data, they export the hardware data of their devices, then they share the encrypted archives but not the files with the hardware data (the files labeled “HwInfo.czkey”). As an additional layer of safety, Alice makes a copy of Bob’s archives and put them in her smartphone.

Unfortunately, while traveling abroad, Alice’s baggage (with her notebook inside) doesn’t reach her at the airport and gets lost. That notebook had all of Bob’s encrypted archives. Suddenly back home, Alice tells Bob what happened but, luckily, she had a copy of those archives in her smartphone. The two colleagues connect the smartphone to Bob’s desktop computer at home but they fail to decrypt the archives using Alice’s passphrase because those archives were non shareable, too. Bob reaches their workplace and gets Alice’s USB stick from the safe: the USB stick is holding the “HwInfo.czkey” file that Alice exported before from her lost notebook. Back at his home, the two colleagues try again to decrypt the archives using Alice’s passphrase. The first attempt fails, then CZIP X asks them if they want to retry by importing “HwInfo.czkey”: they load Alice’s HwInfo.czkey file from her USB stick and they can proceed to decrypt all of Bob’s stuff held by Alice.

As an additional task, they could make new encrypted archives from Bob’s documents on Alice’s smartphone so they won’t have to import the hardware data file again in the future.

– Example #3: Tom wants maximum protection for his documents, also when he’s traveling around the world.

Tom is always on the move and he uses to collect documents and info from his own customers. This stuff must be kept truly private because Tom is responsible for those data and he has to do everything to keep them safe; however, he knows very well that keeping the data in his smrtphone must not be a smart move because he could lose his device or somebody could steal it. Also, Tom knows that keeping encrypted archives in the same device that generated them could be unsafe, even though he would use strong passphrases. That’s why Tom has planned to protect his work in a sharp way: when a metting ends, he creates an encrypted archive with CZIP X and set the archive to be both not shareable and self-erasing; he creates a QR-code to decrypt the archive. He has already exported the hardware data of his smartphone to the “HwInfo.czkey” file and he saved it in a small USB stick that he always carries together with an adapter for the smartphon – a copy of that file is also stored elsewhere at home. After encryption, Tom sends the archive to a secondary e-mail account, one that is not accessible by his smartphone but only from his desktop PC at home; in fact, each time he travels back home, he uses that PC to download all those e-mails with the encrypted archives made during the journey. Obviously, he can’t decrypt those archives directly with CZIP X on his PC: he connects the USB stick to the PC and uses the “HwInfo.czkey” file every time that CZIP X requests it.