I'm really confused about why increasing the number of iterations has any potential to increase security. If you use an algorithm like SHA-512 or Whirlpool, and your password is sufficiently strong (~20+ characters), why would you ever need more than one iteration?
If you had a system that could computer 2^512 in a quick amount of time, it would eventually run into your one single combination that would unlock your data. Doing more iterations would change which combination you have, but I don't see how more entropy or randomness is added to it. I mean, if you bruteforce every combination, couldn't you choose any random number of iterations and run all combinations just from that number? If you know how many iterations are being used, it could speed up using a rainbow table, but if the password is not easily guessable, I don't see how knowing the iteration number helps at all.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I also don't understand why having a longer password is better than a shorter one. If you have some super random 10 character long one, why is it less secure than a super random 20 character long one? Are we just assuming that a bruteforce would start from passwords of length 1 and move up, therefore running into length 10s before length 20s?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
My understanding from the documentation is that the iteration count increases the time to brute force attack on the password. The salt is added to prevent rainbow tables from being used to compare the hash of the header key to the rainbow table.
The default number of iterations in VeraCrypt is a trade-off between security and boot or mount time. Each user can then influence these parameters using the PIM parameter.
Here is what NIST recommends for keys when used with very powerful computer systems where user perceived performance is not critical on page 7.
For especially critical keys, or for very powerful systems or systems where user perceived
performance is not critical, an iteration count of 10,000,000 may be appropriate.
I would advise not setting the iteration count this high using the VeraCrypt PIM feature unless you want to wait a very, very long time for your volume to mount or your system encrypted OS to boot-up.
We strongly recommend choosing a password consisting of more than 20 characters (the longer, the better). Short passwords are easy to crack using brute-force techniques.
If I increase my number of iterations, will it slow down read/writing, or just the initial decryption process? I'm considering increasing my amount soon.
Also, is there any way to quantify how much more entropy is added by increasing iterations? I've read a variety of different posts on this, but nobody seems to explain their reasoning behind any of their numbers.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Do you know if it's a linear change, like if I go from 500,000 to 1,000,000, will it be just about 2x as long, or will it be some kinda huge logarithmic time?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm really confused about why increasing the number of iterations has any potential to increase security. If you use an algorithm like SHA-512 or Whirlpool, and your password is sufficiently strong (~20+ characters), why would you ever need more than one iteration?
If you had a system that could computer 2^512 in a quick amount of time, it would eventually run into your one single combination that would unlock your data. Doing more iterations would change which combination you have, but I don't see how more entropy or randomness is added to it. I mean, if you bruteforce every combination, couldn't you choose any random number of iterations and run all combinations just from that number? If you know how many iterations are being used, it could speed up using a rainbow table, but if the password is not easily guessable, I don't see how knowing the iteration number helps at all.
I also don't understand why having a longer password is better than a shorter one. If you have some super random 10 character long one, why is it less secure than a super random 20 character long one? Are we just assuming that a bruteforce would start from passwords of length 1 and move up, therefore running into length 10s before length 20s?
My understanding from the documentation is that the iteration count increases the time to brute force attack on the password. The salt is added to prevent rainbow tables from being used to compare the hash of the header key to the rainbow table.
https://www.veracrypt.fr/en/Header%20Key%20Derivation.html
https://ostif.org/wp-content/uploads/2016/10/VeraCrypt-Audit-Final-for-Public-Release.pdf
Page 8.
Here is what NIST recommends for keys when used with very powerful computer systems where user perceived performance is not critical on page 7.
I would advise not setting the iteration count this high using the VeraCrypt PIM feature unless you want to wait a very, very long time for your volume to mount or your system encrypted OS to boot-up.
https://www.veracrypt.fr/en/Choosing%20Passwords%20and%20Keyfiles.html
You can internet search articles from cryptographers to get their opinions.
If I increase my number of iterations, will it slow down read/writing, or just the initial decryption process? I'm considering increasing my amount soon.
Also, is there any way to quantify how much more entropy is added by increasing iterations? I've read a variety of different posts on this, but nobody seems to explain their reasoning behind any of their numbers.
The iterations impact mount and boot times of the volume.
Do you know if it's a linear change, like if I go from 500,000 to 1,000,000, will it be just about 2x as long, or will it be some kinda huge logarithmic time?
I do not know. However, you can benchmark on your system:
Tools > Benchmark : PKCS-5 PRF
Enter your custom PIM.