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?
[quote] .zip file format was that you knew you could send it to everyone. Now that's getting broke."
A representative of Aladdin Systems summed it up: "The good thing about the
[/quote]
This quote is funny coming from a company that sells a competing compression format (.sit)
"Jesus saves, but everyone else in a 10 foot radius takes full damage from the fireball."
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.
Why not zip and then use GPG?
Only Women Bleed (Sex, Sharia remix)
Hmm, I don't see why this is such a big deal.... bzip pretty much compresses higher than 'em all. That plus, its GNU-free ^_^ zip? I don't really see why encryption was ever a critical feature in the format, (I thought it was a bunch of proprietary schemes to begin with) but I'll continue to use it to send some files.
The replacement for pkzip should be gzip. Not only is it specified in the open via rfc but it's implemented in internet explorer and friends.
Gotta wonder how they got that past the examiner.
.sig
"No no, pkzip isn't prior art... the patent only covers the novel idea of using strong encryption"
-- this is not a
I think all windows Zip software supports tar and gzip.. Why, oh why do people still compress everything with zip? If they want to compress whatever they want, why not use the open standards?
Hell, even the "pirates" and "hackers" are using something else (rar, ace).
I use PGP for just about everything (I have a built in "roaming profile" via PGPdisk) but I don't believe it compresses stuff (if it does you sure can't tell it - a 600MB PGPdisk won't hold more than 550MB before it gets so fragged you can hardly use the CD). You can use NTFS and compression, but that's not nearly as efficient as zip and you can't mount ntfs partitions in read only mode from win2k, so NTFS parts on CD are essentially useless. It's easy enough to install, but then you gotta be comfortable with formatting and all that stuff - where does this leave people who think "explorer" is just "how you get the internet?"
The problem with pgpdisk is it's not pervasive and there doesn't seem to be a well supported fork out from under the thumb of NA. It would be fantastic if there were a lightweight pgpdisk runtime (ie not a 15MB download, with a braindead consumer oriented GUI) available that was supported in the oss community, but I don't know of one.... do you?
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.
Why is it that EVERY person that points out a spelling or grammar mistake makes one themself?
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.
In both cases, the files are essentially concatinated into a single file by the tape archiver (tar) and then that file is compressed using either the gzip or bzip2 utility. While bzip2 is capable of much better ratios, it takes a lot more processing power, and is not nearly as ubiquitous as gzip is.
In some older UNIXes and most Linux distros, there is still the zip utility that makes files with the extension .tar.Z . This is an older format, but it is still being used sometimes.
Just thinking out loud to myself here. I thought good cyphertext is as close to random as possible, and thus can't be compressed. Or can you compress the file first, then encrypt it? I am no expert on this (obviously) so I could be totally pulling this from my ass. Anyone know how this works?
Stupid people make stupid things profitable.
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.
Who would patent just half the method?
I sure hope he didn't mean they're trying to patent the entire concept of encrypting zip files regardless of the algorithm or method. Because I've been encrypting zip files (among many other types) for a decade.
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
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 agree. Encrypted data which occupies the same space as the decrypted data should, in principle, be just as compressible as the decrypted data.
The problem (if it is indeed a problem) is that compressing the data may, in practice, be as hard as decrypting the data.
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.
I've already got and had secure zip files for years.
somestuff.zip.pgp
whoah! what a concept!
The GeekNights podcast is going strong. Listen!
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."
Software alone should be an exception from patents. Copyrights are ok to protect branding but patenting algorithims is like patenting a shortcut for a daily commute. People built cars and roads to you could use them as you wish. Same thought behind people building hardware and compilers.
It's been awhile, but IIRC, the settlement agreement is under seal, and that's a he-said, she-said affair. Of course, back then, shareware was just about the same as public domain in most people's minds, before the rampant greed associated with it started.
CEE5210S The signal SIGHUP was received.
This is a copy of something I posted on this subject on comp.compression: Darryl Lovato wrote in message news:... > Both companies appear to be fighting to be the "owner" > of the .zip file format, but IMHO, the day that Phil Katz
> released the tech specs to the world, the user community
> became the owner of the .zip format.
Actually, Phil Katz quite explicitly and intentionally made both the ".zip" extension and the zip format public domain. He also committed to updating the PKZip application note, which describes the format, as the PKZip product evolved. That promise was kept while he was alive.
Now however, PKWare appears to want to make parts of the format a trade secret, which as you point out completely undermines what makes the .zip format useful in the first place. In addition to the encryption, they have also declined to document the deflate64 format in their application note, despite at least two revisions of that note since deflate64 was introduced. In this case, it turns out to be not very difficult to reverse engineer the format. However the corporate intent is clear. The corporate intent is also self-destructive.
So, now may be the time for the community, in particular the community that reads this newsgroup, to develop an open, scalable cross-platform format that supports archives of directory structures, files, and meta-data, high-quality lossless compression, and high-quality encryption and authentication. "Cross-platform" does not mean "Windows and Mac", but rather as wide a range of platforms as there are contributors. The PNG format effort is in my opinion a good model for this sort of development. (I played a small part in that development.)
A difficulty with this concept is that the development of high-quality compression over a wide range of types of data requires a great deal of time, determination, and expertise--perhaps more so than one should expect to achieve in contribution to a free, open-source effort. Therefore I might suggest a compensation scheme where corporate users of the software would be obligated to contribute directly to the authors of the compression/decompression methods that they use. This would encourage the development of better compression methods over time, in whatever dimensions are of interest to the paying users (space, time, specialized models for specific data, etc.). How it would be decided when to add a new method to the official format is left as an exercise for the reader. Also whether or not to accept methods with patented components, licensed for free use, is left for the reader to ponder. In any case, as much thought would probably have to be put into the business and legal model as is put into the format itself.
I am posting this idea merely to stimulate discussion. I personally don't have the time or inclination to play a major role in such a development. (My day job is both interesting and time-consuming.) But if a good group is motivated to do so, and can produce on a schedule, I'm thinking on the order of 12 to 18 months, everyone will benefit greatly in the long run.
Mark Adler
(co-author of Info-ZIP, gzip, and zlib.)