Do Veracrypt encrypted volumes have any kind of brute force protection?

Question

I have a 10mb encrypted volume which I made with Veracrypt and was planning to upload it to the internet. I have a pretty strong password but was worried about its protection against brute force attacks. After searching this SE it seems like a Veracrypt encrypted volume can be easily brute forced ref1, ref2. If that's the case then given enough resources we can crack any encrypted volume with any length of password (>100) in mere days with parallel brute-forcing instead of years.

Do Veracrypt encrypted volumes have any kind of brute force protection built into it? Didn't Veracrypt creators know about this issue? Is there any other strong encrypting system which has brute force protection?

VC is very slow at initial volume unlock compared to the old TC. That makes any BF useless since you will not be able to try any new password faster than every few seconds. — Overmind, Jun 10 '19 at 12:47
In both of your references, the OP had a pretty good idea of possible password candidates: it was their own password, they just forgot the details. One mentions only 1000-2000 possibilities. It's a *lot* easier to cycle through "Shoot, which word did I capitalize? Did I use an oxford comma? And was it a ! or a ? at the end?" than it is to find a complete password with little or no prior knowledge. — Ben, Jun 10 '19 at 13:19
You cannot "protect from bruteforce". Imagine VeraCrypt implemented something that stops checking after X attempts. An attacker can simply that the VeraCrypt code, remove that check and obtain a software without that protection. The only way to protect from BF is to make every attempt quite costly. Your examples are very specific and do **not** really represent a brute force attack... they are brute force attack on an extremely small subset of keys due to previous knowledge. — Giacomo Alzetta, Jun 10 '19 at 14:47
It may be better to ask if it has protection against "_dictionary attacks_" rather than "_brute-force attacks_". I mean, large keyspaces are the protection against brute-force; the concern here seems to be about attacks against smaller keyspaces, i.e. dictionary attacks. — Nat, Jun 11 '19 at 13:43
@GiacomoAlzetta Even more trivially, an attacker could clone the VC volume to another hard drive, and attempt to brute-force that clone. — Monty Harder, Jun 12 '19 at 17:08

Andrew Morozko · Answer 1 · 2019-07-05T09:16:18.270

Any encryption is vulnerable to brute force attack, for example AES-256 has 2^256 keys, and given enough hardware we can “easily” brute force it. The problem is that there’s not enough silicon on Earth to construct enough processors to do it before the heat death of the universe. The fact that encryption can be bruteforced doesn’t mean that this will happen in a reasonable amount of time, and we can thank probability theory for that;)

The weakest link is almost always not the key of the encryption algorithm, but the password from which the key is derived. Some passwords are more likely than others, and this allows dictionary attacks on passwords.

In this respect the VeraCrypt project does everything by the books: they are using PBKDF2 with strong hash algorithms and high iteration counts (this is somewhat controlled by the user). Using PBKDF2 with random salt prevents the attacker from using pre-made hash tables and forces them to calculate every key attempt specifically for your container. Having high iteration count makes every attempt take a significant time (milliseconds to seconds). Repeated hashing is inherently unparallelizable (single PBKDF2 operation is unparallelizable, the attacker can perform multiple simultaneous guesses of course), so custom hardware wouldn’t help much.

In these conditions the only feasible attack is dictionary-based, bruteforce would take too long. If your password is secure against dictionary attack - you can have high degree of certainty in the security of your data.

Relevant documentation: https://www.veracrypt.fr/en/Header%20Key%20Derivation.html

My only nitpick is "Repeated hashing is inherently unparallizable, so custom hardware wouldn’t help much." True, repeated hashing can't really be parallelized, but why does that matter? It's trivial to parallelize by making multiple guesses at once rather than by trying to speed up one guess. This is why password crackers use GPUs nowadays. — AndrolGenhald, Jun 10 '19 at 14:44
@AndrolGenhald, some algorithms have a flaw whereby attacking multiple passwords at the same time is more efficient than attacking them sequentially. Veracrypt doesn't have this flaw. — Mark, Jun 10 '19 at 22:18

score 22 · Answer 2 · answered Jun 10 '19 at 13:21

Didn't veracrypt creators know about this issue?

(Not having brute-force protection)

As Andrew Morozko notes in his answer, they have addressed this – as far as it is possible – by using a secure key-generation function (PBKDF2) and high iteration counts. This severely limits the ability to brute-force (assuming the password is long- and random-enough¹).

What other methods do you think they might have used?

On a website, where the software policing login attempts is owned by the defender, you can do things like rate-limit login attempts (with increasing delays, way beyond the actual computation time for checking the password) and lock the account after too many failed attempts.

However, with VeraCrypt, the software handling an encrypted volume will be sat on the attacker's machine, and must therefore be considered "owned" by the attacker. Even if the writers were to have incorporated code to rate-limit attempts, it would be "trivial" for someone to reverse-engineer the binary and remove/bypass the rate-limiting code.

Conclusion: virtually² any measure above and beyond what is inherently required to check the password would be useless and easily circumvented.

¹ The two references you cite to claim that "a veracrypt encrypted volume can be easily brute forced" do not, in fact, show this. One is where the correct password is known to be in a list of "1000-2000" candidates; the other where "most of the password" is remembered. The first is clearly trivial; the second depends on how much is unknown/unremembered, but neither is a "typical" brute-forcing scenario. As Andrew says, "If your password is secure against dictionary attack - you can have high degree of certainty in the security of your data.".

² About the only possibly conceivable method I can think of would be where the process of credential validation involved (and required) talking to servers under someone else's control. For example, if some part of the key-generation process (during both encryption and decryption) necessitated passing elements through, say, VeryCrypt's servers then they could, in theory, impose extra rate-limiting or lock-out measures.

However, even if this could be done (in a way that was both cryptographically necessary, but didn't leave copies of the keys with VeraCrypt) it would be unacceptable to virtually all use-cases: requiring a working internet connection every time someone mounted a drive, and any encrypted volumes would be come useless should VeraCrypt (and their servers) cease to be.

In response to your footnote 2: A possible way to implement this: They key-part can either be generated by calling the VeraCrypt-Servers, or by solving a hard hashing problem (taking a lot of time, e.g. 5 minutes) - then a call to the servers would be fast, but rate-limited, while you could still decrypt your drive offline by waiting 5 minutes. — Falco, Jun 11 '19 at 09:48
@Falco On reflection, I don't think either my original thought, or your modified version would make any real difference: you'd just alter the code so that the "main" brute-force attack was injected at a point _after_ getting the response back from the server (or solving the 5-minute side-problem). — TripeHound, Jun 11 '19 at 15:03

Do Veracrypt encrypted volumes have any kind of brute force protection?

2 Answers2