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?"
Like the subject says, could carelessness in encryption have been a non factor even a couple years ago? Does the raw processing power on the average desktop make it that much easier to exploit a mistake or break weak encryption? In any case, I hope Winzip realizes "security" and "encryption" are more than just buzzwords.
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.
So how can we distinguish between an application that simply uses the right buzzwords, like AES, from an application that is actually secure?"
By only using peer reviewed open source software for starters.
FP?
I think the problem is people approach to the security.
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.
Lqf#6Z5Q|LL5#DzGmL:$^!!AW8\wJE)hr{OMFm\\$^$]*mArkJ ^V!
:P
You know, I read the subject as The Following is encrypted using ASS....as in you're talking out of your ass!
Join the TWIT army now!
Wait for a cryptographer to analyze the product, then read about it on /.
So how can we distinguish between an application that simply uses the right buzzwords, like AES, from an application that is actually secure?
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.
The only surefire protection against Microsoft infections is abstinence. - The Onion
About the last thing that comes to mind is "WinZip". Surely anyone in the least bit serious about security would look into something more mature (the implementation not the algorithm).
Kremlin Encrypt/Decrypt comes to mind as software that I've had good experience with.
We need 2048-bit buzzwords.
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.
I just designed and submitted a corporate security infrastructure built solely on zipping everything. I guess it's time to get back to community security college.
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!
...is really the lowest common denominator of zip programs. It is what Joe and Jane Sixpack of Bunghole, Indiana use to exchange photos with their son Jake in college in Goatse, Minnesota.
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...
Honey, I shrunk the Cygwin
Repeat after me:
:)
"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.
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.
Given that the WinZip people were undoubtedly trying to add "real" security without changing the way their users have become accustomed to working with the product, it seems to me like they did a pretty good job.
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!
most of the flaws mentioned in the article will require the attacker to go to great lengths to break the encyption. Others include the often quoted but rarely practical middle man attacks. In otherwords it is not flawed to the point where your teenage kid can hack your zip files, but the NSA could do crack it if they really wanted to
did you forget to take your meds?
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.
PJRC: Electronic Projects, 8051 Microcontroller Tools
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 or checking the power consumption profile of your processor. Darn!
While most of the points raised in the paper seem valid, some done make sense. Case in point: "someone may use a keystroke logger to find out what your passphrase is". How the fuck is this a Winzip vulnerability?
It got proper AES implementation. And unrar sources are open, so you can check how it's done. Packs much better than WinZip too.
How to distinguish a system that is protected against viruses from one that is virus-proof?
Some people (especially in the management) don't quite tackle the difference.
45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
Complexity is often your enemy when designing secure systems. It might be tempting to implement lots of features and bells and whistles and cherries on top, but if you're serious about security you'll want to keep it as simple as possible.
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.
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.
Might I note that this is the same Yoshi Kohno who broke the Diebold voting system and SSH.
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.
Security has been and always will be an educational problem. Open Source makes the problem more transparent, but it's still pretty naive to think that someone is going to do a security audit of every line of code in a given product. Ex: Linux proved this with it's kernel hacks. Regardless of the severity of the problem, they were in plain site for anyone to analyze and correct for years. More than likely someone found the holes and was free to exploit them for years until a white hat hacker made the issue public. This was just one example and equally applies to any software. The first line of defense in securing code is developer education for proper implementation of security using well known good practices. The greatest weakness that we as development professionals is that there are not enough resources available to teach these best practices, but they're coming slowly based on customer demand. I think that we all have to remember that security issues have only recently become a mainstream computing problem and coincided directly with the increase in broadband Internet connections. I.e. The last 8 years or so. So, what secure coding resources do developers have available to them today?
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.
"some done make sense"
Oh the irony!
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...
Very good and valid point! I hope you get modded up some more.
I thought programs that encrypt data were against the U.S. export laws ( since people overseas can download WinZip )
aespipe is a fast lightweight UNIX solution that is simpler than GPG:
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.
"So how can we distinguish between an application that simply uses the right buzzwords, like AES, from an application that is actually secure?"
Do some research and ignore buzzwords.
I have no signature
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.
If you liked this thought maybe you would find my blog nice too:
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/
If someone can use a keystroke logger to find out what your passphrase is, then it is a Winzip vulnerability. That doesn't mean that Winzip can do anything about it, but the inability to counteract an attact does not make that attack go away.
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.
It is a WinZip vulnerability in the same way a castle wall is vulnerable to a battering ram.
A dyslexic man walks into a bra.
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?
Instead of blaming other people for charging too much, you might try learning how to budget yourself and balance your spending with your desires. If you want something bad enough to petition for it, you should be able to adjust your savings enough to be able to afford it yourself.
I live on about $12,000 a year, but I was able to buy a $2200 PowerBook, I drink $100/pound tea, $50 Scotch, and shell out quite a bit for my girlfriend. Just think about what you're spending money on, and whether it's really worth it to you.
In my case, I was buying lots of shitty beer on the weekends (ah, college life), eating out when I could have been cooking, going to movies all the time, driving my 12mpg Lincoln to campus 3 blocks away, and everywhere else. All that shit adds up, and a lot of little shit, too.
After I started cutting that stuff out, I started finding myself with fucktons of money. The first thing I set out to buy was an iBook, but then they came out with the 12" PowerBook, so I set my sights higher, waited 4 months, and bought one, fully loaded. (I sold a painting in that time that paid for the SuperDrive, but $2000 of the price came from 6 months of savings, If you can't save $1000 (for an eMac or iBook), in that time, there's something wrong with you.)
I'm not a crypto expert either, but I've got a decent grasp on the subject.
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.
"He's more machine now than man, twisted and evil."
This may be non-news to those who read the paper, but it seems like the "vulnerabilities" here are overstated. Plenty of "rah, rah, should've used open-source, all your data are belong..." comments, but successful use of any of the exploits in the paper seems highly unlikely at best.
.zip are not authenticated. Like above, if the attacker can change the file extension, (s)he can cause the file to open in the wrong application when the victim unzips that file. This will likely be a nuisance at best; while the paper states that this method could be used to mount an attack similar to the above (getting garbage decrypted by a different method), it's unclear how this would actually work (since the file decrypted successfully, and there isn't any garbage). The attacker would have to coerce the user to send the unencrypted file itself.
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.)
Caveat Emptor is not a business model.
So how can we distinguish between an application that simply uses the right buzzwords, like AES, from an application that is actually secure?
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.
"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...]
Sorry, I seem to have a mild case Fourier analysis on the brain.
Secure WinZip: Put files together with WinZip. Then run The GNU Privacy Guard.
Personally I use GPG. It's open source, has lots of users, and is very intensely reviewed.
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 -czf- files | gpg --encrypt.
I hereby place the above post in the public domain.
Same thing with security. Simply downloading and installing the "latest security tools" does NOTHING except give you warm and fuzzies.
"Reality is that which, when you stop believing in it, it doesn't go away." - Philip K. Dick
I think Bruce is a smart and clever fellow and he certainly knows what he's talking about.
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 cryptographers at least quote ones that have new and original things to say instead of the repetively tiring press-whore Schneier.
Tom
Someday, I'll have a real sig.
You ask Howard Schmidt. He will tell you.
I think you underestimate just how much I just dont care.
The salt is generated randomly. There are 2^64 possible values. If you happen to get two files encrypted with the same password, using the same salt, then the transformation done to encrypt them is the same. If you know the plaintext of one of them, then you can easily decrypt the other (up to the length of the first).
Also, you may have a somewhat easier attack to decrypt both of them than you otherwise would; but I think it still wouldn't be particularly easy, since the data is compressed.
This is a realistic problem only if you encrypt millions of files with the same password.
From a quick glance through the paper, it doesn't sound like he found any smoking guns. The attacks he thinks of are pretty unlikely, and he did not find anything that makes the method intrinsically insecure.
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.
This guy didn't find any problems with the AES encryption per se, he just doesn't like the way it is used. But the same objections he has to WinZip would apply to using PGP or AES command line tools, either for files on disk or inside tar archives.
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.
Thank you professor obvious. Next, please point out that AOL is not for the technically savvy, and that emailing the same Really Funny .exe to 300 people isn't very swift.
+1 what a freaking brilliant insight, ooo ooo!
We are all in debt to you for your huge contribution to society with this post.
P.S. you insensitive clod.
This is pretty much (in a very general sense) exactly how the Xbox was hacked. I mean, it makes complete sense right? It doesn't matter how good the lock on your door is if you can just smash a window and get the key.
Doesn't it make you feel good to know that our freedoms are protected by politicans, lawyers and journalists.
Case in point: "someone may use a keystroke logger to find out what your passphrase is". How the fuck is this a Winzip vulnerability?
Well, for example, Winzip could (but doesn't) provide a "secure entry mode" which was based on an on-screen mouse-driven "keyboard" with a randomised key layout. Or it could check the process list for known key-logging programs and alert the user if any are detected. Sure, neither method is foolproof, but at least it would be making an effort...
Actually the algorithm WinZip is using also does an authenticity check. So you not only know that it's encrypted, but you should also know that whoever gave you the file also had the secret key.
Does WinZip promise that those authenticity checks are cryptographically secure? I kind of doubt it; the CRC feature just looks like the traditional CRC check that WinZip always used to have, mostly guarding against accidental errors.
The fact that someone without the secret key can take an encrypted file and modify it without the recipient getting a message letting them know it was modified is a *bad* thing.
No, it's not. It's a trumped up threat of little practical significance, which is why all the examples in the paper seem contrived--they are contrived.
It looks to me like the WinZip authors just added AES encryption in a straightforward, unsurprising way. It does what it does, and what it does looks useful to me. If you want it to do more or something different, that's not a problem with the software--you just picked the wrong tool for your needs.
An attacker won't be able to extract the contents from your zip files without your assistance.
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.
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.
Winzip 9 has FIP 140 validtion and the algorithm used is open source!
see: http://www.winzip.com/aes_info.htm
It is the implementation that has been found wanting.
In today's environment, I assume, even domestic software in the USA may have government suggested features as well, not that other countries haven't had it all along.
In my opinion, nothing has changed for decades, except the technology; e.g. if you are a "bad guy", they will find some way of watching you, if you are bad enough. For the tin-foil hatter's out there... consider this - there are too damn many people doing too damn much stuff for them to watch everone. Don't worry about it too much.
This issue is a bit more complicated than you think.
With network firewalls and other such software there are already recognised processes for getting evaluation and certification for security related products. This involves some cost to the vendor, as they obviously can't certify their own products.
What appears to be needed is a drive from business/government to give priority to any such products, unless there is a sensible (auditworthy) reason to choose another uncertified product and formally acknowledging the disks involved.
This works for firewalls, and at a minimum provides a limited form of peer review. If purchasers could examine the evaluation criteria applied to a particular product, and match the independant findings against their particular circumstances, business and government can have a greater level of confidence in the product.
If 'joe public' then has to choose between a product that has some form of independant certification, and another that business and govermnet don't want to touch, which will they choose ?
Many software houses cannot get the security right for their products. There must be some unique problem upon this.
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. For most small/medium size software house (except the security related ones), I doubt if they have specialist who knows security/ encryption of that kind of stuff. One day, when the PHB wants some more security feature in the product, he would most likely deploying some programmers skilled in other areas to work on this. Obvious, it won't work that well....
The abstract begins with "WinZip is a popular compression utility for Microsoft Windows computers"; the word "-infected" is missing.
Re: 1): (from TFA) M Bellare and C Namprempre "Authenticated encryption: Relations among notions and analysis of the generic composition paradigm" in T Okamato (ed.) Advances in cryptology - ASIACRYPT 2000, volume 1976 of Lecture notes in Computer Science pp 531-545. (Springer-Verlag, Berlin Germany Dec. 2000).
"The underlying AES-CTR-then-HMAC-SHA1 code is a provably secure authenticated encryption scheme per results by Bellare and Namprempre."
Posters recognized by their sig,
So how can we distinguish between an application that simply uses the right buzzwords, like AES, from an application that is actually secure?
Perhaps the first question to ask is: Does it run on Windows?
I hope that he meant every syllable of it. Here's the deal: the list of people in the world smart, paranoid, and experienced enough to develop a new, relative secure crypto system is extremely short, and the odds of one of them being in a random classroom at a given moment is almost nil.
RSA may be breakable. 3DES may be breakable. We may even learn currently "impossible" methods of breaking quantum crypto. However, that professor can be reasonably confident that noone who was in his classroom when he said that is going to write a more secure system.
Honestly, if anyone in that room is gifted enough in that extremely small problem space, then they probably already know it and a professor speaking to the contrary isn't going to dissuade them. On the other hand, someone who thinks that they may be smart enough to create the Next Big Thing in crypto may remember their teacher's words and give up on the idea after being laughed off of sci.crypt a few times after their algorithms are shredded by people who know the subject better than they do.
If that professor can convince one would-be crypto hack to do something more productive with their time, then the world will be a better (and more secure) place for him having done it.
Dewey, what part of this looks like authorities should be involved?
So what about the "security" measures being used to protect RF-transmitted passport info/photos that are being introduced for US passports?
/.
What are they using, and who is providing it?
This was mentioned a couple of days ago on
Wait a minute. But Bob is exactly the person who is supposed to read the cleartext in the first place, is he not? Now, if Eve could intercept said zip file, then she would be able to tell Mallory about it and this would most certainly be a very serious problem. But why on Earth would Alice be worried about Bob reading the cleartext is simply beyond me.
Sincerely,
Pan Tarhei Hosé, PhD.
"Homo sum et cogito ergo odi profanum vulgus et libido."
that's called stenography