Slashdot Mirror
PKWare Zips to Growth
Rob Kennedy writes "The Milwaukee Journal Sentinel has a story about PKWare's new business plan. It talks about the investment group that bought the company after founder Phil Katz's death in 2000, and the plan for PKWare to produce what president and COO Timothy H. Kennedy (no relation) calls 'the next generation of zip' by adding various security features."
Might these security features include paying per zip file or something?
When I PGP a file, it shrinks to same or smaller than when I standard zip it. Isn't that secure / small? Or am I horribly confused?
Since a Zip has to be decompressed anyway it makes a lot of sense to integrate encryption. It's easier to unzip once compared to unzipping and then unencrypting or vice versa.
:)
Now, integrate this with email attachments and we're on a roll
.: Max Romantschuk
Most of the files I want to send are not going to compress to well in the fisrt place. Nowhere near enough entropy. The only files that will actually benefit are source code and binary executeables.
Okay, there may be some specialised industry data formats for microchips and the like, but the really large files tendto be things like pictures and videos. These are already compressed using standard lossy techniques. zipping these won't work.
From the article:
PKWare no longer sells its products as shareware.
Is this a good idea? I believe that shareware is the only way to get your product known to all computer users (apart from bundeling it with Microsoft Office). There are not that many computer users that still known PKWare, and when this strategy is followed, that won't change.
One of the coolest moments of the many GenCon Game Fair's that I attended in Miwaukee, WI was when a panel consisting of most of the premiere Origin producers including Richard Garriot and Warren Spector took a question from the crowd during the Q&A session and when the nervous speaker said, "Well I have a programming question...and...um.. well I'm from a little company in town...do you know PKWare?"
And all the members of the panel looked at one another and then started doing the Wayne's World bow and chanting, "We're not worthy! We're not worthy!"
Then Warren (if I remember correctly) made a mildly sarcastic and admonishing comment towards the poor PKWare dude along the lines of, "Hey man you guys have saved us tons of money on media. We use Zip all the time. Of course we know your company." (games of the era were beginning to approach some 30 floppy discs compressed and CD-ROM had not yet become an affordable alternative)
It's nice when a little mostly unkown (at the time) company making software compression utilities gets recognition from a (at the time) powerhouse game development company like that.
Once more unto the breach dear friends...
The .zip format has great inroads into the corporate world, whereas PGP is still a geek's toy. By leveraging (cough) the massive usage numbers, they could be successful with this. Of course, it remains to be seen what features they want to add. But enough zip files fly around corporate networks without security, that it does make sense to improve PKZip in that area.
On the other hand, WinZip has a a head start, as the preferred way to deal with zip files for most people. And the PKWare website seems to come up blank on Mozilla, not an encouraging sign.
But what I really want is security for my PDA data, so it is secure over the network, and secure on the hard drive of any PC, even a PC that others have access to. Can zip help with this? Not sure.
A corporation built on "tar -cf - . | gzip | crypt". And people wonder why TCO for Windows systems is so high.
Hmm. 'Do one thing and do it well' might be a better strategy. There are existing very capable encryption and signing programs you can use on individual files or the whole zipfile; there are plenty of existing version management tools. Let the archiver just archive files.
-- Ed Avis ed@membled.com
Hah. He took the established ARC format, which had copyrighted free-as-in-beer public domain routines in C, and rewrote them in x86 asm for speed... and then sold PKARC (Phil Katz ARC) as a commercial product. The original inventors of ARC sued him and won - he even kept the same misspellings in the strings, for fuck's sake. He settled for a lump sum in court, then ended up making a couple of changes to the ARC format and renamed it PKZip.
That, and if you actually look at the ZIP format, you'll notice that it's all routines invented by other people. "Shrink" is dynamic LZW, "Reduce" is RLE with a second-pass probabalistic encoder, and "Implode" is a sliding dictionary with post-compression using Huffman/SF-tree encoding.
Katz was an excellent promotor and had good networking skills. I admire him for that much, and for establishing a defacto format that scaled nicely to 64-bit sizes and arbitrary-length Unicode filenames. HOWEVER, he was hardly a pioneer in compression algorithm design. Give him credit where credit is due.
Hopefully, if this is what they want to do, they will do better than the embarrasingly insecure "encryption" that the old DOS PKZip included (a cryptographically-weak LFSR-based stream cipher). With good support for cryptographic standards, they could have something here.
By the way, you always do encryption AFTER data compression. Doing it before data compression ensures that your compression ratio is close to 0%.
Qu'on me donne six lignes écrites de la main du plus honnête homme, j'y trouverai de quoi le faire pendre.
For comparison purposes, I downloaded cs94_002.zip and recompressed it with the latest version of WinRAR (3.10 beta 3), set to maximum compression. The result:
cs94_002.rar (Source) 9.4MB (9,407,157 bytes)
WinRAR appears to compress much better than bzip2; however, it isn't free. Interestingly, as good as WinRAR is, even it doesn't come that close to having the best compression ratio out there.
For lots of useful statistics on the relative capabilities of virtually every compression engine in the world, check out Jeff Gilchrist's Archive Comparison Test. A lot of progress is still being made in compression technology, so the state of the art keeps changing.
begin 644
From the article:
/. to come up with a better paragraph than this.
"Eventually his personal problems caught up with him. Struggling with chronic alcoholism, Katz was estranged from his family and often hung out with strippers. He turned into a recluse, often avoiding his posh Mequon condominium and staying in cheap hotels instead."
You couldn't pay the trolls on
graspee
Well the other reason for doing encryption after compression, is to mitigate dictionary attacks. So the cost of breaking in by brute force includes both decryption as well as decompressing.
Yeah, the cipher was pretty weak. Interested people might like to read the paper A Known Plaintext Attack on the PKZIP Stream Cipher by Biham and Kocher. Esentially, a string of 13 known bytes and a few hours on a good PC will decrypt the rest of the file.
But what's even worse, imho, is the horribly bad implementation. They encrypted only the file contents; file name, size and (what were they thinking?) the CRC were all in the clear. If you were using encryption to hide the fact that you possess a file you're not meant to, Pkzip will do you in real nice.
All in all an excellent example of how crypto works not.
Alex
Heisenberg may have been here
Programs that encrypt computer files tend to make the files much larger, gobbling up valuable room on a hard drive or ...
This is bullshit. I do not know of even a single cipher which makes the files larger. Indeed all ciphers commonly used today for file-archiving are block-ciphers which transform a fixed-size (typically 64 bit) cleartext-block into an identically sized ciphertext-block. Examples of such ciphers include DES, IDEA, Blowfish, 3-DES, AES, Twofish and many others.
Combining encryption with data compression is a natural, said Stephen Crawford, vice president of marketing.
The vice-president of marketing is not typically a good person to ask about technical issues. In this case he is correct though, it is a good idea to compress files prior to encryption, this both saves place, aswell as making certain attacks a little bit harder due to more entrophy in the compressed plaintext than in the plaintext itself.
Unfortunately for him this idea is so obvious that it's been implemented in typical encryption-programs for ages. Both PGP and GPG for example by default compress the plaintext priorto encrypting it. This is hardly novel.
This is the most disturbing part of the whole story. I think that PKWare will die a slow and painful death as all the "interesting" ideas get thrown on the floor. Why do companies think that purchasing a successful company and then changing the basics around how they operate will make them grow?!?
Yea, making the company "market driven" is going to work.
KangarooBox - We make IT simple!
Just don't make the filename so obvious man,
C:\ren porn.zip pr0n.zip
they'll never know
Since a Zip has to be decompressed anyway
While until just recently, this was true - now you can create a "ZIP" file that doesn't decompress. The idea is instead of decompressing the files to disk, a tiny user-mode OS is inserted between the application that needs to use the data and the compressed data. The new OS does transparent decompression/decryption and to the application it appears the files reside on the hard drive. The OS provides streaming decompression so only small blocks are decompressed at a time and the memory requirements are very low. Yes, the data is present in memory in unencrypted form at some point so it is possible to hack - but it provides a pretty good level of data security.
The cool thing is that the archive size is usually the same size as a ZIP, but it runs directly with no install and no decompression time. Usually applications load 2x faster in this state.
This is something I've spent the last year working on. Checkout here
-- Virtual Windows Project
...When Katz was in charge, PKWare's programmers often would work on new features that they found interesting rather than targeting specific needs of potential customers, Kennedy said.
"In some cases what they did was successful, but in many cases what they did wasn't anywhere near successful," he said. "The company from this standpoint now is market driven."
The engineers are no longer in charge, money is. All the clueless and stupid "features" that corporate slave drivers can think of will become projects for the Brown Deer survivors. I can imagine them asking for central repositories of file lists, tables of "sensitive" files that can't be ziped, and other silly work arounds the serious lack of data control their w2k desktops have. I can also imagine that half of the "I wanna micro manage my staff to death" initiatives will directly contrardict the requirements for the other half. Sounds like hell if they really have remade the company that way, and sure the customer gets screwed along with the lusers. That's what happens when you put sales in front of engineering.
I could be wrong. Dr. Kelly could be a fine fellow and have no intentions of making this happen. It will be difficult for him to manage the monster he's making. Good luck and never trust M$, the folks that bought 5th Generation Software to kill Fastback and who have always seen backup utilities as a threat and aid to "pirates".
Friends don't help friends install M$ junk.