
Attacking WinZip AES Encryption 227
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?"
is this a testament to today's computing power? (Score:2, Insightful)
Re:is this a testament to today's computing power? (Score:5, Insightful)
He then proceeded to explain how easily NTLM can be defeated in a brute force attack.
Re:is this a testament to today's computing power? (Score:2, Funny)
Suddenly the students started listening and taking notes!!!
Re:is this a testament to today's computing power? (Score:2, Insightful)
Pssssst: GnuPG (Score:2)
Secure WinZip: Put files together with WinZip. Then run The GNU Privacy Guard [gnupg.org].
Re:Pssssst: GnuPG (Score:2)
Windows XP supports Zip files. (Score:3, Interesting)
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 m
I hope've you misquoted him. (Score:5, Interesting)
"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 [google.com]].
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 [icm2002.org.cn].]
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...]
Oops - Tukey/von Neumann == Turing/von Neumann (Score:2)
Sorry, I seem to have a mild case Fourier analysis on the brain.
Re:I hope've you misquoted him. (Score:2)
With no way for someone to eavesdrop the key or without showing any vulnerabilty to known types of attack(timed, man-in-the-middle, etc.), it's going to
Re:I hope've you misquoted him. (Score:4, Interesting)
I hope you've misquoted him. Personally, I know of no provably secure means of encryption and decryption [de-encryption].
And now you're misinterpreting him as well. "Secure", "provably secure", and "perfectly secure" are three different things and *YOU* seem to have trouble with the difference. The OP's prof is talking good sense. When it comes to cryptography, companies should stick with using the best common practice rather than trying to invent their own. It's the exact same advice you would get from Schneier.
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
One-time pads *are* provably perfectly secure (in a cryptographic sense), but they are irrelevant in almost every practical application of cryptography. And yet every two bit amateur cryptographer on
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
See this is where you really pissed me off and goaded me into replying. 99% of the people reading your comment already know what RSA is. 90% of them probably know that it stands for Rivest-Shamir-Adleman, but no one actually calls it that except for pretentious wankers who want to appear smart.
-a
Re:is this a testament to today's computing power? (Score:5, Insightful)
What I can't believe is that they would still leave so much stuff unencrypted. A very poor design decision.
I mean, how freaking hard is it to put a flag at the start of the archive saying it is encrypted and then just raw encrypt the rest of the data. That design seems obvious and would be as secure as AES can be (eg. just create a normal zip, encrypt it, add flag/tag at start).
Re:is this a testament to today's computing power? (Score:3, Interesting)
Similarly, TFA mentions a piece of documentation advising to encrypt all files in an archive in order to avoid warning dialogues about some unencrypted (
Fundamental software engineering problem... (Score:3, Insightful)
First, it is the testing problem. For most features, e.g. number of request handled by a database, compression ratio of a video encoding software, the correctness of an accounting package, the test is easier to construct than the software itself. For security related enhancement, the difficulty is about the same (similar applies to stability).
Second, it is the actual developing problem.
The answer is simple... (Score:2, Interesting)
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.
Re:The answer is simple... (Score:2, Funny)
The easy way to avoid having someone else break your encryption is to put some copyrite data in the files, then sue them into oblivion under the DMCA if anyone tries it:)
Re: The answer is simple... (Score:2)
Simple (Score:5, Insightful)
By only using peer reviewed open source software for starters.
FP?
Re:Simple (Score:5, Funny)
Re:Simple (Score:2)
Uh, I think that when talking about "peer review", it is implied that when all the reviews are negative, you shouldn't use that software.
In other words, the system is solid, but still doesn't work if end users don't pay attention to the reviews.
Re:Simple (Score:5, Insightful)
I agree that the best way to ensure that an application is secure is for it to be reviewed by someone who knows their shit. Quite simply its the only way to be sure at this point in time. Perhaps an authoritive body should be formed comprising of cryptographers that grants their seal of approval on it. Then again, doesn't the US government have to give its authorisation for cryptographic software to be exported? I recall that DES had to go through such motions, and if i'm not mistaken PGP can't be shipped outside of the US because its considered military grade cryptography? If im wrong please correct me, its been a while since I read over this topic and my memory is a bit hazy.
BTW, open source does not necessarily imply increased security. 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.
-- Enditallnow
Re:Simple (Score:2)
Exactly. If you want to find out if your crypto implementation is secure, ask the US government. If they say yes, you've got bugs.
Mind you, I'm not sure why anyone would need to ask permission to export a public standard like AES. I'
Re:Simple (Score:2, Interesting)
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 Sourc
Re:Simple (Score:5, Informative)
By only using peer reviewed open source software for starters.
Also note how the "UNIX" tradition of chaining smaller, single-purpose applications together would have also prevented the problems described in this paper.
If you first create an archive (tar.bz or even ZIP), and then run it through gpg, the metadata is encrypted by default, and these problems would not have arisen.
Furthermore, there's no need to check every archiver under the sun for subtle encryption snafus, since the encryption is done by a specialized application. Wheter you GPG a
I wonder why people use a
Also note that in the EU (now 25 countries!) public key cryptography such as GPG and SSL is all but mandated for electronic signatures that will stand up in court; better to use public key crypto than to rely on a shared key if you need to rely on file's or email's authenticity/non-repudiation.
Re:Simple (Score:4, Informative)
Re:Simple (Score:2, Informative)
PGP/GPG uses compression for security purposes (remove as much entropy as possible) but IIRC it doesn't archive; i.e. include multiple files (and a directory structure) in one file.
This capability is precisely what bit WinZip in the ass (WinZip lives for archiving) because they left the meta-data that lists filenames etc. unencryp
Re:Simple (Score:2)
aespipe (Score:4, Informative)
http://loop-aes.sourceforge.net/aespipe/
Would be interesting to analyze it for potential problems; the included bz2aespipe script, at the very least, specifies the hashing and crypto algos in plaintext.
Re:aespipe (Score:3, Interesting)
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 [sf.net].
Re:Simple (Score:2, Insightful)
I say preferred because with an open specification, peer review is more likely since competitors and open source users alike will try to implement the specification, thus enforcing the "many eyes" ideal. If there was an Open Source zip program that everyone used, there would probably be less compet
Predictable.. (Score:5, Insightful)
They think you can just take AES and HMAC and glue them together in any way
and arrive at security. I mean both are secure right? The result should be secure?
Wrong! Schneier names one of the chapters in one ofhis book: "Cryptography is hard but that's just the easy part!"
It really is very hard to secure information. It's almost intractable.. We've seen a few articles here in the last week about interesting side-channel attacks. Breaking RSA keys by listening and an earlier one which broke into computers by heating them up.
Cryptography is littered with broken designs fielded designs like WEP and let's not mention software security..
It's going to be twenty years before we have "trustworth computing". It would help if we could modularize cryptography like we can computer programs...
Simon.
Re:Predictable.. (Score:3, Interesting)
http://www.quantum.univie.ac.at/research/photonen
Basically, is it the coder's fault or the computer's fault? Maybe both?
Re:Predictable.. (Score:3, Insightful)
The head code probably said "We can save a few hundred clock cycles if we only encrypt the actual data and not the header data.. I mean what value is the header-data.. "
BIG MISTAKE! Your a coder not a security expert. Get a security expert to make that decision - just because you write code does not give you the experience to make that judgement..
Simon.
Re:Predictable.. (Score:2, Insightful)
Re:Predictable.. (Score:4, Interesting)
Re:Predictable.. (Score:2)
Re:Predictable.. (Score:4, Insightful)
Well, let's see - after you've encrypted that Zip file with PGP, you'll be able to exchange it with all of the 0.0001% of the people in the wolrd who have heard of PGP and are willing to put up with the it. (That figure's probably not far off: As evidenced by their actual usage, the vast majority of IT professionals refuse to put up with the pains of PGP/GPG, and they're only a tiny fraction of the world's PC users.
There are decent solutions out there - But even the best tools available, things like AxCrypt [sourceforge.net], which can be used to encrypt/decrypt any file on the fly are still considerably more of a pain than not using encryption. Encryption is not a panacea, and won't be widely used until it's totally transparently hidden by the OS.
Arguments about convenience are not bogus: they are in fact probably the most valid arguments involved in any sort of security system discussion, since history has proven time and again that users *will* turn off or otherwise render useless any security they find to be obnoxious...
Re:Predictable.. (Score:4, Informative)
True, but let's look at the quote:
There are always tradeoffs. The trick is to know which tradeoffs work the best for you. One set of trade offs work best for a company competing for business (or at least the company will bet on one set of trade offs paying off), while a different set of trade offs work best for a particular individual.
When I was 12, I used a simple substituion cypher. With the following cavets:
Still, I have nothing really worth hiding. However, if I want to. I have the following requirements.
As far as even savy system administrators not using pgp. I will trust the data of 100 individuals with a secure passphrase of not getting hacked is far more likely than the possibility of those 100 administrators who do not use pgp.
Why? For all the reasons I mentioned above. They probably feel very secure, but in reality have a weak encryption setup. It won't come back to haunt most of them, but nonetheless, it is still weak.
People that want and really need security, will take whatever steps necessary to get it. They will live with the hassle to get that security and will be secure because of it.
Relying on the OS to provide it makes it only as safe as the weakest link, and we have seen how many weak links there are in the OS chain. Not to mention trusting that the OS does not have any backdoors.
Always a tradoff. So for, I have not seen a better set of trade offs for exchaning encrypted information between users than pgp. But I am open to consider better implementaions of encryption software when they become available.
Re:Predictable.. (Score:2)
Re:Predictable.. (Score:3, Informative)
Simon.
Re:Predictable.. (Score:2)
How to tell if a product is secure. (Score:5, Funny)
Under many eyes, all bugs are trivial (Score:3, Insightful)
Having access to the source code is a good start, so the community can examine the methods used. It's not like WinZip has my business to lose if I could compile the source myself.
When I want to secure my data... (Score:4, Insightful)
Kremlin Encrypt/Decrypt [kremlinencrypt.com] comes to mind as software that I've had good experience with.
Re: When I want to secure my data.. (Score:2)
However, if you're sending an archive to a Windows user, and you trust your archiver's encryption, why would you want to mess with some external tool? They quite possibly don't have PGP or Kremlin or whatever, and they do almost certainly have WinZip. It's simpler just to check the relevent options there instead of running it through some other program.
Of course, in any of the various Unices, it's as simple as tar
stronger encryption (Score:5, Funny)
Source code and peer review (Score:5, Insightful)
Open source is critically important with crypto, IMHO. Crypto seems to me to be something that a malicious entity would be more likely to put a backdoor into, instead of, say, an image editing program. Open source, as we all know, means that the code can be audited and compiled by a trusted party (myself), thus guaranteeing the legitimacy of the program. Perhaps more importantly, open source means the software is subject to peer review.
Re:Source code and peer review (Score:2)
But only within the limits of your skill and experience. Crypto holds many traps for the over-confident and unwary.
I distrust the popular notion on Slashdot that exposure of source is somehow equivalent to (or somehow guarantees) peer review in the medical and scientific sense of critical examination by experts in their field.
Oh shit! (Score:3, Funny)
WinZip... (Score:5, Insightful)
It is to archiving programs what AOL is to ISPs.
Given that, do you really trust anything it does to be secure in any meaningful way?
It's like if AOL announced that all AOL connections were protected using "state-of-the-art technology based on OpenSSL". Would you really trust an AOL connection to be as secure as, say, an OpenSSH connection from an OpenBSD box to another OpenBSD box?
Just because it's buzzword-compliant doesn't mean it's actually as secure as that buzzword would imply in more geekish circles...
Re:WinZip... (Score:3, Interesting)
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?
Re:WinZip... (Score:2)
I hear a familiar mantra coming on... (Score:2, Insightful)
"Open source software is good, Closed Source is bad!"
I feel like sometimes these stories are intended to invoke that type of response, whether warranted or not.
A company did a bad job programming here -- no need to indite all Proprietary software on Winzip's account.
-Jason/a. [blogspot.com]
Re:I hear a familiar mantra coming on... (Score:2)
Not sure they're really big issues (Score:4, Insightful)
The solutions to the points raised in the article as far as I can tell pretty much boil down to:
1) Be aware that metadata of the encrypted files is not secure. (The only WinZip-specific flaw, and certainly possible to work around)
2) Be careful how you communicate regarding the transmission of encrypted files.
3) Be careful with your password.
4) Check your PC every time you return to your office to make sure nobody has placed a keylogger between it and your keyboard.
Certainly slashdot users can do that!
winzip is reasonably secure (Score:2, Informative)
Re:winzip is reasonably secure (Score:2)
but the NSA could do crack it if they really wanted to.
winzip is not open source, isn't it? NSA has probably the source code, or they may have a backdoor, installed courtesy of winzip makers. Remember NSA's master key in Windows crypto libraries?
Re:winzip is reasonably secure (Score:4, Funny)
The NSA has no backdoors into Microsoft products.
Everyone here knows that the NSA is just a tool of Big Business.
Clearly you meant to say Microsoft has a backdoor into the NSA.
Re:winzip is reasonably secure (Score:2)
Clearly you meant to say Microsoft has a backdoor into the NSA.
Well, that is true as well, but at least, the NSA knows how to firewall their backbone (at least we hope so).
Here's the link: Backdoor in MS crypto API [www.ccc.de] (in german).
Quick summary (Score:5, Informative)
Similar to IANAL, I'm not a crypto expert. I probably botched some of these a bit, especially the key collisions one. If I've misunderstood any of these, please reply.
Re:Quick summary (Score:3, Insightful)
Re:Quick summary (Score:3, Insightful)
The mechanism fails to provide several expected properties: that all of the information in the file is hidden and that a file which decrypts without error with a given key was created by someone with the key (
Re:Quick summary (Score:3, Insightful)
Not all of those are social engineering attacks though. Modifying the header to prevent the data from being properly decrypted is a technical attacking. Data security is protecting your data from a 3rd party while ensureing that the recipient can read the data.
Cryptographers hate poorly implemented security, especially when properly implemented security is possible. That is why this is news: People need to know that WinZip
Re:Quick summary (Score:2, Informative)
Note: i am not a crypto expert
I've been reading up on PRNGs recently so I'll take a shot at it. The encryption method used is AES in what's known as Counter mode. The way that works is like so:
F(X) = AES(X, SALT)
So to get the next one in the list, all you have to do is calculate AES(X + 1, SALT). Since F(X+1) does not depend on F(X) at all, they can be do
Re:Quick summary (Score:3, Insightful)
I disagree that the filename should be authenticated, changing the filename should be allowed since different systems allows different characters. If I had an encrypted zipfile that I had trouble sending because the filename was too long or had spaces or somethin
Key collisions, an explanation (Score:4, Informative)
After reading the paper, what they're talking about with key collisions is a fairly common problem with beginning cryptosystems.
When designing a cryptosystem, you try to get the same "bit level" of security throughout the system. The reason for this is that in most cases any system is only as strong as its weakest component (I know, duh, right). In a system using a 128 bit symmetrical block cypher (in this case AES) you are usually going for ~64 bits of "security". This basically means you can expect any successful attack to take 2^64 operations. The reason you don't get 128 bits is because of the "birthday attack"[a].
So generally if you're using AES 128 you are going for 64 bits of security. The problem with AE-2 (the system used in WinZip), at least according to the author, is that the key generation algorithm only gets ~32 bits of security. The article just says "the key derivation process is randomized"; it does not say what algorithm is used. My guess is that they used a 64 bit algorithm to randomize they keys generated from the password.
Since the CTR mode counter is always initially zero in this system, that means that there is no additional randomness added to the keystream (you get all your randomness from the password).
So that part is basically saying that the system is at most half as secure as one would expect for a (well designed) system using AES 128.
[a] The "birthday attack" is named after the "birthday paradox", which is the idea that if you have 23 people in the same room there is a greater than 50% chance that two of them have the same birthday. Where N is the number of possible choices, sqrt(N) is approximately the number of random choices made before there is a %50 chance that two of them coincide. Since in encryption you are usually using values of 2^n, this means that the "birthday bound" is 2^(n/2), e.g. if you are using encryption which normally would take 2^128 steps to find a collision, the probability of a collision is greater than %50 if you take only 2^64 steps.
Re:Key collisions, an explanation (Score:2)
As I said, since the attack can be performed in fewer steps, it provides fewer bits of security.
Your point is valid, it *also* decreases the lifespan of the password.
security is a system problem (Score:2, Insightful)
Security is a system problem, and requires you to look beyond the boundaries of software.
Breaking security requires to find a side-channel, where secure information leaks through. Just when you thought you found the perfect software solution, there's some chap that starts probing your address bus [xenatera.com] or checking the power consumption profile [cryptography.com] of your processor. Darn!
not everything in the paper a Winzip vulnerability (Score:5, Insightful)
Re:not everything in the paper a Winzip vulnerabil (Score:2)
Re:not everything in the paper a Winzip vulnerabil (Score:2)
Re:not everything in the paper a Winzip vulnerabil (Score:3, Interesting)
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, i
Old problem... (Score:2)
Some people (especially in the management) don't quite tackle the difference.
!Complexity == Good (Score:4, Insightful)
Of course since when is anyone who's serious about protecting their data is going to use winzip? One tool for each job please, this is for compressing and archiving data, not to protect it. Anything else they try to build on top of it is only giving a false sense of security to people.
I can see how "AES Encryption" must have had the marketing guys wetting their pants though.
Stick with what you're good at.
Check the community (Score:2, Interesting)
Yoshi's broken other things too.... (Score:5, Informative)
The UNIX Way (Score:3, Interesting)
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.
Re:The UNIX Way (Score:3, Insightful)
Regarding not all of the things being good - you can't encapsulate security. That's exac
Re:The UNIX Way (Score:2)
Outlook Express 6 has Sign and Encrypt checkboxes. S/MIME, 168 bit. But you need a digital ID from VeriSign [verisign.com] ($15/yr) or another service to enable the feature.
these people wouldn't like UNIX either (Score:2)
WinZip seems to do what you expect it to do: it encrypts each file individually using AES. That's a perfectly reasonable thing to do, and that's all there is to it. It's the objections that are bogus, not WinZip.
This is an educational problem (Score:3, Insightful)
Is this research illegal? (Score:5, Interesting)
Re:Is this research illegal? (Score:2, Interesting)
There is considerable debate as to if an algorithm or source code is a "circumvention device", but pretty much most of the courts have ruled that object code of such a device is no longer free speech and falls under the "circumvention device" portion of the code.
If I'm incorrect, please enlighten me as my understand
Re:Is this research illegal? (Score:2)
Re:Is this research illegal? (Score:2)
They were classified as "munitions" for some reason.
Do some damn research! (Score:2, Insightful)
Do some research and ignore buzzwords.
Misleading!! (Score:4, Insightful)
This statement about winzip is quite misleading. Either the author didn't bother to read the paper or has an emotional bias against non-free software.
The encryption method in WinZip is actually fairly secure, the attack mentioned in the article consists of tricking someone into sending back the decrypted output. While design improvements could be made to make this less likely this hardly qualifies as 'simply use(ing) the right busswords'. So long as you aren't an idiot and send data so confidentional you might reasonably be the victim of a complicated man in the middle attack this product will work fine for your security needs. In fact as they mention in the article PGP suffered from a similar problem.
In fact, aside from the documented fact that the file names and lengths are in plaintext, this tool provides all the security an individual user is ever really going to need. Even large corporations are unlikely to be the victims of sucesfull man in the middle attacks and certainly anyone using WinZip for their security needs doesn't really need to worry. This is certainly enough to stop your family friends and law enforcement from reading your shit.
I know I'm going to get jumped on by some crypto people and to be fair it *is* good we find issues like this report them and either document or fix them. However, if we are going to consider social factors (such as tricking someone into sending back 'garbage') it is only fair we credit social factors toward the credit of such a program. So we should consider the social factor that WinZip is hardly used by the government or milatary when asking if it is a reasonable security product.
Use validated software! (Score:4, Interesting)
Another international validation program is the Common Criteria [nist.gov] 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.
Re:Use validated software! (Score:2, Informative)
These "validations" aren't really worth much. I personally have evaluated a product that had passed Common Criteria, and I found numerous critical vulnerabilities, including flaws in basic SSL implementation, an obvious buffer overflow, the ability to access the entire supposedly protected database without authentication, etc. This was a closed-source product, so I'm sure there was a lot more that I missed, since all I did was test it for a couple of days.
It's much better to go with open source so at leas
The difference (Score:5, Informative)
However using weaker crypto algorithms like DES will invalidate any secure keystorage simply becuase it would be much more vulnerable to brute force attacks. Using AES simply moves the weak point to another link in the chain of security for WinZIP.
A curiousity for an example is the book "Neuromancer" by William Gibson where the AI had to trick a human beeing to unlock the last link to its pal AI because it could not be cracked by computers. A 100% computer secured old fashioned iron key! :-) I just love that chapter.
is 7-zip any more safe? (Score:4, Interesting)
We've known this about ZIP files for 15 years! (Score:4, Interesting)
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?
Crypto is not vanilla and software is not cola. (Score:3, Interesting)
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
Much ado over nothing? (Score:5, Informative)
The vulnerabilities listed basically boil down to:
* Filenames and sizes aren't encrypted. If you store sensitive data in the filename, it can be read. (The paper uses the example of Bob intercepting a zip file containing a file named PinkSlipForBob.doc)
* The type of encryption method used is not authenticated. If a malicious user is able to perform a man-in-the-middle attack and edit the file so that it specifies a different (incorrect) encryption method, the final recipient will decrypt it and get a file of nothing but garbage. Now, if the attacker can also social-engineer the victim to send him that garbage file, the original file can be reconstructed.
* File names stored in the
* The next attack involves the attacker actually knowing the entire contents of the file (s)he wants to intercept, which to me at least, seems to defeat the purpose of intercepting it. Actually, that's a slight oversimplification: for this attack, the attacker needs to know 1 of n possibilities of what the exact file contents could be, and with this information, has a 1 in n chance of finding out if (s)he was right, by replacing the file in the archive with the "guess" (again, requiring the ability to modify the file in transit), and use the fact of whether (s)he intercepts a "Hey Bob, that zip file you sent was corrupted" message to find out whether the guess was right. (If it was a 1-byte file named "yesorno.txt", and the attacker wanted to know whether it contained "Y" or "N", this could be a useful attack. For less trivial files, however, this doesn't seem very feasible.)
* WinZip allows both encrypted and un-encrypted files in the same archive, so the end-user doesn't know if any given file was encrypted or not. An attacker can (man-in-middle, yadayada) add files to the archive before it reaches its recipient, and the recipient won't know they're not part of the original archive. A definite flaw, however, not directly a data leak of any kind. (Although, if one of the 'unofficial files' is a keylogger, and you can get the luser to run it....)
* A weakness in key randomization will cause a repeat key to be generated once every 2^32 files rather than the theoretical maximum of 2^64 files. So, "all" the attacker needs to do is find a victim who will use WinZip to encrypt, oh, 4.2 billion files or so, and they will have a good chance that one of the encryption keys is a repeat. Supposing there was a repeat, now they just have to know the entire contents of the larger of the two files, and they can determine the contents of the smaller one.
The paper also briefly mentions attacks like "plant a keylogger" or "replace Winzip with a program that looks like Winzip", but I wouldn't exactly call these flaws in the AES implementation. (The paper also comes to pretty much this conclusion, and so doesn't dwell on these possibilities.)
Nothing is secure. (Score:3, Insightful)
We can't. I think it's more of a question of "Is it secure enough?" The WinZip encryption may be weak, but unless you're zipping up government secrets it's probably OK.
Almost all encryption schemes can be broken, either through brute force or social engineering, it's just the way it is.
Peer review certainly helps, but doesn't ensure that the product is secure. It may you tell which products are not secure, but then the above paragraph shows that.
It's like safety (Score:2)
Same thing with security. Simply downloading and installing the "latest security tools" does NOTHING except give you warm and fuzzies.
std. disclaimer (Score:2)
However, I think *any* cryptographer will say "crypto is hard". Just like *any* heart surgeon will say "transplantation is hard."
Why people continually attribute such obvious tidbits of truth to him is beyond me. Here's a tip for you non-cryptographers out there.... Bruce isn't even an academic cryptographer!!! There are way smarter [Lenstra, Daemen, Matsui, Biham] cryptographers out there. If you want to quote cr
misdirected criticism (Score:5, Informative)
WinZip seems to do what it claims it does: encrypt file contents with AES, no more and no less. Yes, it leaves the "metadata" unencrypted, such as it is, but so what? You get the same kind of behavior when you use the AES command line utility on UNIX. Nobody ever said that it would protect metadata, and it should be pretty clear to users that it doesn't as soon as they open the WinZip archive and see the file names. Furthermore, protecting the metadata through encryption would decrease usability significantly.
We also know that shredders don't offer perfect security, but they are sure a lot better than just throwing out documents on the curb. Well, it's the same with cryptography. The sooner people like Schneier realize that and stop scaring people away from cryptography by making obscure points, the better off we all are.
Him, again! (Score:2)
Secure enough for most. (Score:3, Informative)
To summarize their main concerns:
* The file listing is not encrypted, allowing attacker to see file names, sizes, compression ratios, and dates.
* The files are encrypted using an AES based stream cipher, whereby if the attacker replaces the encrypted contents, gets you to decrypt them, and gets a hold of the decrypted garbage that resulted, they can use the "garbage" to decrypt the original.
* An attacker can rename files in the zip.
The only one that reveals the contents of your data requires a bit of social engineering to get you to decrypt a chosen ciphertext and send them the result. Without tricking you into helping them, all an attacker can do is get a file listing, which may not be useful if they already knew what they were after.