For example, if some part of the key-generation process (during both encryption and decryption) necessitated passing elements through, say, Ver圜rypt's servers then they could, in theory, impose extra rate-limiting or lock-out measures. 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. The first is clearly trivial the second depends on how much is unknown/unremembered, but neither is a "typical" brute-forcing scenario. 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. 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.Ĭonclusion: virtually 2 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. 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. 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. What other methods do you think they might have used? This severely limits the ability to brute-force (assuming the password is long- and random-enough 1). If your password is secure against dictionary attack - you can have high degree of certainty in the security of your data.ĭidn't veracrypt creators know about this issue?Īs 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. In these conditions the only feasible attack is dictionary-based, bruteforce would take too long. 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. Having high iteration count makes every attempt take a significant time (milliseconds to seconds). 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. 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). Some passwords are more likely than others, and this allows dictionary attacks on passwords. The weakest link is almost always not the key of the encryption algorithm, but the password from which the key is derived. 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 problem is that there’s not enough silicon on Earth to construct enough processors to do it before the heat death of the universe. 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.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |