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?
What OSS alternatives(multi-platform: win/mac/lin), if any, to zip,rar,etc are available?
[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.
wow. obviously, for windows the gnu zip (gz) is available, as well as for Mac/Linux/BSD natively. Secure? encrypt it with PGP or GnuPG. Problem solved. I'm sure a plugin can be written for the lazy, though.
In SOVIET RUSSIA... erm...NSA AMERICA, the Internet logs onto YOU!
Can't Winzip handle tar and gzip? Isn't gzip fairly cross-platform?
all of those companies who run brute force zip password cracking.
otherwise its a great idea, albiet way too late, pgp and others have been out for a long time. pkware should have had encryption from day one, instead of simple password protection.
RAR!
C'mon seriously, people still compress things in zip?
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)
load .zip file onto a unix system, delete all other traces of original archive.
chmod 000 file.zip
Everyone ignores patents anyway. It doesn't matter if they get a generic patent on any 'secure' compressed format because they'd get their arses kicked in the courts!
Bash script for FP whores
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
trying to think of a drunken pk haiku
if our man were here
he'd be asking for a beer
not a secure zip
i'm a dumbass
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 guess we won't be seeing a free Linux version any time soon either. Not that we need it, GPG does a good enough job at compression and multi-platform compatibility to make this completely unnecessary.
Now that's getting broke
its piss poor english at best.
I write code.
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
The best zip program for Windows is FilZip. IT'S FREE!!!! It also supports ace, arc, arj, cab, gz, lha, jar, rar, tar, AND it has strong encryption (AES)
There's also a Usenet thread about encrypting archive programs including some modified Zip programs.
If they get the algorithms patented and licence them out to everyone else, what will happen? Well, let's look at some past case studies - namely, the .gif fiasco. Unisys tried to ching-ching-cash in, and where are they now? Everyone will just swip to .tar.bz2.
Note to M1-ers: a curt but otherwise insightful message is not "Flamebait" or "Troll".
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
C'mon, we all know that the correct way to say this statement is:
"now that's getting borken"
(with mad props and shout outs to the Opera folks)
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.
One company governing one extension is no way to run the world. Microsoft used these same principles to take over the computing world. What comes next, PKWare trying to put WinRAR and WinACE out of business for using compression technology that is vaguely related to there own? Stop them now before they start asserting power gained from such a patent.
</rambling>
And why did you staple the trout to the RAM?
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 believe there is prior art from the folks who brought us CuteFTP, in their CuteZip product. Strong crypto with Twofish. (At least as far as strong crypto on zip goes....) Also, they have a handy self-unzipper for that format, so compat isn't an issue..under windows anyway.
http://cuteftp.com/cutezip/
Thoughts?
I was wondering. Why do some still insist on 3 letter extensions? Doesn't windows support extensions that are longer and more descriptive than 3 letters?
You have two years from when you 'announce' before you have to file a patent. So if PKware announced encrypted zip, and then WinZip also implemented encrypted zip, PKware can still file a patent.
autopr0n is like, down and stuff.
Encryption and Computer Security art units are about 3 years behind in applications. Figure about 6-12 months after the app. is docketed, so about 3-4 years maximum, 2-3 if pendency is alleviated. By that time, it might be too late.
People working on secret project. Send sensitive files in.. Encrypted .zips.
.zip cracker!).
The ones you can crack in 4 hours at most.
Why? "everyone has zip" and "it's good enough" (Yes, indeed! Evil hacker people who intercept your e-mail on the internet through a myriad of complicated hacks and deceptions will never think to download a
Nevermind that everyone has Outlook [other S/MIME mailreaders available], and that for all it failings, it does a pretty good job of strong S/MIME encryption using X.509 certs..
Gotta love ad-hoc cubicle solutions to the world's problems.
SCO employee? Check out the bounty
BULLSHIT. PkWare gets this patent, and not two seconds will elapse before Aladdin Systems licenses it for use in their StuffIt program. That's because they will need to support the format in order to be relevant.
As for free software, you'll simply download a patch that says, "For educational purposes only, do not use without a license from PkWare." And guess what people will do.
On the other hand, how 'bout someone in the free software community invent a better compression algorithm that includes all kinds of encryption and other services that nobody's thought of yet, and distribute it everywhere...
Understand unique doesn't have to mean "no one else did it." All it has to mean is "THIS is how WE did it and you can't do it OUR way without paying us." This is how MPEGLA can make people pay for using MPEG - even 'tho there's a thousand similar ways to do it, most of them don't interoperate without making use of that IP.
If your goal is to protect an invention, patents can do it. But they can also protect a standard. It's called a design patent - and that's what this is about.
OMFG -- USE TEH PACK
/BIN/SH FOEVAH!
IT MAKES LITTLE "z" AT THE END OF THE FILE AND ALWAYZ WORKS BEST1!!!!!
ONLY N00BZ DON'T USE ex
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.
I haven't used one of their products since I used DOS. *cough cough*
Now all we need is PKWare suing Winzip for patent infringement and we'll have poor Phil spinning (sloshing?) in his grave!
This attempt to "embrace and extend" what was previously an open format is pretty sad. I'm sure Phil Katz is spinning in his grave, since he created PKware to market his alternative to System Enhancement Associates' .ARC format. The .ARC extension had been in use since just about the dawn of time, but SEA sued Phil Katz for using it. Thus, .ZIP was born. Now it looks like the company he created is going down the same ugly road as SEA did. And will end up in the same place--penury and obscurity.
WinZip will implement an incompatible encryption, utilities on other platforms will copy it, and WinZip will win the day.
CEE5210S The signal SIGHUP was received.
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."
Can you please explain the whole ^H^H^H^H^H thing to me?
I know it means replace the previous with...
But why? Is there some geek program that uses ctrl-H for backspace or something?
I use bzip2 even in Windows these days. It's just a far superior compression aglorithm (just shy of perfect huffman lossless compression too, as I understand it). It's just too bad that more people don't know about. That goes double for GPG -- it's just impossible to convince most people that securing ANYTHING is worthwhile.
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
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.
Isn't this a dupe from last month?
m l?tid=185
http://slashdot.org/articles/03/06/10/1542216.sht
Can't seem to find the filing. Can somebody please post it?
Ah, this reminds me of when I first was introduced to .zip files, with PKUnZip. Did that run in DOS originally, or was that just my imagination?
Those were the days. Apogee's Greatest Games was in the D: drive, I had no idea what filesharing was, and it took 30 minutes to rotate the map in SimCity 2000 (okay, it froze).
Your XML is not well formed, it should look like this:
You need to quote all attribute values!...interesting if true.
Or perhaps they know more about PKZip's financial state than you realize...even so, its still poor grammar.
BTW, English is capitalized, as is the word starting a sentence. Does pressing the shift key really hurt that much, or are you trying to demonstrate an applied knowledge of piss poor English?
:P
Does anyone know what their patent claims are for this? There's prior art going back at least a decade (although that never stopped the USPTO).
I have an old 5 1/4 Dos floppy disk with a compressed file on it that I can't open becouse I desided to be cute and used a password for it. One that I'd never forget...
and I haven't remembered that pasword sense...
(Actually the file is probably dead by now)
I don't actually exist.
I believe that NO because introducing redundant bits (aka S-Boxes eliminates bits carefully) doesnt go up the strongless of encryption.
WinRAR + GOST (method of secure & strong encryption from Russia more easier than TripleDES)
open4free
Most people who Zip now-a-days doesn't use new versions of PKzip. They either use an old shareware version, winzip, or the version built into Windows XP.
The founder of PKWare is dead. Maybe it's time for the company to die as well.
...and not just obvious to a skilled practitioner, but done every day. On a command line or with a script.
`gpg -se -r Bob swiss_numbers.gz`, etc.
Katz, PKWare, Alladin, et al. have been doing for years under an open spec. Any hint of a claim is long, long gone. What a joke.
--rgb
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.)
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
Filesystem development on Windows NT (2000, XP, etc) is economically unfeasible. The headers necessary for developing file systems on NT (called the "IFS Kit") cost $1000.
Will I retire or break 10K?
That's exactly what Unisys did (and continues to do in territories where counterparts to U.S. Patent 4,558,302 have not expired) with the LZW compression in GIF.
Burn All GIFs
Will I retire or break 10K?
PKZIP is perhaps the poster child for the idea of "de-facto" standards. The main reason the zip format is so universal is not only that is was open, but more importantly that it caught on. It's popularity is what mandated it's adoption by others.
However, how many people use the *actual* PKZIP anymore? In Windows most people use WinZIP (or one of its many clones) while most unix-ish systems use zip/unzip. I think what PK does to the format has long ago lost any relevance. If a major player like WinZIP announced an open encryption format of their own I'd expect now days more people would support that over PK's now proprietary stuff.
This is what MIME is for. Rather than adding yet more incomprehensible 3-letter codes on the end of filenames, why don't we use slightly-less-incomprehensible MIME coding in the filesystem metadata?
Think something (under UNIX) like:
$ ls -t filename
file image/jpeg
More and more filesystems support it, as do some other apps. I seem to remember talk of internal MIME type tracking being possible in WinFS (the SQL-Server based MS filesystem for their newer OSes) and maybe even NTFS, as well as in Reiser4, Ext3, maybe reiser3, and no doubt others.
The file extension is the horrible legacy of the MS-DOS 8.3 filenames, and we'd be well rid of it. I'd expect a LONG transition period though (file ext commonly used, but MIME type understood, always used where supported, and considered authorative) - yuk.
Gzip is all well and good, but as you point out only does half the job. Tar /could/ be used for archiving, but I'd prefer a format not designed around the concept of linear tape archives myself.
Perhaps something with indexing and the ability to be CLEANLY EXTENDED for more file attributes in the future (MIME type, etc) so that they could be ignored if not undersood?