Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Security

Attacking WinZip AES Encryption 227

Posted by CmdrTaco from the eruces-yrev-si-siht dept.
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?"
This discussion has been archived. No new comments can be posted.

Attacking WinZip AES Encryption More

Attacking WinZip AES Encryption

Comments Filter:
  • 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.
    • I took a class in cryptography last semester. The professor offered the best words of advice I ever heard in the subject: "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."

      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)

        by Anonymous Coward
        He then proceeded to explain how easily NTLM can be defeated in a brute force attack.

        Suddenly the students started listening and taking notes!!! :)
      • lol...there are LOTS of things vulnerable to brute force attacks. Security is a joke because most companies simply say they support this and that so they can put a checkmark in their feature list. It's not that they really care to make anything secure. Even in rare cases where an implementation is good, it's even more rare that a good password is used (which is essential regardless of how fancy your encryption) because people can't remember long passwords and software rarely requires users to pick secure

        • Secure WinZip: Put files together with WinZip. Then run The GNU Privacy Guard [gnupg.org].
          • Better just use GPG since it compress files too (by default it will use the same compression algorithm than Winzip). If you want to encrypt several files, use tar ( availiable for Windows too [sf.net]) before.

            • 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)

        by mosel-saar-ruwer ( 732341 ) on Sunday May 16, 2004 @03:19PM (#9168398)

        "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...]


        • Sorry, I seem to have a mild case Fourier analysis on the brain.

        • Well,for one-time pad, the logistics is the hardest as you've stated. However, if implemented correctly and as soon as it becomes more viable, quantum key distribution QKD will alleviate all problems of key distribution. However, I don't see it used mainstream in the next 10yrs, but it could be used by the govt and things like that in less than 10yrs IMHO.

          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)

          by God! Awful 2 ( 631283 ) on Monday May 17, 2004 @04:10AM (#9171451) Journal
          That was just one of those typical comments that fits the mould of an insightful comment, but really isn't. See below.

          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 /. (i.e. someone who has read an edition of Crypto Gram) will mention them at every possible opportunity. This may appear to prove their knowledge, but it actually demonstrates their ignorance.

          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)

      by Cthefuture ( 665326 ) on Sunday May 16, 2004 @01:15PM (#9167767)
      I didn't read the whole paper but the first attack was dealing with the meta-data.

      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).
      • 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 (
      • 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.

  • The answer is simple... (Score:2, Interesting)

    by gid13 ( 620803 )
    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.

  • Simple (Score:5, Insightful)

    by Anonymous Coward on Sunday May 16, 2004 @12:39PM (#9167528)
    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?

    • Re:Simple (Score:5, Funny)

      by Anonymous Coward on Sunday May 16, 2004 @12:49PM (#9167590)
      Yes, like sendmail.
      • Yes, like sendmail.

        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)

      by enditallnow ( 177040 ) on Sunday May 16, 2004 @01:03PM (#9167693)
      Its questionable whether this would help commercial applications. Not every company offering secure programs wants their source code floating about the internet (Insert Microsoft Joke Here).

      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)

        by c ( 8461 )
        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?

        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)

        by Anonymous Coward

        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 wfberg ( 24378 ) on Sunday May 16, 2004 @01:16PM (#9167769)
      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.

      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 .rar or a .zip, you only need to look at GPG to find bugs. And if and when you do, fix GPG, or use something else.

      I wonder why people use a .ZIP plugin in outlook to encrypt mail, even though outlook has encryption (though admittedly, using cumbersomely acquired SSL certificates) built right in..

      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)

        by Krunch ( 704330 ) on Sunday May 16, 2004 @01:47PM (#9167934) Homepage
        GPG (and PGP) already compress the encrypted data. It seems PGP only use the .zip format but GPG also support bzip2 and gzip. Look at the -z and --compress-algo options of GPG.

        • Re:Simple (Score:2, Informative)

          by wfberg ( 24378 )
          GPG (and PGP) already compress the encrypted data. It seems PGP only use the .zip format but GPG also support bzip2 and gzip. Look at the -z and --compress-algo options of GPG.

          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
          • 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.
            That's what tar is for.
            tar -c $FILES | gpg -s -e -r $RECIPIENT > compressed-and-encrypted-files.asc
            Send that through netcat and you got a somewhat secure way of sending files to anybody who can configure his firewall. Who use Winzip anyway ?

      • aespipe (Score:4, Informative)

        by EventHorizon ( 41772 ) on Sunday May 16, 2004 @01:50PM (#9167952)
        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.

        • Re:aespipe (Score:3, Interesting)

          by Q Who ( 588741 )

          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)

      by John Starks ( 763249 )
      That might do the trick (though it usually doesn't, as another poster alluded to re: sendmail). But it is sufficient, and perhaps preferred, to simply open specifications for others to implement, as WinZip did.

      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)

    by Ckwop ( 707653 ) * on Sunday May 16, 2004 @12:40PM (#9167535) Homepage
    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.

    • Re:Predictable.. (Score:3, Interesting)

      by sjwaste ( 780063 )
      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:

      http://www.quantum.univie.ac.at/research/photonent angle/rng/

      Basically, is it the coder's fault or the computer's fault? Maybe both?

      • Re:Predictable.. (Score:3, Insightful)

        by Ckwop ( 707653 ) *
        It's a drive for efficiency..

        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)

          by sjwaste ( 780063 )
          Unfortunately, most firms will save a few clock cycles.. err, dollars to let the coder make the decision rather than hire a security expert. :) The average manager trusts his code staff simply because he knows no better, thus wont spend extra money on a "needless" consultant.

        • Re:Predictable.. (Score:4, Interesting)

          by John Starks ( 763249 ) on Sunday May 16, 2004 @01:32PM (#9167860)
          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.
        • In other words: stick to what you know. Let Winzip do the compression and archiving, and let someone else do the encryption. WTF is wrong with making a zipfile and then encrypting it with PGP? The only reasons to put encryption in Winzip itself are fairly bogus arguments about convenience, and the chance to charge more money for a product that does more (even if it does it badly).

          • Re:Predictable.. (Score:4, Insightful)

            by dublin ( 31215 ) on Sunday May 16, 2004 @03:59PM (#9168586) Homepage
            [What]is wrong with making a zipfile and then encrypting it with PGP? The only reasons to put encryption in Winzip itself are fairly bogus arguments about convenience, and the chance to charge more money for a product that does more (even if it does it badly).

            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)

              by fwarren ( 579763 ) on Sunday May 16, 2004 @07:51PM (#9169683) Homepage
              Arugments about convenience are
              not bogus;

              True, but let's look at the quote:

              Fast, Inexepensive, Easy to Understand. Pick any two

              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:

              1. What I was encoding was probably a note to my best friend with a message like "Hey, lets talk to our moms about me spending Friday night at your house. This is great that my sister can't read this note if she finds it."
              2. I knew that any 10 year old who had 2 paragraphs of encoded text and a library book could break the code. I knew an adult who knew what he was doing could probably break it with only a sentance or two.
              3. I knew I was going to encode the note, hand it to my friend later in the day, and he would go straight home to decode it, there was not much chance of it being intercepted.
              For what I was doing, it was the best method available to me. Wrapping notes around rods, or making invisible ink, were more trouble than they were worth. We did not have 2 rods of the same size, and my expermients with invisble ink were never really satisfactory.

              Still, I have nothing really worth hiding. However, if I want to. I have the following requirements.

              1. Do the encryption on the computer, to eliminate redunancy and incrase the speed and accuracy of encryption/decryption.
              2. Use an encryption method that is currently considered secure by cryptoanlysis.
              3. Use a public/private key encryption method to simplify the process of protecting my private key and making it easy to get/distribute public keys.
              4. Use an implementation that does not swap data out to the hard drive, leave remenants of unencrypted files, etc. Things that would make the implementation insecure and easy to hack.
              5. Understand that if someone physically comes gets my computer with my passphrase on it, and I pick a weak passphrase, my infomation will no longer be private.
              6. Understand that if someone can obtain physical access to my computer and install keyloging hardware, or has the equipment to listen to frequencies from my keyboard or monitor, my information still is not secure.
              Within those parameters, I do not know of a better product than pgp/gpg encryption. Does it take work to learn. Yes, yes it does. If I want to exchange encryped information, will I probably have to teach the other person how to use it? Yes, yes I will.

              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.

    • The paper makes it clear that they're combined using the correct "encrypt-then-authenticate" approach, not just thrown together. That should normally yield a secure channel so I'll be very interested to see what flaws Yoshi Kohno's found with this implementation.

  • How to tell if a product is secure. (Score:5, Funny)

    by teasea ( 11940 ) <t_stool@@@hotmail...com> on Sunday May 16, 2004 @12:43PM (#9167554)
    Wait for a cryptographer to analyze the product, then read about it on /.

  • Under many eyes, all bugs are trivial (Score:3, Insightful)

    by proverbialcow ( 177020 ) on Sunday May 16, 2004 @12:45PM (#9167569) Journal
    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.

  • When I want to secure my data... (Score:4, Insightful)

    by Jon Kent ( 777707 ) on Sunday May 16, 2004 @12:46PM (#9167571)
    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 [kremlinencrypt.com] comes to mind as software that I've had good experience with.
    • 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

  • stronger encryption (Score:5, Funny)

    by Anonymous Coward on Sunday May 16, 2004 @12:47PM (#9167574)
    We need 2048-bit buzzwords.

  • Source code and peer review (Score:5, Insightful)

    by Spetiam ( 671180 ) on Sunday May 16, 2004 @12:48PM (#9167586) Journal

    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.

    • 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.

      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)

    by Anonymous Coward on Sunday May 16, 2004 @12:48PM (#9167587)
    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.

  • WinZip... (Score:5, Insightful)

    by JessLeah ( 625838 ) * on Sunday May 16, 2004 @12:52PM (#9167609)
    ...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...

    • Re:WinZip... (Score:3, Interesting)

      by The Slashdotted ( 665535 )
      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?
      • Um, what? No, I'm not saying it was cracked because it's the biggest target. I'm saying it was cracked because the people who market to Joe and Jane Sixpack aren't the most brilliant programmers. (The most brilliant marketers, maybe...) Examples: Microsoft. AOL. Gator/Claria. Bonzi Buddy.
  • 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. [blogspot.com]
    • I believe you meant "indict", meaning to 'accuse, perhaps wrongly'; not "indite", which means to compose [a poem, et al]. Although some coders may disagree, I personally don't equate coding with poetry =) Unquestionably, all chants are bad, even 'open source' chants. But with respect to security, open source transparency is the best all-around approach to the security problem.

  • Not sure they're really big issues (Score:4, Insightful)

    by scalveg ( 35414 ) on Sunday May 16, 2004 @01:02PM (#9167682) Homepage
    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

  • Quick summary (Score:5, Informative)

    by pjrc ( 134994 ) <paul@pjrc.com> on Sunday May 16, 2004 @01:14PM (#9167752) Homepage Journal
    Here's the security problems, quickly summarized (and oversimplified). These are in the same order as the paper. The paper is lengthy and not an easy read... if you can't be bothered to RTFA, maybe this will help.

    1. Filenames, file sizes, time/date stamps are plaintext. Only the file contents are encrypted. Filenames, dates may be sensitive data (example giving, pinkslips.zip contains file pinkslip-bob.doc).
    2. Both compressed and uncompressed sizes are stored without encryption, so an attacker can know the compression ratio and perhaps infer what type of data it is based upon its compressability.
    3. File lengths are not authenticated. A man-in-the-middle attack could modify the file sizes recorded inside the zip archive so decrypting produces "garbage" output files (without warning that the zip archive was tampered). The man in the middle intercepts the communication about the problem and impersonates a request from the sender to see the "garbage". The garbage is after decryption, so if the receipient sends it in the clear, the man in the middle can easily turn it into the original plaintext.
    4. File names are not authenticated, so an attacker could tamper with the file names and change their extensions. On windows and other systems, the file name extension determines which software will be used to view the file.
    5. The CRC is stored without encryption. If an attacker suspects he knows what the message is, he can replace the ciphertext with his guess, and watch if the receipient complains about a CRC error.
    6. Zip archives can contain some encrypted files, others plaintext. They worry that a receipient may believe all or most files were protected, when only a few or one was.
    7. Key generation isn't random enough, so keys may be reused. I don't fully understand this one... maybe someone who does will reply and explain it??
    8. Attacker can create a "self-extracting" archive that mimics the GUI of Winzips, but is actually a trojan horse. They admit this isn't really winzip's problem.

    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)

      by rsmith-mac ( 639075 )
      While those are some interesting problems, I have to admit, they're really minor. Most of these are more social engineering attacks than technology attacks in the first place(i.e. man in the middle), and only 1, key generation, is a true technological threat to the encryption. As far as I'm concerned, even with their "flawed" implementation, this is strong enough for my needs. Anything past this calls for PGP in the first place.

      • Re:Quick summary (Score:3, Insightful)

        by iabervon ( 1971 )
        The other flaws are differences between what is actually done and what a user is likely to expect to be done. In a social engineering attack, the attacker confuses the victem in some way; in this case, the victem is confused in advance by the software, and does something inappropriate because of that.

        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)

        by Bishop ( 4500 )
        Welcome to security. The technology side to security is easier then the human side.

        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)

      by AaronMB ( 136741 )
      > Key generation isn't random enough, so keys may be reused. I don't fully understand this one... maybe someone who does will reply and explain it??

      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)

      by alphaseven ( 540122 )
      I agree with a lot of these criticisms. I've used Winzip encryption, the strangest thing is that instead of encrypting the zipfile, it encrypts the files within the zipfile. This is contrary to how most people expect an encryption program to work.

      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)

      by Gregoyle ( 122532 ) on Sunday May 16, 2004 @03:10PM (#9168347)
      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.

  • 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)

    by Anonymous Coward on Sunday May 16, 2004 @01:16PM (#9167774)
    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?
    • 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.
    • It is a WinZip vulnerability in the same way a castle wall is vulnerable to a battering ram.

    • 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 isn't a WinZip vulnurability, but it is mentioned in the WinZip documentation. The exact quote from the article is:

      For example, as noted in the WinZip documentation, an adversary might try to capture a user's passphrase by installing a keyboard logger on the user's computer or might try to resurrect a plaintext file from memory.

      But the above is not the major point, i

  • 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.

  • !Complexity == Good (Score:4, Insightful)

    by Graftweed ( 742763 ) on Sunday May 16, 2004 @01:28PM (#9167839)
    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.

  • Yoshi's broken other things too.... (Score:5, Informative)

    by meese ( 9260 ) on Sunday May 16, 2004 @01:31PM (#9167851)
    Might I note that this is the same Yoshi Kohno [ucsd.edu] who broke the Diebold voting system [ucsd.edu] and SSH [ucsd.edu].

  • The UNIX Way (Score:3, Interesting)

    by XMyth ( 266414 ) on Sunday May 16, 2004 @01:35PM (#9167875) Homepage
    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.

    • Re:The UNIX Way (Score:3, Insightful)

      by Sircus ( 16869 )
      ...and the reason that the general public is such a long way off is because it's not built into widely-used e-mail MUAs as a natural function. While there are certainly things to be said (though not all of those things are good) for simplicity and modularity with regard to security, until Outlook starts shipping with a standard "Encrypt this e-mail" checkbox, the general public isn't going to be using encrypted mails.

      Regarding not all of the things being good - you can't encapsulate security. That's exac
      • until Outlook starts shipping with a standard "Encrypt this e-mail" checkbox, the general public isn't going to be using encrypted mails.

        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.

    • 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.

  • This is an educational problem (Score:3, Insightful)

    by Schoony ( 675241 ) on Sunday May 16, 2004 @01:36PM (#9167878)
    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?

  • Is this research illegal? (Score:5, Interesting)

    by bigberk ( 547360 ) <bigberk@users.pc9.org> on Sunday May 16, 2004 @01:40PM (#9167900)
    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.
    • My understanding is that the research to break encryption itself is legal, but publishing a tool based on that research isn't. (Also, the DMCA only applies to encryption of copyrighted works.)

      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
  • "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.

  • Misleading!! (Score:4, Insightful)

    by logicnazi ( 169418 ) <gerdesNO@SPAMinvariant.org> on Sunday May 16, 2004 @01:58PM (#9168001) Homepage

    So how can we distinguish between an application that simply uses the right buzzwords, like AES, from an application that is actually secure?


    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)

    by DangerTenor ( 104151 ) <pmhesse2&geminisecurity,com> on Sunday May 16, 2004 @02:08PM (#9168041) Homepage
    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 [nist.gov] program, run by NIST and recognized by the US and Canada. A friendlier description is in this FAQ. [corsec.com]

    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.

    • 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)

    by StarBar ( 549337 ) on Sunday May 16, 2004 @02:21PM (#9168115) Homepage Journal
    between a secure program and a less secure program has nothing todo with AES. It is all about the keys. Whenever you are using symetric encryption, like AES, you need to store the key somewhere accessible both when encrypting aswell as decrypting. A human brain for instance. However at 128 bit encryption it starts to be hard to remember binary keys, even for smart folks. Then you need a secure way to store the key in, like a smartcard or an USB dongle or fetching it using PKI from a central storage using asymetric encryption like RSA. The weak point will still be the key storage and transportation, not the AES part.

    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)

    by ManyLostPackets ( 646646 ) on Sunday May 16, 2004 @02:31PM (#9168169)
    7-zip [7-zip.org] 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.

  • We've known this about ZIP files for 15 years! (Score:4, Interesting)

    by Teddy_Roosevelt ( 757045 ) on Sunday May 16, 2004 @02:31PM (#9168172)
    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?

  • Crypto is not vanilla and software is not cola. (Score:3, Interesting)

    by Lord Kano ( 13027 ) on Sunday May 16, 2004 @02:41PM (#9168212) Homepage Journal
    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

  • Much ado over nothing? (Score:5, Informative)

    by BillX ( 307153 ) on Sunday May 16, 2004 @03:12PM (#9168360) Homepage
    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.

    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 .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 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)

    by jonfelder ( 669529 ) on Sunday May 16, 2004 @03:14PM (#9168374)
    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.
  • Security is like safety. You have to do some serious analysis of the whole situation before even thinking about going out and purchasing lightscreens and control-reliable relays.

    Same thing with security. Simply downloading and installing the "latest security tools" does NOTHING except give you warm and fuzzies.

  • 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 cr

  • misdirected criticism (Score:5, Informative)

    by hak1du ( 761835 ) on Sunday May 16, 2004 @04:21PM (#9168693) Journal
    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.
  • how can we distinguish between an application that simply uses the right buzzwords, like AES, from an application that is actually secure?
    I don't know, but I'm sure it requires us to pay homage to Schneider.

  • Secure enough for most. (Score:3, Informative)

    by dtfinch ( 661405 ) * on Sunday May 16, 2004 @07:47PM (#9169663) Journal
    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.

Slashdot Top Deals

"Protozoa are small, and bacteria are small, but viruses are smaller than the both put together."

Close