8

File compression utilities like Winrar or ZIP or 7zip encrypt the password and store it inside the archive.

How safe is that? I mean you are giving away the archive with the password inside,it's not like authenticating against a web site where the password is stored somewhere remotely.

Can for example binary examination of the archive, given that the rar or zip file format structure is public, reveal the password's encrypted form? For example look for the header that contains the actual password and extract the encrypted string?

Say that this is plausible,is there something you can do to extract the clear password of the encrypted one?

microwth
  • 2,101
  • 2
  • 14
  • 19
  • depends on the hashing technique used, i guess – JOW Feb 19 '16 at 16:54
  • I think there is some confusion about how these file formats work. See http://stackoverflow.com/questions/15442565/how-do-you-get-the-password-hash-of-a-zip-file for a discussion of that, and http://security.stackexchange.com/questions/33410/can-password-protected-zip-files-be-broken-without-brute-force for some details on how they can be broken – Matthew Feb 19 '16 at 17:08
  • 1
    "File compression utilities like Winrar or ZIP or 7zip encrypt the password and store it inside the archive." - I very much doubt this. I cannot see anything in the ZIP specification which would indicate that the encrypted password is stored (encrypted with what?). Please provide a source for these claims. – Steffen Ullrich Feb 19 '16 at 17:33

3 Answers3

13

File compression utilities like Winrar or ZIP or 7zip encrypt the password and store it inside the archive.

I don't know where you got this information (claims without source are always bad) but I'm sure you got it wrong. This would not make any sense and the question would also be which key would then be used to encrypt the password.

With ZIP you can look into section 7.2 of the specification and you will see that the password will not be stored in any way. Only various more or less random data are stored which are used together with a key derived from the password entered by the user. These random data are used to make sure that ZIP files with the same content and same password don't result in the same encrypted data.

In the RAR specification you will find optional check value for the password. This is not the encrypted password but a hash value (i.e. irreversible) derived with PBKDF2 (computationally intensive hash) from the password.

Which means the most you have is a hashed version of the password, and hashed with a really slow hash. While this can be used to detect a wrong password fast enough for a single attempt, it does not help much with brute forcing the password. Brute forcing would probably be more effective by trying to use the password and checking if the decrypted data make some sense. This can be often done faster because most file formats contain typical magical strings at the beginning or have some typical file structure. Thus if you got something which does not look random you have probably broken the password.

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
6

The password is required to decrypt the archive, so storing a copy of the password inside the archive would be pointless - anyone who could decrypt the archive already has the password.

The only things that get stored unencrypted in the archive are the encryption type, and perhaps the file structure and file attributes.

Perhaps you're confused about how the archive is getting locked and unlocked. It sounds like you're under the impression that the password gets stored inside the archive, and then the archive utility compares the password entered by the user to the password stored in the archive. However, this is not how encryption works. If the password were stored in the archive such that the utility could read it, then anyone with a simple file editor could read it. Not only that, if the protection scheme were setup to simply force the utility to check against the stored password in this manner, but not obfuscate the data, anyone could simply read the contents of the file without even looking at the password. If the payload were encrypted and the password were stored somewhere in the unencrypted section of the archive, anybody could read the password and quickly decrypt the payload, thus defeating the encryption.

Instead, what encryption does is use a key and an algorithm to manipulate some data to obfuscate what it means. Once it has gone through this encryption process, the only way to make sense of the data is to process it through the corresponding decryption algorithm. The only way to successfully do this is by using the correct key and algorithm. Since the algorithm is always known, only the key is unique. The way you know that you used the correct key is the fact that the data you get out of the decryption process has a valid format and isn't just random garbage data. The only information an encrypted archive will give you is the encrypted payload and the algorithm used to encrypt it. It is up to you to supply the correct key.

Dr. Funk
  • 186
  • 4
  • There is generally some type of checksum/integrity check that is performed over the plaintext data and appended to the encrypted data. This is how the encryption is verified. – RoraΖ Feb 19 '16 at 18:41
  • That depends on the implementation and is not required. – Dr. Funk Feb 19 '16 at 18:44
  • This was a general description of how encryption works, not a specific, detailed description of a given scheme. – Dr. Funk Feb 19 '16 at 18:48
  • "under the impression that the password gets stored inside the archive, and then the archive utility compares the password entered by the user to the password stored in the archive".Exactly I was under this impression.But what is the password the user enters compared to? what kind of data is used?isn't a hashed password stored somewhere? – microwth Feb 19 '16 at 19:48
  • The password isn't compared to anything at all. It is simply plugged into the decryption algorithm (the password in this case is the encryption key) along with the encrypted payload, and the output of that algorithm is checked to see if its valid data or garbage data (or, as RoraZ pointed out, it is checked against some checksum). If the data is invalid, then that means the password was bad, and the archive utility will fail to open the archive. – Dr. Funk Feb 19 '16 at 20:16
  • This is different from an operating system authentication scheme where a user's password is hashed with a one-way hashing algorithm and the hash of the password is stored in order to be compared against later. – Dr. Funk Feb 19 '16 at 20:18
  • See: https://en.wikipedia.org/wiki/Cryptographic_hash_function#Password_verification – Dr. Funk Feb 19 '16 at 20:21
2

There's already been a discussion on something similiar that i think you might find useful. Does password protecting an archived file actually encrypt it?

Also, from what i read from there WinRar uses a 64 bit key( WinRAR uses 262144 rounds of SHA-1 with a 64-bit salt), which is pretty strong.

I'm not 100% sure on the following, so anyone correct me if i'm wrong. From what i understand when you encrypt a compressed archive or zip file, 7zip or winrar, the encrypted files doesn't let you read a key if there is one, as it is, encrypted. That would be the same as trying to decrypt an encryption without the key, so i'm pretty sure you can't get the key from the zipped file.

Also i'm not sure if it even stores the key. RSA encryption is one of the strongest encryptions(if you go for 2048 + bit encryptions), and some zip archives use the same AES encryption. The key isn't stored in the encryption, but the algorithm used to decrypt the file. The key is provided by the one who password protected/encrypted the file in the first place, and if the decryption key matches the encryption key, the algorithm will unravel the decryption, thus making it readable.

Does this answer your question?

Edit: As for just extracting the string with the encrypted decryption key, no. That wouldn't work as the key would be encrypted and useless, and you'd have to decrypt it to be able to read what the decryption key actually is, thus you're back at square 1.

For example, if i write: "pancakes", as "H01LG32H4Gg6H", you wouldn't be able to extract that encrypted string and convert it, as you don't know the algorithm i used to decrypt the word.

Community
  • 1
Robin
  • 59
  • 5