Slashdot Mirror
PKWare and Winzip Reach A Secure Zip Compromise
richard_za writes "Until now the rival compression software vendors PKWare and Winzip have had different (incompatible) ways of password protecting the ZIP format. In a bid to prevent fragmentation of the standard they have agreed to have their software support opening of the other's files. They have however not agreed to support a single standard. PKZip's encryption is RSA-based while Winzip use an AES approach which is fully documented here.
The Register is running this story. PKWare has this press release."
if either program opens the others files the user wont (and shouldn't have to) give a shit which method is used.
"As long as it works"
You can't expect to wield supreme executive power, just because some watery tart threw a sword at you
Zip file management has virtually been absorbed into both Windows and Linux, and even if these two vendors agreed on a standard it would not mean much. PKzip became irrelevant when Infozip's portable zip tool became widely available, around 15 years ago. Further, all archiving tools today already deal with such a variety of formats that I can't see the crying need for a standard.
Ceci n'est pas une signature
Since the PKZip guy killed himself?
There is still a problem with interoperability at the level of creating encrypted ZIP files. There is no longer a problem with interoperability at the level of reading encrypted ZIP files. The best way for this problem to go away would be for PKWARE to expand the SecureZIP standard to include RSA and AES encryption.
Old zip-encryption used three internal 32-bit keys - which by today's standard is quite easy to break. You need 11 bytes (or was it 14?) of known cleartext though when searching.
The breaking of zip-encryption was considered to be quite a feat when it happened in the middle of the 90's, if memory serves me correctly.
it's in my head
I doubt that PKZip is based only on RSA. RSA is an asymmetric encryption. For some purposes this is nice, but it is inefficient. For that reason you almost always use asymmetric encryption together with a symmetric encryption. You generate a one time symmetric encryption key. The data is encrypted with the symmetric key, typically in CBC or CFB mode. Then only the symmetric encryption key is encrypted asymmetrically, which means much better speed.
Actually I think this is one of the cases, where there is no need for asymmetric encryption at all. So AES sounds like a better idea. Can anybody explain why PKZip use RSA? And which symmetric cipher is it combined with?
Do you care about the security of your wireless mouse?
7zip is pretty cool - much better compression than ordinary zip. So I wonder if 7zip will support PKZip/WinZip encryption... From the looks of their fileformat page, they support AES encryption... :)
Oh yeah and 7zip is under the LGPL license
Any technology distinguishable from magic, is insufficiently advanced.
They should name the one ecryption scheme:
Zip-a-dee-do-da
and the other encryption scheme:
Zip-a-dee-day
They could even create new encryption algorithms based on finding the primes of "supercalifragelisticexpealidocious" in various base-N counting systems...
Ooohhh.. what fun. Makes me want to dance on the rooftops with a bunch of chimney sweeps, seeing songs about PKWare and WinZip... Next thing I know, I'm going to get hired as a Window cleaner...
BTW, the same doesn't quite hold true for PGP/GPG users because they use a key that includes much more entropy than which is derived from the password. Also, the password itself is useless in generating the key. If they choose lame passwords (or none at all), you'd still have to steal their key.
I have PGP to encrypt the zip files.. This software has recieved a lot attention and we know that it's probably okay!
The new standard these guys may agree will have recieved little public analysis when it is fielded.. Not something to trust at all!
Simon.
I couldn't care less about WinZip. WinRAR came in version 3.30 today, for the same price as WinZip and a lot more features. IMHO, it would be better than WinZip even if it didn't support RAR, simply from its arhiver support and features. :-)
:-)
:-P
That it happens to use the superior RAR format makes the decision easy for me. We're installing it at our company too, since it isn't even a hard to use archiver for geeks in any way. I know about for example bzip2 and 7-zip, but 7-zip still seems like a rather immature archiver, although it's interesting. The problem is the lack of a good feature set besides the core archiving part. And the official bzip2 package compiled for Windows doesn't come with a GUI so that makes it a bit less useful to me at least, especially when RAR has a comparable compression ratio. Sure, I can use a command line archiver, but I wouldn't like to.
The only downside I can see is that RAR is a closed source format, with only the decompressor being open.
Sometimes, I think it's better to not have two different companies trying to get control over a single format.
Beware: In C++, your friends can see your privates!
My passwords are usually >16 characters long, some are more than 30 (depends on the strength of the algorithm they're used in). While I agree that a lot of people use easy to guess passwords, the old zip encryption was most easily broken through the internal key - NOT by brute forcing the password. Do the math if you don't believe me ;)
A-Z,a-z,0-9 and a few special chars makes a 24 char password contain 128 bits of entropy. That's secure enough for everyone using symmetric ciphers.
it's in my head
I don't really see why it makes sense for zip and unzip programs to care about encryption. If you want to encrypt the whole archive, it's simple to use GPG on the whole thing. If you want encryption on a per-file basis - again, use GPG on individual files before or after archiving. This is true on Windows too, using whatever your preferred GUI encryption program might be.
The only reason to stuff both functions into a single program seems to be the perennial problem of installing anything on Windows systems (you can't assume that an encryption tool is available) and marketing - why should users pay $20 twice for two different pieces of tacky shareware when they could pay Winzip $40 for one?
-- Ed Avis ed@membled.com
As plugins to existing applications are so popular these days, I see this issue as an irrelevance.
/path -Bxvf -
Both sides are competing using incompatible creeping featurism. Last I looked, Zip applications where supposed to combine and squash files (and that was enough).
What should be done is to separate the operations:
- file browsing (WinRAR's interface trumps both)
- archiving (combining files)
- compression
- encryption
and implement the latter three as functions of the first using plugins (and let the user choose).
Incidentally, Zip's file format (directory last) sucks. It is practically impossible to do the following using zip:
tar Bcf - . | gzip -1c | rsh -n over_there gzip -dc | tar -C
To this end, plugins suggested above should be written as filters where possible.
I have no problem with browser-like interfaces combining other functions, but the Golden Rule still stands: One Tool, One Job.
A very dumb company I once worked for chose pkware to archive (and sell) many terabytes of text and images. Unfortunately this was done through a binary only pkware library (for SCO but running on Sequent).. This decision was made around '92 (when many superior alternatives available), before my arrival.
In the mid-90's they wanted to migrate off of their crap sequent boxes to something better.. Unfortunately, pkware refused to accomodate them by porting the library version to SGI.
The company was in a bit of a panic as the sequent gear was no longer a viable solution. New customers and scalability problems were rapidly increasing..
I suggested that they simply decompress on the Sequent and re-compress on the SGI with a better algorithm (source). Forget using pkware. The migration could have been automated such that customer requests resulting in a de-compress would re-file the data in the new system. Requests would check the new servers first. Pretty simple. Batch conversions could occur during off-peak times.
Nope. Too easy. That would not have been a sufficient crisis.. People would not have looked busy enough.
The amount of money they were offering pkware finally became sufficient for them to do a version for SGI. So they kept using pkware.
Oh yeah.. They re-hired the guy who originally decided to use pkware (as a consultant).
A little off topic, but it would be nice if the decided to start supporting unicode filenames in Zip files. With unicode becoming more common in OSs ( this inclues MacOS X, Linux and MS-Windows), I find it ridiculouse that this doesn't even seem to be on their scopes. Well at least it seemed that way when I contacted PKware.
Jumpstart the tartan drive.