Keyfile size beyond 1MB doesn’t matter in Veracrypt.
From VeraCrypt documentation":
The maximum size of a keyfile is not limited; however, only its first 1,048,576 bytes (1 MiB) are processed (all remaining bytes are ignored due to performance issues connected with processing extremely large files). The user can supply one or more keyfiles (the number of keyfiles is not limited).
Given this, “keyfile size” is not the metric that matters. What matters is the entropy of the secret you add via keyfiles plus your password, and the work factor of the KDF. A truly random 64-bit keyfile already makes brute-force infeasible; a “1024-bit keyfile” doesn’t buy you anything practical beyond that, and in VeraCrypt the effective added entropy from keyfiles is capped by the 512‑bit keyfile pool and the KDF anyway. Quantum computers would at best square-root the effort, which still leaves a 64-bit truly random secret far beyond practical attack. So, in essence, you’re fine where you are. It doesn’t matter in any practical sense.
As for the additional keyfiles, that’s completely up to you. I don’t think it’s necessary but based on your threat model you might think it’s very necessary. Before adding more keyfiles, think about where you would store them. You ideally want to store all of them in separate locations and with random data. So for an image, storing them with hundreds of other images would be ideal. Do not make them distinguishable from the other images, ideally you would know exactly which one is your keyfile while following a specific naming convention that if an adversary were to see would not give away that it’s a keyfile.
On top of that, I’d make backups of all the keyfiles you have if you want to be sure you can access that volume.
Personal Iterations Multiplier’s are a great tool for 2 reasons. It acts as a mini secret while also making it more difficult to brute-force your container. If you don’t enter the correct PIM when attempting to mount, even with the right keyfiles and password, it will fail.
- If using PBKDF2 (SHA‑512/256/BLAKE2s/etc.), PIM scales the number of
hash iterations. - If using Argon2id, PIM scales the memory used and/or the number of passes.
This is how it makes brute-forcing more difficult. Each guess to open the container would be more computationally expensive. Argon2id (if you chose it) adds memory hardness. High PIM can force large memory use per guess, which cripples GPUs/ASICs that rely on massive parallelism.
All containers have default PIMs which are a safe medium.
From VeraCrypt documentation:
When a PIM value is specified, the number of iterations is calculated as follows:
For system encryption that doesn’t use SHA-512 or Whirlpool: Iterations = PIM x 2048
For system encryption that uses SHA-512 or Whirlpool: Iterations = 15000 + (PIM x 1000)
For non-system encryption and file containers: Iterations = 15000 + (PIM x 1000)
If no PIM value is specified, VeraCrypt will use the default number of iterations used in versions prior to 1.12 (see Header Key Derivation). This can be summarized as follows:
For system partition encryption (boot encryption) that uses SHA-256, BLAKE2s-256 or Streebog, 200000 iterations are used which is equivalent to a PIM value of 98.
For system encryption that uses SHA-512 or Whirlpool, 500000 iterations are used which is equivalent to a PIM value of 485.
For non-system encryption and file containers, all derivation algorithms will use 500000 iterations which is equivalent to a PIM value of 485.
So if you do want to harden it, make sure the PIM is above the default. For example, a PIM value of above 485.
Containers and non‑system partitions (Windows, macOS, Linux) allow passwords up to 128 characters on all OSes for standard (non‑system) volumes.
Windows system drive/partition (pre‑boot authentication) only accepts passwords up to 64 characters because it must be entered in the VeraCrypt bootloader before Windows starts.
Cascading algorithms only protect against an encryption algorithm being broken. For example, if there was a weakness discovered in AES, you would still have Two-fish and Serpent to fallback on and your container would be safe (assuming the vulnerability doesn’t exist in those algos as well) from the vulnerability. It doesn’t add any reasonable defenses against brute-forcing.
Hope this helps!