Is there a installer out there, such as InstallShield, Wise or any other, that lets me perform the compression (any format) on an encrypted file, if I give it the passphrase that I used when encrypting the file?

Basically, I have a bunch of files that are already encrypted (and they need to be encrypted) that need to be compressed before deployment so the installer package is smaller, so maybe there is a ultility or installer that lets me compress a cab file or something if I provide the passphrase?

I read the other topic, but it didnt answer the question I needed.

Thanks for all the great people here trying to help.

perhaps I should go into more detail here...

my software has a viewer of office documents. Its built into Office. My software comes with really, nice Word Tempates which I want to protect from "copiers" so the legitimate people dont suffer, the software/viewer displays the thumbnails to the user, when the legitimate user tries to open a tempalte, my running "service" decrypts the file and opens it with no problems.

now ALL the Word Doc Templates I provided are all encrypted. They still show the .doc file format, like Template001.doc You cant open this without the viewer. if you have the viewer, then you have access to all the tempaltes.

due to non compression applied to my doc files, my installer is 500MB If they werent encrypted, the installation using LZMA is 10MB you can see a huge difference right there.

so I need to keep each doc file encrypted(and leave it still as the the same file extensiton) and have the installer compress the files using LZMA.

Any ideas now?

thanks DC


Sadly, No. Encrypted files look like random noise, and there's no way to compress random data.


As Zach said you can't really compress encrypted data ( you might get 1 or 2% compression if you are lucky).

The proper way to handle this would be to decrypt the data, compress it, then re-encrypt that compressed archive.

  • 1
    I think that is what the questioner is actually asking for something to do when he mentions "if I provide the passphrase". I'm guessing that such a facility does not exist in common tools as it isn't something that is going to be needed by many and Murphy's law suggests that it would most likely support encryption utilities other than the ones you use if it did exist! You might be able to write your own plugin for one of the customisable/extendible install set generators though. Dec 1 '09 at 19:16
  • Right, but he is (if i'm reading his post right) trying to create an installer for a set of files that he a) already has b) has the passphrase/private key to c) given the above possibly has access to the original source files. The only way to achieve what he wants - a compressed, encrypted archive is to compress, then encrypt whether that is de-encrypt temporarily and compress, or compress the source files.
    – Zypher
    Dec 2 '09 at 5:01
  • Thanks David and Zypher. I rewrote some algos and now I am compressing and then encryting.
    – DevCompany
    Apr 24 '10 at 16:55

Depending on the encryption software you are using, there may be an option for to compress as well as encrypt. What encryption tool are you using?


As mentioned, encrypted files don’t compress well (if at all).

One option you could try is to decrypt the files, then use an archiving app like 7-Zip or WinRAR to compress them, and use the tool’s built-in encryption function. In fact, modern version of such utilities not only allow you to encrypt the files, but even the filenames, so that the archive is truly opaque without the passphrase.

These utilities also have the ability to create self-extracting archives, usually with various levels of functionality (eg creating shortcuts, running scripts, etc.), thus allowing you to create a compressed and encrypted installer.


Why not just encrypt compressed files instead? That should work.

Seriously, if your encryption algorithm is sound, you shouldn't be able to compress it at all, because there shouldn't be repeated bits, or not-obviously-random stuff. If you get even 1%, then that means your crypto algorithm is unsound and could be crypt-analysed.


I think your requirements if I understand them correctly are:

  • the files should *always* be encrypted when stored on disk?
  • the files in your installation package should be encrypted too?
  • the files in your installation package should be compressed?

Perhaps one way to do this could be to:

  • create an encrypted volume, eg using truecrypt, or cryptfs, or Microsoft Encrypted File System
  • decrypt the encrypted files into a folder on this volume
  • run the packager against the files in this folder, compressing them, then re-encrypting them on the fly

A variation on this if your packaging solution doesn't itself support encryption and so on could be to:

  • decrypt your encrypted files into a folder on an encrypted volume, as for the previous potential solution
  • compress them inside the encrypted volume, eg using winzip or similar, to a single archive file
  • create a new encrypted volume, eg using truecrypt, just large enough to hold the compressed archive file
  • copy the archive file across to the new volume, and unmount it

Now you have an encrypted compressed volume containing the files you need. Next step, to create your installation packager:

  • add truecrypt or similar to your package
  • add the encrypted compressed volume to your package
  • add a script into your package, eg inside the .msi add a custom script, that will mount the encrypted volume using truecrypt then install the files from that volume, doing any re-encryption on the fly as appropriate
  • Nice Option...I will evaluate this as well.
    – DevCompany
    Apr 24 '10 at 16:56

You need to apply compression BEFORE encryption.

"my running "service" decrypts the file "

If all encryption is done by your program or "service", you just need to apply compression before actual encoding. It is a common technique, and will increase safety too.

The easiest is compression using zlib.

If you use some encryption service from other people/company, please say us name of this service.


Why not do a base64'd on the encrypted data and then compress it? Sounds lame but at least you will have a lot of letters and numbers which can be in turn, compressed. That is my theory, have not tried it that way.

Hope this helps, Best regards, Tom.

  • That just wouldn't work. At best, you'd get the same size as before. At worst, your resulting file would be bigger than the original encrypted file. His best bet it to compress the data before it gets encrypted in the first place. Dec 2 '09 at 2:40
  • That would definitely not work. Based64 encoding would make it 33% bigger and then the compression might reduce it back to only slightly bigger than the original. Useless.
    – MarkR
    Dec 2 '09 at 7:54

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.