Menu

Encryption

2003-08-15
2012-12-08
  • Nobody/Anonymous

    When 7-zip uses AES encryption, does it use ECB or CBC mode? Also, does it salt the passwords before hashing into key?

     
    • Bzyn

      Bzyn - 2007-04-28

      7-Zip uses CBC mode.

       
      • PIK

        PIK - 2007-04-28

        Little bit OT:
        Why AES? Rijndael have (also for NIST!) only "sufficiently" security.
        The decision for Rijndael is a compromise for all the small devices (smart card & Co)

        Twofish and Serpent have (NIST) more better and "high" security. Serpent
        is the best at the moment but noticeably slower.

        Twofish is the most used TrueCrypt method. Why? Twofish-256 is much faster
        then Rijndael-256. Near 1/4 faster. With *better* theoretical security.
        Paranoia-boys use Serpent. Imho only n00bs use AES (Rijndael) in TrueCrypt. Less security (theoretical) then Twofish AND its *slower*

        Ok. NSA use Rijndael in crypto suite B. But nobody known NSA's
        implemantation. And nobody known suite A ;-)

        Only key setup is with Twofish slower (comparsion with Rijndael). But is
        that most important for "us"?

        Therefore Rijndael is a super solution for VPN or WLAN. And smartcards. But
        its imho not best solution for 7-zip. For me Rijndael-128 with 10 rounds is less security. And with 256bit and 14 rounds its more slower then Twofish-256 (MORE) (cycles on P-II for encode/decode 1 Byte) And Rijndael-256 ist also 40% slower then Rijndael-128. Twofish its not.

        Again: In NIST PDFs from AES-competition, Rijndael dont have "high" security. Its only the best compromise for all 'applications' in NIST list. Compromise with "sufficiently" security. Ok. Its maybe also enough for us :-), but its always still noticeably slower then Twofish.

        Imho the AES-hype existing in/for winzip, winrar and other programms because of rumors in the press 2001/2002 (inet, press, TV) and its only therefore the security killerfeature for n00bs eyes...

         
        • Bzyn

          Bzyn - 2007-04-29

          What else I could say. I did know everything you said. And completely agree. But I just didn't bother to write it. I also wonder why GPG is using aes256 by default, but it's easy to change to twofish.

          AES256 is good enough for 7-Zip. I don't expect any one to use it for "top secret" information. As you used a lot of facts, you also should consider that anyone planning to crack encrypted files must first think that it's worth of the time and effort. This is valid point as far as I know. If thougher encryption is required then feel free to use other tougher means.

          OT IMHO is that Rijndael was selected for AES because NSA has some kind of trick cracking it very easily. Just listened security now and latest WEP braketroughs. I'm quite sure that cracking AES256 is "trivial" to NSA as well as cracking WEP is with latest tools. WEP is cracked in less than 60 seconds. But I'm sure that others also agree with this matter.

          Yeah, I'm a tinfoil hat dude too. But let's not make an overkill about this issue. I was already asking for adding salt, which might help if bruteforce password cracking is used. But it won't help if there are "fundemental flaws" in AES, but I actually think it's not my problem. Even if I have some bad legal evidence in archive. Intelligence organizations aren't going to reveal their cracking capability, it would be too bad for them. As we know from history. So I think this isn't problem for regular citizens or even small or medium sized businesses when ever there aren't special information giving that information mighty economical, political or military influence.

          In "our business" we handle tons of credit card data. Most often it's sent in zip archives, without password. Sometimes with password (using zipcrypto). I have been encouraging people to use 7-zip and 10+ char random passwords so data is "safe enough". There are easier ways to get that kind of information than cracking our archives.

           
          • Bzyn

            Bzyn - 2007-04-29

            But I forgot to add one point. If there aren't too much work, please add twofish cipher option, so everyone can be happy. SHA256 with salt is for sure good enough.

            - Thanks

             
            • beng

              beng - 2007-07-24

              Some interesting notes on ciphers:

              The one approved by the US government before AES was DES, developed by IBM with help from the NSA. It was widely suspected that the NSA could decrypt it easily.

              Before thet, after WWII the allies captured a lot of German enigma machines, which they sold to developing countries whlst keeping the secret that they had broken the code (it only came out in public in the 1970's). This enabled them to spy on the governments of these countries, who were using the enigma machines.

              As for using AES in archivers, see these:

              Analysis of the WinZip Encryption Method
              Paper by: Tadayoshi Kohno
              http://www.cs.jhu.edu/~astubble/dss/winzip.pdf

              WinZip's own spcification
              http://www.winzip.com/aes_info.htm

              On the security of the WinRAR encryption feature (128 bit AES)
              abstract
              http://www.springerlink.com/content/51184370n1g2854g/

               
            • beng

              beng - 2007-07-27

              In case Igor wants to add twofish to the list of encrryption types, here are links to the twofish source code:

              http://www.schneier.com/twofish-download.html
              see also
              http://www.schneier.com/twofish.html

              Niels Ferguson version:
              "There's a new Twofish C library, written by Niels Ferguson. The main differences with existing code available is that this one is fully portable, easy to integrate, well documented, and contains extensive self-tests. And it's 100% free." - Bruce Schneier

              http://packages.debian.org/stable/source/twofish

              http://packages.debian.org/unstable/libdevel/libtwofish-dev

              Crypto++® Library 5.5.1 by Wei Dai, includes AES finalists including twofish
              http://www.cryptopp.com/

               
            • Lou Cyphre

              Lou Cyphre - 2007-07-31

              If speed concern is one issue, why not considering Salsa20 as another optional encryption?
              http://cr.yp.to/snuffle.html

              ~ Lou

               
          • PIK

            PIK - 2007-04-29

            You are of course right. I haven't fear 'because of' 3 letter agencys and AES-256 is enough for us.

            But I am still 'wondering' why the "archive guys" implementet not only theoretically badder solution, but also practically SLOWER solution (then Twofish).

            I dont known whether Igor optimizing Rijndael asm (?) code. But I mean, when, he can also and better optimize Twofish.

             
            • beng

              beng - 2007-07-27

              Never mind the 3 letter agencies, there is already in the public domain a theoretical way to attack Rijndael (AES) and Serpent, but not yet twofish. See this article in Bruce Schneier's Cryptogram:
              http://www.schneier.com/crypto-gram-0209.html
              So far it is only theoretical and it is not possible to do it in real life, but the article says there is a possibility of it being broken in the next 10 years.

               
            • MLoup

              MLoup - 2008-05-22

              Found this old message and others like it, discussing encryption and algorithms and making weird claims regarding the security of AES vs. some other algorithms out there. Or why 7-Zip uses AES instead of some other algorithm.

              I'm not an expert, but nor are those who have shared their opinions here on these matters. So, here goes.

              AES is used because it is secure. 128 or 256 bits -- not relevant. Both are ridiculously strong. Braking them requires you to either tear the whole algorithm down to its pieces by some new breakthrough in cryptoanalysis (which would probably bring down most other algorithms as well, or seriously weaken them, making them equally useless from cryptonanalysis point of view) or brute force it. Bruteforcing 128 bit AES is not viable with anything known to Man. Not now. Nor in the unforeseeable future.

              But is AES weaker than, say, Twofish or Serpent? Some say that in theory it is. Is this important? No. Because we can't predict what future cryptoanalysis will reveal on any of those algorithms, it is pointless to say that either one is more secure due to some theoretical feature. They're "ludicrously safe enough" until proven otherwise.

              Even still, if I were to pick one over the other, I'd go for AES. It has already gone through substantial amount of analysis. Its security has been established to a certain extend. That is not the case on Twofish or Serpent, which, due to no-one's in practise using them, have seen only limited amount of analysis. Their security is more theoretical than truly established. No doubt they have a sound theoretical basis, but so have all good cyphers. When experts choose between these theoretically sound algorithms, they tend go for those that have proven themselves in the real world. Currently, most would agree the most trusted algorithm is 3DES. This is also what many experts recommend for those really paranoid about their security. No cypher comes even close to the analysis 3DEs has had, and the number of attempts to break it that it has withstood. It is as solid as these things can come based on out current knowledge.

              AES is also good, despite its being still a new algorithm compared to 3DES. This is because due its being the standard (3DES was too slow to be the new standard) it has been the target for extensive cryptoanalysis from all parts of the world since its adoption. The likelihood that some three-letter agency knows more about it than the cryptocommunity, is significantly smaller than on less studied algorithms, like Twofish. The more the algorithm is being attacked, the more assured we van be of its quality. AES has earned its position due to this fact. Its possible weaknesses (XST or whatnot attacks) are better understood and people are constantly trying to improve on these results. This is good. This is why we can keep on trusting in it until proven otherwise, in which we would be happy that it was being constantly attacked and that weakness was hence revealed.

              So, AES is used because it can be trusted. This is not necessarily the case on most other algorithms. Even a member of the Twofish development team has recommended AES over Twofish due to this very fact.

              If another algorithm were to be implemented in 7-Zip, it ought to be something with similar practical security level. Basically that'd come down to 3DES, or some of the early-90's algoes that have gone through extensive analysis, such as Blowfish or CAST-128, due them having actually been in wide-spread use. (unlike, say, Twofish)

              Of course, where the possible security problems of the 7z format would come down to would be the algorithm's and related components' practical implementation. Do you trust that the AES is correctly implemented in 7-Zip? Is the hashing part correctly done? Are there bugs in other parts that could affect these components? Ans so forth. Crypto security typically comes down to these kinds of issues. No one has recorded a single case where a correctly implemented AES would have been compromised. But there have been numerous cases of poor programming and sloppy implementation practises that have undermined the total security of crypto software.

              I don't know if 7-Zip sources have been analysed by crypto experts.

              But I know that were I paranoid, I'd create the archive on 7-Zip (unencrypted), and then encrypt it with GnuPG/PGP, for example. Possibly with GPG's 3DES.

              But since people use weak passphrases, or reuse old ones, what cryptoalgorithm or software they use is often irrelevant anyway. Even if your password were 20 characters long and fully random, composed of letters and number etc., it would be much weaker than, say, AES-128, making AES-256 pointless. People do not generally use ultra-long passphrases (dozens of random characters), so going above 128bit algorithms in archiving programs seems mere waste of CPU cycles. Even using salt makes more sense than going from 128 to 256, as the passphrase is typically the weakest link and the one the attacker attacks against regardless of what algorithm was used.

              Just my 2 cents. Sorry for dragging an old thread up again.

               
    • beng

      beng - 2007-07-24

      PS: Does 7-zip support AES encryption as used by WinRAR?

       
    • beng

      beng - 2007-07-24

      Some Encryption source code links:

      ISAAC: a fast cryptographic random number generator
      http://burtleburtle.net/bob/rand/isaacafa.html

      Twofish: A New Block Cipher
      http://www.schneier.com/twofish.html

      Both are used in SecExFile:
      http://www.bytefusion.com/download/winxp/middle.htm
      SecExFile Home Edition is a free version using a combination of Isaac stream cipher with Twofish block cipher. The free version uses twofish with a 128 bit key length, the commercial version with 256.

       
    • beng

      beng - 2007-07-27

      > By: PIK (beehaa) - 2007-04-28 23:38 
      > Imho the AES-hype existing in/for winzip, winrar and other programms because
      > of rumors in the press 2001/2002 (inet, press, TV) and its only therefore
      > the security killerfeature for n00bs eyes...

      Well it is advertised by the Americans:
      "The design and strength of all key lengths of the AES algorithm (i.e., 128, 192 and 256) are sufficient to protect classified information up to the SECRET level. TOP SECRET information will require use of either the 192 or 256 key lengths. The implementation of AES in products intended to protect national security systems and/or information must be reviewed and certified by NSA prior to their acquisition and use."
      http://en.wikipedia.org/wiki/Advanced_Encryption_Standard

      So the archivers that have AES will sell better in the US market, though perhaps not in the rest of the world since this probably means the Americans have a way to break it.

       
      • PIK

        PIK - 2007-07-27
         
    • Bzyn

      Bzyn - 2007-07-28

      Hi,

      Password Salting is still missing.

      Salt adds same stuff for encoding key as random IV makes to encrypted data even with same key. Using both is better.

      Both make decrypting data harder. Especially when using to use dictionary attacks. In some cases there might be huge pre-hashed dictionary. Salts prevent using precomputed hashes.

      - Thanks Igor

       
      • Igor Pavlov

        Igor Pavlov - 2007-07-28

        There were some problems with salt implementation as I remember (probably decrypting speed releated problems for non-solid archives that were updated). Maybe I'll enable that feature in future (.7z decoder supports salt).

         
        • PIK

          PIK - 2007-07-29

          Solid? Maybe I am totally blind, but I cant choose solid method in 4.51 (??)

           
          • Ares

            Ares - 2007-08-03

            It's been moved/renamed/combined.  Check under "Solid Block size."

             
    • Bzyn

      Bzyn - 2007-07-31

      Ahem? I think there could be some problems without solid archives. If every file is using new salt when encrypting. So whole AES-256 network must be re-established every time. Btw. I think this is even slower with Twofish, even continuous encryption is faster. How about using same salt / archive? So every file wouldnt be salted separately? Anyway if salt + key is cracked then I think it's quite possible to use key with other files with different salt anyway.

      Comments?

      I also noticed that latest beta has selection for encryption algorithm which is way cool. Even there is only one value to choose from. ;)

      That's the way to go!

       
      • beng

        beng - 2007-08-04

        There is more than one choice in the selection box for encryption algorithm when you are making a Zip file (as opposed to a 7z file): it lets you use the old zip password protection which is not secure, but compatible with Zip utilities that do not support AES.

         
      • beng

        beng - 2007-08-04

        > How about using same salt / archive? So every file wouldnt be salted separately?

        For the reasons why using the same salt for all the files in a multi-file archive is not a good idea, see:
        http://www.winzip.com/aes_info.htm#salt

        The way encryption is implemented is important. The use of AES does not necessarily make an archive secure - it depends on how it is implemented - as has been shown by the example of WinZip:

        Slashdot: Attacking WinZip AES Encryption:
        http://it.slashdot.org/article.pl?sid=04/05/16/1515216

        On the security holes in WinZip 9's implementation of AES, see Tadayoshi Kohno's paper:
        http://www.cs.washington.edu/homes/yoshi/papers/WinZip/winzip.pdf

        slide presentation about the paper:
        http://www.cs.jhu.edu/~astubble/dss/winzip.pdf

        Another paper saying WinRAR's implementation of AES is better than WinZip's:
        Abstract:
        http://www.springerlink.com/content/51184370n1g2854g/

         
    • Yutaka Sawada

      Yutaka Sawada - 2008-05-28

      I am not a expert of encryption, so I don't know AES algorithm's strength. But, from my tesing, 7-Zip's encrypted 7z archive is far stronger than WinZip or SecureZIP against Password crack. MLoup (tepesonen) wrote good points. Weakpoint of archive is mostly not in encryption algorithm itself. Speed is imprtant for user, but also for cracker. ZIP's encryption / decryption is faster than 7z, then cracking is faster, too.

      Encrypted ZIP archive has Password Verification Data to check inccorect password. This data is usefull for user, check type miss before decrypt whole. Then this data help cracker very much for brute-force trial. 7z dose not write those verifier, but Header Encryption give small sample. This is a possible weakpoint of encrypted 7z archive.
      If user dose not encrypt header, Filename / Size / CRC32 of each file is shown.
      If user encrypt header, the encryped header become sample to check password.

      I made a DLL for encrypted 7z archive, with non-7-Zip oriented AES and SHA-256 code. My encrypted 7z archive is compatible to 7-Zip's one. But compreesion is different from 7-Zip, I use zlib and libbzip2. My DLL can use Salt and changeable Iteration count and IV size.
      Salt size is 0 to 16 byte.
      IV size is 0 to 16 byte.
      Iteration (Cycle Power) is 2^0 to 2^62.
      As Igor said, 7-Zip can decrypt my 7z with changable Salt/IV/Iteration. This DLL's latest version is not public yet. If someone want for testing salt's effect, I can send my DLL by e-mail.

      BTW, encrypted 7z archive with high iteration can freeze 7-Zip. When you need 2 hours to encrypt a file with my DLL, 7-Zip need about 3 hours to decrypt the file even if you know correct password. While 7-Zip is hashing password, user can not cancel. So, it is better not to make 7z archive with high iteration.

       
      • PIK

        PIK - 2008-05-28

        Salt ist ok, IV is ok, iterations are ok. High interations? trueCrypt use 1000 to 2000 iterations and this is good enough.

        No salt, no iterations are a big security weekness.

        p.s.:
        Fastest on thze planet and 100% secure AES-asm comming from Gladman
        http://fp.gladman.plus.com/AES/

         
        • Yutaka Sawada

          Yutaka Sawada - 2008-05-29

          WinZip use PBKDF2-HMAC-SHA1 to derive key.
          I think trueCrypt may use it also.

          Password length dose not effect PBKDF2's calculation time.
          Password become HMAC key, so 64 byte (Hash block size) is the max size.
          If you type longer password, it just hashed to 64 byte.
          HMAC-SHA1 output is 20 byte, Counter is 4 byte.
          Hashed data size is roughly about " (Salt size + 20 + 4) * Iterations ".
          WinZip's salt is 16 byte, Key size is 32 byte (need 2 output), Iteration is 1000 times.
          Then, hashed data size is (16 + 20 + 4) * 1000 * 2 = 80000 byte.
          It need time to SHA-1 hash about 80000 byte for each files.

          7z dose not use HMAC, but use SHA-256 only.
          7z use UNICODE for password, so it is doubled than ASCII, Counter is 8 byte.
          Hashed data size is about " (Salt size + Password length * 2 + IV size + 8) * Iteration ".
          7z 4.58 dose not set Salt, IV is 8 byte, Iteration is 2^19 times.
          For example, user may use password of 8 strings.
          Then, hashed data size is (8 * 2 + 8 + 8) * 2^19 = 32 * 524288 = 16777216 byte.
          It need time to SHA-256 hash about 16777216 byte for each files or blocks.

          This is why I said 7z is far stronger than WinZip against brute-forcing Password.
          I don't like feeling or image or rumor , calculated proof is important.
          As user enter longer password, the difference become larger.
          If user set Salt or Higher Iteration to 7z, the difference become huge.
          Because 7-Zip dose not use Salt at this time,
          dictionay=database crack against SHA-256 hash can bypass this deffense of 7z.
          This is why I made a DLL to use Salt.

          BTW, SecureZIP dose not use Salt nor Iteration to encrypt files.
          It use SHA-1 of Password, very simple function of old Windows OS's Crypto API.
          To derive 256-bit key, it use SHA-1 3 times, 1 of password, and 2 of the hash block.
          Hashed data size is about " Password length + 64 * 2 ".
          For example, user may use password of 8 strings.
          Then, hashed data size is 8 + 128 = 136 byte.
          Because most file encryption freeware use samly simple deriver,
          I can not say SecureZIP is not secure, but it may have weakpoint.

          7-Zip's AES code is simple and easy to use, good implimentation.
          I use Gladman's AES code of C for my DLL.
          I tested speed of Gladman's C code, asm code, and 7-Zip's code.
          With my compiler, Gladman's both code are faster than Igor's code.
          But, the difference is small, HDD access become bottle-neck for file encryption.
          So, user may not need to care about encryption speed.
          Anyway LZMA compression is much more slow than encryption.

           

Log in to post a comment.