Can I 100% trust the PBKDF2(HMAC-SHA256) AES-256 CBC encryption algorithm for file encryption purposes or not, and why? (Winrar)

Question

I am not an expert in cryptography and therefore I would like to address this problem to people who have been working on this topic for a long time and thus verify the facts from several sources.

I use Winrar for file encryption because it is most suitable for me, it's fast and I'm already skillful with this program. I am using up-to-date version of Winrar which uses PBKDF2(HMAC-SHA256) AES-256 CBC algorithm.

BTW in this link https://connect.ed-diamond.com/MISC/misc-092/usage-de-la-cryptographie-par-les-formats-d-archives-zip-rar-et-7z they says that the number of PBKDF2 iterations is optional 2^15 (default) 2^24 (maximum), however I did not find any command to set this parameter https://documentation.help/WinRAR/, other sources say that the number of iterations varies depending on the version used. Extracting a WinRAR password?

For comparison, here is a link to a password cracking benchmark using a commercial tool. https://blog.elcomsoft.com/2021/04/breaking-rar5-and-7zip-passwords/

Can I 100% trust the PBKDF2(HMAC-SHA256) AES-256 CBC encryption algorithm for this purpose or not, and why?

Thanks

Here are some links I would recommend, it might be helpful:

https://www.rarlab.com/rarnew.htm

https://www.win-rar.com/faq0.html

https://www.win-rar.com/industry.html?&L=0

I would also recommend reading related information on Wikipedia:

WinRAR,PBKDF2,Advanced Encryption Standard,Block cipher mode of operation Cipher block chaining (CBC),Rainbow table,Linear cryptanalysis,Partitioning cryptanalysis,Differential cryptanalysis, Substitution permutation network, Chosen plaintext attack, Chosen ciphertext attack, Rijndael_S-box, S-box

Answer 1

PBKDF2-HMAC-SHA256 is not a recommendable† key/password stretching algorithm, especially with only 2¹⁵ rounds. Problem is, it's too fast and resource-light to optimally slow down a password search for a powerful adversary (using GPUs, FPGAs, or ASICs).

It would be significantly safer to use a modern key-stretching algorithm like Argon2 at its industry standard parameterization. And, if that's not possible (e.g. because one wants to use WinRAR as is), it's advisable to increase‡ the PBKDF2 iteration count: the difficulty of password search grows about linearly with that. It's thus about 2⁹ > 500 times harder to crack a password with 2²⁴ rounds than it is with 2¹⁵ rounds.

However, poor password stretching is only a problem for poor passwords. For a large random password (e.g. 25 characters chosen independently at random among 64), that's a non-issue, and PBKDF2-HMAC-SHA256 with 2¹⁵ rounds or more is ample.

AES-256 CBC encryption is solid from the standpoint of ensuring confidentiality, and that's more likely not going to be a weak point.

If there's a weak point beyond the password and it's stretching, it's going to be a flaw (deliberate or accidental) in the implementation of WinRAR. Determining if there is one would be hard, and is off-topic.

---

† NIST is thus consistent when it is still endorsing PBKDF2-HMAC-SHA256, after actively lobbying for Dual EC DRBG (just as the NSA made DES keys 56-bit).

‡ The WinRAR 5 file format specification states there's a 1-byte KDF count specifying the base-2 logarithm of the number of PBKDF2 rounds (if the question is right, that would be 15=0x0F to 24=0x18). How to coerce WinRAR into increasing that is unclear to me (it's possible that the value depends on the version of Winrar, or/and licensing terms/country).

Answer 2

Can I 100% trust the PBKDF2(HMAC-SHA256) AES-256 CBC encryption algorithm for this purpose or not, and why?

There is no such thing as 100% security. We don't know if the AES algorithm can be broken, for instance. Also, if you lose the password then the "availability" part of the security triangle is lost. CBC doesn't provide integrity protection, although I presume the encrypted RAR archive by itself may provide some of that.

For in-place encryption that is not system-dependent, I would strongly recommend public key-based encryption where you secure the private key encrypted with a password. You can then use the public key to encrypt without providing any password. A disadvantage against this is that classical encryption algorithms (RSA, IES) are not secure against attacks from a fully-fledged quantum computer.

Many passwords have limited entropy, and PBKDF2 only allows a constant slowdown per password try. If you are going for password-based encryption then please make sure that the password is strong. Preferably use a strong password generated by and stored in a password manager application.