Slashdot Mirror
Attacking WinZip AES Encryption
bden writes "As another tidbit from Bruce Schneier's Crypto-Gram, remember back in
January when WinZip was Slashdotted for moving forward with its new
AES-based encryption technology? Everything sounded good
since we all knew that AES is secure, right? Well, a cryptographer
took a look at how WinZip uses AES and found lots of problems.
Regardless of how many people actually plan to use WinZip encryption, the lesson, according to Schneier, is that "cryptography is hard, and
simply using AES in a product does not magically make it secure."
So how can we distinguish between an application that simply uses
the right buzzwords, like AES, from an application that is actually
secure?"
More buzzwords!
Seriously, however, perhaps the best ways to have a secure product are to examine the implementation yourself, or try to attack it yourself, or wait for those who know more than you to do the same, and read about it.
Yeah, its pretty sick when you can play with a previous working key and "make it fit". That might work on my 10 year old Toyota, but should NOT work on my secure data. Is this due to carelessness, though, or do we need better random generation capability to stop that threat? I remember seeing this before:
t angle/rng/
http://www.quantum.univie.ac.at/research/photonen
Basically, is it the coder's fault or the computer's fault? Maybe both?
Seeing as winzip got slashdoted previously and I dont know if they have upgraded I put up a couple of quick mirrors:
/ aes_info.htm d u/users/tkohno/ p / is at http://mirrorit.demonmoo.com/r_476/www.cse.ucsd.ed u/users/tkohno/papers/WinZip/
The mirror of http://www.winzip.com/aes_info.htm (the winzip page on AES and its implementation in winzip) is at http://mirrorit.demonmoo.com/r_476/www.winzip.com
The mirror of http://www.cse.ucsd.edu/users/tkohno/ is at http://mirrorit.demonmoo.com/r_476/www.cse.ucsd.e
The mirror of http://www.cse.ucsd.edu/users/tkohno/papers/WinZi
Note to Mods: When I post mirrors, it's a best guess. I don't know for certain whether or not the site will go down!
Or we simply accept that everything is unsecure and uses something that seems kind of secure. Even though I hate the thought of the government watching me, I don't have anything that is so secret I need all this encryption.
And in turn you validate one of Gates' excuses, "The larger the user base, the more attractive it will be to attack it".
There is a difference between branding and what it does.. Wasn't AOL contributing to Firefox/Mozilla/Netscape for a short while.. Does that really make it dirty/insecure in your eyes?
Then again, why am I trying to talk sense to an elitest?
Before I use any cryptography product, I usually check the Russian Password Crackers website, to see if there is any known attack (no link, you'll kill the site). If the listed attack is "plaintext" stay away... Yea, my assumption is that someone who knows more about cracking encryption has looked at the product, and that it has been out long enough to discover the problem. You can get the idea of what companies employ crpytographers and which ones use the word as a marketing gimmick.
That seems unlikely. What seems more likely is that they were trying to preserve more compatability with the Zip format by leaving the metadata unencrypted. I think everyone is being too hard on the WinZip guys. If you read at least the introduction half of the paper, you'll see that these mistakes are not completely obvious, and WinZip has been apt to correct their mistakes in the past. I suspect we'll see a new version of WinZip with these new mistakes corrected shortly.
Sure, it's aggrivating at times, but it leads to less implementation problems when done right. UNIX apps (and open source apps in general) seem to build off each other, so that if one thing implements its job correctly, it just calls the other app to implement that apps functionality.
Take for example Thunderbird + Enigmail + GnuPG. It offers example of apps building on each other to add value. If Winzip had simply appealed to GnuPG or another proven encryption application then these implementation issues would have been less likely to occur.
The tradeoff is a more compilcated install, and I guess that's where the rub is....but encrypted zip files would generally be for advanced users anyways. Sure, we want everyone to use encryption, but lets face it...the general public is a long way off from ever doing that.
Doesn't this violate the DMCA or something? I don't want to get this guy in trouble, I'm just trying to figure out if this is the kind of research I'm allowed to pursue in an american university.
Would have been interesting if he discussed the subtle flaws in IPSec or another more widely respected protocol.
You don't run Windows if you care about security. Mods, do what you must, with your closed source unaudited unoperating system which is probably trojaned if you are running an illegal copy...
There are validation programs in which third party laboratories test and inspect systems related to computer security. Probably the most well known of these is the FIPS 140 program, run by NIST and recognized by the US and Canada. A friendlier description is in this FAQ.
Another international validation program is the Common Criteria program. This provides an internationally accepted set of IT security requirements, policies, and procedures for testing.
Use validated software. Buy validated software. Looking at software that isn't validated? Encourage them to look into the validation process. The US government can no longer purchase cryptographic modules that are not FIPS 140 validated. Put similar rules in place at your organization.
Check out our infosecurity industry blog: http://securitymusings.com/
Actually it's not a poor design decision but a stupid feature. They want the file hierarchy within the archive to be browseable without decryption (TFA also briefly mentions that). Zillions of winzip users seem to value that feature higher than protection against such middleman attacks. And the developers, even though they must have a clue, seem to agree.
Similarly, TFA mentions a piece of documentation advising to encrypt all files in an archive in order to avoid warning dialogues about some unencrypted (and thus potentially modified) files. Seems to be viewed as a user experience concern, not a security concern. Quite a shame...
My next comment will be ready soon, but moderators can beat the rush and mod it up early.
7-zip also uses AES with a 256 bit cipher key for it's password protected file option. I store my personal backups in the 7z format, as I've always had a bad feeling about WinZip's zip cipher scheme, so I wonder what issues the 7z's encryption implementation might have.
The ZIP archive compression standard came out probably about 15 years ago (Phil Katz was a programming god despite serious personal problems), and even then it was obvious that the metadata wasn't encrypted, even with the simpler initial encryption algorithm.
Everybody knows that if you want a secure, encrypted ZIP file, you compress the files first (with or without encryption) into a zip file called "data.zip". _Then_ you zip that file into a second, meta, zip file with encryption.
The article points out that metadata isn't encrypted. I mean, this has been obvious for 15 years, right?
You can't just add an algorithm to a program and make it secure.
It takes WORK to make a secure program. I have given a large chunk of my recent free time to get up to speed on crypto. I have been tearing through RSA Security's Official Guide to Cryptography. Basically it's my bathroom reader. The field of crypto is so complex that I doubt that the average user of WinZip fathoms more than just the basics.
LK
"Hi. This is my friend, Jack Shit, and you don't know him." - Lord Kano
It isn't a WinZip vulnurability, but it is mentioned in the WinZip documentation. The exact quote from the article is: But the above is not the major point, it is mostly an introduction to the next point about how missing integrity of self extracting archives can be used. If you rely on self extracting archives, the archive could easilly carry the key logger into your system. So their point really is, that self extracting archives cannot be secure.
Do you care about the security of your wireless mouse?
aespipe is a fast lightweight UNIX solution that is simpler than GPG:
http://loop-aes.sourceforge.net/aespipe/
There is an established UNIX solution which is not restricted to AES, and doesn't look like it's written by amateurs - mcrypt.
"Don't try to create new algorithms. We know how to do that already. What we have is secure. What you need to work on is the implementation. Just because something uses encryption, it is by no means secure."
I hope you've misquoted him.
Personally, I know of no provably secure means of encryption and decryption [de-encryption]. I know that it is widely believed [although I don't know whether an infrastructure is in place within which it could be proved] that one time pads are secure, but I don't know of anyone who's proposed a way secure means for the distribution of one-time pads, and, for that matter, there's a rather old and rather contentious controversy as to whether one-time pads can even exist in the first place [Google on God does not play dice with the universe].
As for the standard encryption and authentication techniques, to the best of my knowledge, it is still an open question as to whether there are holes in Rivest-Shamir-Adleman; specifically, to the best of my knowledge, it is an open question as to whether third-party decryption of Rivest-Shamir-Adleman is as hard as the factorization problem itself.
And even if you assume that third-party decryption of Rivest-Shamir-Adleman is as hard as factorization, it is still, to the best of my knowledge, an open question as to whether factorization is a hard problem, at least on classical Tukey/von Neumann machines. [It is known that factorization is not necessarily a hard problem on a class of theoretical machines which do not yet exist in practice.]
So anyone who says "What we have is secure" is either incompetent to practice in the field [which, I suppose, does not necessarily determine the competency to teach about the field] or has been misquoted.
To the contrary, anyone who is honest about the state of affairs within the community of encryption artists will tell you, "We have a collection of algorithms that are widely believed to be secure, but I can no more prove to you that they are secure than I can, for instance, offer you a proof of The Existence*."
[*FYI: It is a little-known fact that Kurt Gödel believed he was in the possession of a proof of The Existence towards the end of his career...]
Not every company offering secure programs wants their source code floating about the internet...
And I should care exactly why? If companies cannot deliver secure software without releasing source code, then they had darn well better release their source. Their preference is irrelevant to that decision.
(Note, pedants, that I said "if" security requires source code release.)
I'd rather have the word that a piece of software is secure from a professional like Bruce Schneier rather than an Open Source zealot who skimmed over a copy "Applied Cryptography" in their local Borders.
Well, I'd rather have the authors of OpenSSL, OpenSSH, and FreeSWAN review my code than some overpaid consultant who skimmed over a copy of "Applied Cryptography" in their consultancy library.
Of course, it's a bit more likely that I'll get the OpenSSL/OpenSSH/FreeSWAN authors to review my code than it is that you'll get Bruce Schneier to review yours.
In Windows, it is better to use WinZip, since so many people are accustomed to it. Also, Windows XP supports Zip files, but not tar.
Gnu Privacy Guard is the most peer-reviewed of the encryption programs, I think.
The goal is usually to transmit one compressed file safely that encloses all the files needed to be transferred, and then use those files from within the enclosing compressed file. The value of WinZip is not just in compression, but in providing 32-bit CRCs that WinZip uses to give error messages if files are corrupt. If there are no error messages after testing with WinZip, then we know the transfer was successful.
Another factor that is sometimes useful is that WinZip also supports TAR and other methods of compression and binding files together.