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.
but I want a secure zipper. So many people are trying to get into my pants it's outrageous.
WWJD.... for a Klondike bar?
It's good to see Aladdin Systems are demonstrating their lossy text compression technology by saying that the ZIP format is "getting broke" rather than "getting broken"
</tongue>
Everybody, start using the (open source) 7-zip instead.
But it's likely that they'll keep using ZIP because of its brand recognition. That's really too bad, but at the same it might frustrate people enough to get them to try another compression format, like BZIP.
seems like a familiar story to me.
I write code.
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
There's also a Usenet thread about encrypting archive programs including some modified Zip programs.
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.
I can't even believe there is any doubt they will receive a patent for this, even if it isn't anything particularly interesting. In fact I'll be presently surprised if the PTO actually recognizes the existance of plenty of prior art. Maybe they don't even need to recognize prior art, just the fact that encrypting a zip file is obvious.
Its insane that you can patent "Doing something someone already did, but doing it to THIS instead of THAT." I can, perhaps, buy an argument that encryption (like the first time anyone did it) was patentable. Maybe even that different algorithms for encryption could be patentable.
But once encryption is there, applying encryption to ANYTHING should not be patentable. A zip file is just data. Encrypting it (or encrypting the contents) is not a novel concept.
So while I would love to see the PTO demonstrate some miniscule amount of clue and reject the patent, I will be very surprised if they actually do.
blog
Ok, I know that ZIP is known for notoriously weak security.
But is it worth a PATENT to now associate the "security" features of ZIP
with "strong cryptography algorithms"?
That's like Microsoft filing a patent for a "not crashing OS", as reaction
to market research reports that show how people are not happy anymore with
traditional (crashing) MS products.
Funny, it sounds like either they already reverse engineered the pkware zip encryption, or established their own encryption.
I wonder how many times users will complain to company xyz (that is using pkware encryption for their products) about their files not working in winzip, before company xyz will drop their pkware proprietary encryption in favor of winzip's published (and functional) encryption.
1. "What we've filed a patent for is the whole method of combining.zip and strong encryption to create a secure.zip file," said Steve Crawford, the chief marketing officer at PKWare. The patent was filed with the Patent Office on July 16, he said.
2.In May of this year, WinZip developed its own method of strong encryption, which incompatible with the PKWare product.
3.Crawford believes that WinZip will be a potential licensee. "The basic approach of combining encryption of.zip is covered by the patent, so what WinZip has done, I believe, would be covered by the patent."
If 3 is true, 2 is clearly prior art. So why patent?
There is something rotten in IP kingdom.
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.
That way, you could always still send either an unencrypted or an encrypted zip - you pay for the ability to encrypt them, fine, but you can unencrypt them easily enough no matter where you are or whose winzip you're using.
It's kinda like Acrobat - anyone can read their files, nobody can create them without buying the utility (blah blah freeware acrobat writers, I know...)
Except that they started out in hell, because their founder ripped off Thom Henderson's ARC to make his original program.
Back in the BBS days, we were all rallied to support good ol' Phil against the evil Big Company, System Enhancement Associates, who was suing to keep Phil's faster PKARC from eating the original ARC program's lunch. BBS sysops were encouraged to boycott ARC. It worked. It ruined System Enhancement Associates.
Except the funny thing is, SEA was right. They won the lawsuit because Katz hadn't just reimplemented ARC, he stole their source code. That always gets left out of the retelling, even though the reason ZIP exists as a format is because Katz was ultimately prevented from using the ARC format and compression routine. The reality is also that even then, PKWare was a bigger company than SEA ever was. ARC was a commercial program, but had a very unusual license (for the time) allowing people free access to the source code if they wanted to port it to non-DOS platforms. Katz baldly abused this license and, in the end, got away with it. ZIP did end up with an improved compression scheme which I presume PKWare came up with, although there's some evidence that the all-but-ignored ARC 7 outperformed it. (PKARC was, IIRC, based on ARC 5.)
Ben Baker has a description of the history of this whole affair at the website of Thom Henderson (ARC's author). Henderson also has his own commentary, which I would describe as "gently acid."