Slashdot Mirror
PKWare Files a Patent Application for Secure .zip
prostoalex writes "The battle of ZIP formats might intensify as PKWare filed an application with USPTO to obtain a patent on its Secure Zip technology, which pretty much involves archiving with strong cryptography. If the patent gets granted, PKWare will license its algorithms for other software manufacturers. A representative of Aladdin Systems summed it up: "The good thing about the .zip file format was that you knew you could send it to everyone. Now that's getting broke.""
zip & use pgp even better use bzip2 and pgp
secure and compressed
-- everyones not everybody and neither is everybody like everyone.
For those too young to remember - PK are initials of late Phil Katz, the original author of PKZip, a pretty unusual character. Here's a link about how he died.
AFAIK the company is now run by his mom pretty much.
grisha.org
It's important to note how the strong encryption
... etc ...
differs from other pkzip crypto methods.
A zip45 file begins with:
central file header signature 4 bytes (0x02014b50)
version made by 2 bytes
version needed to extract 2 bytes
general purpose bit flag 2 bytes
In a zip file, if the GENERAL PURPOSE bit flag is set
(bit 0 of the 2 byte field) it means the file is encrypted.
The PKZIP encryption scheme was designed by Roger
Schalfly, who is evidently the son of the famous
(1980s anti-women's rights) republican spin mastah
Phyllis Schlafly. But anyway.
Each encrypted file has an extra 12 bytes stored at
the start of the data area defining the encryption
header for that file. The encryption header is originally
set to random values, and then itself encrypted, using
three, 32-bit keys. The key values are initialized using
the supplied encryption password. After each byte
is encrypted, the keys are then updated using
pseudo-random number generation techniques in
combination with the same CRC-32 algorithm
used in PKZIP and described elsewhere in this document.
The following is the basic steps required to decrypt a file:
1) Initialize the three 32-bit keys with the password.
2) Read and decrypt the 12-byte encryption header, further
initializing the encryption keys.
3) Read and decrypt the compressed data stream using the
encryption keys.
For step one, you jack up your karma whorin' by pasting
the following key sets:
Key(0) > 24)
end update_keys
In step two, often associated with total karma whorin',
one also (*cough* karma whore) loops through the
buffer with:
loop for i > 8
end decrypt_byte
After the header is decrypted, the last 1 or 2 bytes in
Buffer should be the high-order word/byte of the CRC for
the file being decrypted, stored in Intel low-byte/
high-byte order. Versions of PKZIP prior to 2.0 used a
2 byte CRC check; a 1 byte CRC check is used on
versions after 2.0. This can be used to test if the
password supplied is correct or not.
In step 3, we continue to blatantly violate copyright laws
while whorin' karam with:
loop until done
read a character into C
Temp - C ^ decrypt_byte()
update_keys(temp)
output Temp
end loop
So that's about it.
Everybody, start using the (open source) 7-zip instead.
No kidding. It amazes me that a lot more people don't use this - It handles all the major formats (zip, tar, gz, bz2, cab, no "sit", though) better than the "native" program for them does, and hey, open source to boot. And, its "7z" format really does get 10-30% better compression than even bzip2.
Gotta agree with the other response to you, though - the interface needs MAJOR work. It doesn't "look" bad, but feels very counterintuitive. Hell, if they totally eliminated the psuedo-explorer-esque look and just let me drag-and-drop, I'd consider it perfect.
No, zip makes zip files. compress makes .Z files.
you're both right.. 'encrypted data' doesn't compress well not because it's random, but because it's redundancy is relative to the encryption method and not to specific patterns within text sets, image sets, number sets.. since conventional compression like burrows-wheeler, huffman, gzip, pkzip, etc. are all designed to remove patterns from 'natural' data sets you'll have much poorer compression rates.. but that hardly means the data is not compressible
I would not consider .sit a competitor to .zip. StuffIt is the .zip for the Mac niche. It's the only archive format out there that is sensitive to Mac OS resource forks. For certain types of Mac files (read: most), putting your data into a zip archive will render them useless. Though reliance on the resource fork is decreasing in Mac OS X.
Aladdin writes software handles zip files, too. So they DO care about inter-operability. They have a perfectly honest and legitimate interest in this.
It'd be interesting to see exactly what the scope of the claims are in the patent, since this is a potential threat to encrypted gzip as well.
.zip support is another direct derivative of this Info-Zip code.
How?
Zip and gzip use the same 'deflate' compression alogrithm. In fact, zlib was based on the Info-Zip code, a free software/open source alternative to pkzip, and the GZip homepage specifically credits Info-Zip as where "all this started", and mentions that the decompression code was based on the code of the major author of Info-Zip. And WinZip's
So, gzip, zlib, Info-Zip, and WinZip all share common code from common authors implementing the same algorithm. As a result, it would take a very narrowly-tailored patent to allow gzip-and-encryption without allowing Winzip's zip-and-encryption.
You're partly right. StuffIt was the main compression format until OS X came along, but it's not the only format that preserves resource forks.
Today you'll mainly see .dmg (disk image) format, which features compression, optional encryption, and preserves resource forks. Also common are .pkg (a compressed installer, which can include files with resource forks) and .tar.gz files (I don't think they preserve resource forks).
And some folks still use Stuffit .sit files.
No, I don't want to explore the Recycle Bin.