3
$\begingroup$

I have quite a few WinRAR volumes that are all encrypted with the same password. The password is long and unbruteforceable, but I recently read that WinRAR uses PBDKF2 as its key-derivation function instead of generating a new volume key every time like TrueCrypt, which means that in essence all of these volumes have the same 256-bit key.

Does that mean that if attackers got ahold of these volumes, they can use techniques similar to crib-dragging to extract the master password? Also, are these kind of attacks practical (i.e. have there been published success stories of such attacks)? I tried searching on Google but found nothing close to what I wanted.

$\endgroup$
  • $\begingroup$ Ignoring the fact that I’m not sure if “unbruteforceable” actually is a word (in case it is – I definitely like how it reads), it should be noted that there is nothing that can not be approached with a brute-force attack. I surely agree that a brute-force attack may not be a feasable effort in every case and/or situation, but a brute-force attack is always possible (while feasability is more a question of having access to according resources). $\endgroup$ – e-sushi Sep 18 '15 at 2:50
2
$\begingroup$

The RAR5 archive format encrypts file data using AES in CBC mode, and generates a 256-bit key using PBDKF2-HMAC-SHA256 (32768 iterations default?).

If an attacker is able to view many files encrypted this way all with the same key, the attack is to recover the key from the ciphertext. This is not an easy task, even if the IV was reused. In WinRAR, the IV should be pseudorandom, preventing the same (or similar) plaintext from generating the same ciphertext blocks.

Additionally, a 128-bit salt is provided during key generation, which should prevent the generated key from being the same for 2 different archives, even if the password is the same. For decryption the salt is extracted from the archive header.

While there is no documentation I can find that specifically says the salt and IVs are pseudorandom, I would assume that it is, meaning that for a given file/password combination, the chances of the archive ciphertext being the same are near 0.

Clarification from RARLAB on exactly how they are generated will help. In the windows UnRAR utility, there is a fallback from CryptGenRandom to using the system time to generate random bytes, which is not acceptable during archive creation, but may be reasonable during decompression for whatever reason. Password data is encrypted in memory and cleared using appropriate methods. I also find it curious why there is a separate salt value in the file record header, as the one in the archive header should be used for KDF.

$\endgroup$
  • $\begingroup$ This answer is really helpful. I didn't know about the salt and IV part and at least I can sleep more soundly tonight. $\endgroup$ – iyuaeo Sep 18 '15 at 3:20
  • $\begingroup$ You might want to clarify that even in the case of key+IV reuse there is no key recovery attack on AES/CBC. The two salts values are, as I understand, because header encryption and file encryption can be independently enabled. $\endgroup$ – otus Sep 18 '15 at 6:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.