http://qs1969.pair.com?node_id=404308


in reply to Compressing and Encrypting files on Windows

This node falls below the community's threshold of quality. You may see it by logging in.
  • Comment on Re: Compressing and Encrypting files on Windows

Replies are listed 'Best First'.
Re^2: Compressing and Encrypting files on Windows
by Elgon (Curate) on Nov 01, 2004 at 15:28 UTC
    Tachyon is precisely correct.

    When you encrypt something, the output is highly entropic and there will be no redundancy in the text. Compression works by removing redundancy from the file, so, given that there is no redundancy in an encrypted file there will be no compression.

    See... this, for example. Pay particular reference to the section which states "Compression after encryption is silly. If an encryption algorithm is good, it will produce output which is statistically indistinguishable from random numbers and no compression algorithm will considerably compress random numbers. On the other hand, if a compression algorithm succeeds in finding a pattern to compress out of an encryption's output, then a flaw in that algorithm has been found. In the majority of encryption utilities (e.g., PGP ) the data is first compressed before it is actually encrypted."

    It is better either to be silent, or to say things of more value than silence. Sooner throw a pearl at hazard than an idle or useless word; and do not say a little in many words, but a great deal in a few.

    Pythagoras (582 BC - 507 BC)

Re^2: Compressing and Encrypting files on Windows
by tachyon (Chancellor) on Nov 01, 2004 at 14:45 UTC

    Sorry that is absolute rubbish. First you are completely wrong in than anyone with two neurons to scratch together or even rudimentary investigative skill can show your first premise is complete rubbish. You second premise has nothing to do with the price of fish, or the question at hand for that matter. There is no analogy between tar and either encryption or compression. All tar does is glue files together with just enough header data to split them back into a dir structure and check for corruption.

    I have presented some sample code above. Please experiment with it and follow your own suggestion. Please learn from it as you clearly have NFI.

    As noted you will get >>>>>ZERO COMPRESSION<<<<< if you encrypt first with any decent algorithm. By design an encryption algorithm will turn an infinite stream of zeros into an equally infinite stream of (pseudo)random noise. This can not, by definition, be compressed. This is not a bug. This is by design :-)

    If you can compress your encrypted files I suggest you have a problem with your encryption algorithm.

      Geez, tachyon, why don't you tell us what you really feel?

      It's one thing to say, "sorry, I think you have that backwards, read my post to understand why;" and a completely different thing to use a caustic, abusive tone in every sentence. We've been without Abigail-II for months now, and I like the change in average tone in the community. Let's not blow it.

      --
      [ e d @ h a l l e y . c c ]

        , why don't you tell us what you really feel?

        Because I thought it would get reaped ;-) The OPs post obviously annoyed me. I have no problem with people being wrong. Like most people I spout rubbish from time to time, but I typically have the good grace to add an AFAIK, IMHO, perhaps, maybe or whatever. It was the authoratative presentation of absolutely incorrect information that set me off.

        cheers

        tachyon