Attacks on WinRAR volumes reusing same password? 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.
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.