If you make a volume with a good 64char random password and move the mouse to max entropy on the bar and also use a keyfile with also max entropy, and you upload this volume to the internet with your important documentation, what are the odds your data ends up accessed by someone?
They would need to crack the cloud storage service (layer 1) + the 64char (I think maximum) veracrypt volume (layer2) + somehow manage to guess the missing data that the keyfile deliver (layer 3) which is never uploaded into the internet but kept safe on a FDE linux drive.
So basically, could you sleep well at night that important data will not be accessed?
Even if they somehow got the cloud + actual veracrypt passwords, what does it mean if they miss the keyfile? does this impose an actual physical limtation because the header is incomplete without the keyfile thus rendering the volume useless without the keyfile, or is it theoretically possible to guess the missing data that is located on the keyfile?
Also, when creating a keyfile what settings should you use? I used whatever was set there in default.
Im asking this because I have seen people that were anti cloud storage lose all of their files (including financial data, all passwords, everything) because they were paranoid about hosting files online because of potential copies being stored there indefinitely even if you delete them and eventually with quantum computers they may be recoverable. I mean, okay great, this may be a realistic scenario in the future, but having learned about keyfiles, if they require the keyfile, they would be able to access the data without it?
I was considering splitting the volume in half and hosting it in two different providers or something, since I think that makes volume parts useless unless you got both, but the thing is, if a small keyfile does the same, then im set. I just want to know the details on how this works. Please let me know so I can think of the best way to go about it. It would be real handy if you could just store a small keyfile that makes the volume useless without it even in some crazy quantum computer eventual scenario.
With a strong password and secure keyfile, your VeraCrypt volume is almost impossible to access without the keyfile, even for advanced attackers. For most people, this setup is overkill unless targeted by high-level threats. Itâs incredibly safe for average users. Iâd even go as far as to say that itâs an over-sacrifice of convenience if you access it often.
Even without the keyfile, a 64 character password alone would be effectively impossible to crack, even by the most powerful computers known to man kind. That said, that doesnât mean not to use a key file. Keyfiles can protect against attacks like keyloggers which could record your passwords or malware that only exfiltrates passwords and the likes.
As a side note: obviously do not store your keyfile with the volume itself. You could store it locally on a drive, hide it (like using a random image/text file) in a different cloud storage.
You do not need to split your volume, it obviously would make it harder for your adversary to access, but even the NSA using all resources against a 64 character password and a keyfile would struggle with that alone. You also shouldnât worry about quantum computers either:
Groverâs algorithm gives a quadratic speed-up against brute-force on symmetric keys: it turns an n-bit key into an effective n/2-bit key. AES-256 (256-bit) thus offers ~128-bit security even against a quantum adversaryâfar beyond any practical reach today or in the near future.
Header keys are stretched via PBKDF2 (SHA-512) with hundreds of thousands of iterations. A quantum adversary still must run Groverâs search per hash iteration, so your high iteration count multiplies their work just like it does classically.
You have covered your bases well. This is, for all intents and purposes, unbreakable.
So you recommend leaving the default settings for the keyfile creation?
Thereâs a video on youtube called âVeracrypt Keyfiles and PIM Tutorial | Protect Your Encrypted Dataâ by âKMDTechâ and he changes the default âkeyfiles sizeâ from 64 to 1024. I left it at 64. Should I recreate the keyfile with 1024? I guess I will need a new volume.
He also adds an additional 2 keyfiles, an image and audio file. I guess this is overkill and with the randomly generated keyfile is enough, I mean you donât want those files corrupted and the more keyfiles the higher chances that happen.
And he also adds the PIN as well. I guess this is also not needed with a strong 64+char password and the keyfile. Btw, does veracrypt support 128 char password? Thereâs some wierd thing I keep reading, about how this works for windows for some reason but for not linux, but I think I tried yesterday with a 128 char password and it did work so maybe they have fixed this.
Then the other question would have been, what about the hashing algorithm for the volumes? Thoughts on cascaded algos? aes+2fish+serpent one sounds good.
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.
Thanks. I would use a PIM, but that would be yet another thing to remember, even tho itâs just 3 numbers.
As far hidding keyfiles, you would also need to remember where you place them, and if you type where they are located somewhere, that is a single point of failure.. so I have to think about how to sort this out in a way that is manageable. For now, securing keyfiles inside FDE copies of Linux is it, but I would need to think about how do I put them somewhere in a random folder where they donât stand out. Could you add a filename extension to them?
But in any case, arenât these files easy to find by a reasonably sophisticated attacker? kind of like how you can find Veracrypt volumes with some software (havenât tried it) that finds for randomness in files, and lists thinks that could be volumes (this is assuming they accessed your Linux FDE drive, that is.)
And as far as the 64bit key, the next time I make a volume, I will use 1024 there on the keyfile option, just as good ol paranoid approach to max out all settings.
And when it comes to using actual, normal files (like an image) as keyfiles, I guess this is easy to hide, since they are just regular files, but are not as strong as proper random data with a lot of entropy as the keyfiles you can create with Veracrypt.. so I see this tradeoff of choosing between files that look like something encryption related (a proper random keyfile) vs a regular keyfile that is just a regular file and easy to hide.
For cloud storage, any free email provider with reasonable features or any cloud storage service, I guess could do to store keyfiles, since they are useless by themselves, and then in a completely separated service, you can host the encrypted volumes, which are also useless without the keyfiles (and obviously, the passwords) where you may potential need to pay if you host a lot of data.
In this context, do you recommend any cloud storage services? Ideally, if you could pay in crypto it would be best. And it would be even better if you can buy a lifetime plan so you arenât worried about how if you forget to pay they may delete your files or something.
I donât need a ton of space, since itâs just documents, but now having learned about keyfiles, im more confident about hosting data online for a potential scenario in which you may lose all your data like a flood, fire or whatnot, so I was looking into how to clone your encrypted drive, which has a password, and then put it inside an encrypted Veracrypt volume, which has another password, which also requires a keyfile, which is hosted in another cloud storage, both cloud storage accounts having different passwords. I think this is a reasonable solution to store data without having to rely on a physical location, which at the end of the day is one big single point of failure.
Yes, keyfiles can be named anything with any extension. It would be useless to really do that for a VeraCrypt generated keyfile, as like you said any reasonable attacker would know that itâs a keyfile. If not that its a keyfile, at the very least they would know it is most certainly not a photo/video file. That being said, using custom keyfiles, like a photo or regular text file, CAN be hidden in plain sight. Or even better, having a photo in an encrypted partition (hidden partition if super paranoid) that is named just like every other photo that only you know is a keyfile.
Yes, there is a trade off. You said it perfectly. To mitigate this, you could use multiple keyfiles. It is up to you what you think is the best approach but you are understanding it correctly from what I see and what you said.
As for recommendations, I like Filen.io. There are also others like Mega.io, Internxt.com, and Proton Drive. As for lifetime plans, be careful as they can be cancelled at any point or if the company shuts down. Lifetime plans are notoriously known to be unprofitable for companies for the vast majority of users who purchase them. That said, I do trust that Filen.ioâs lifetime plan is trustworthy and worth it. Itâs 30 euro for 100GB. The reasons I believe it to be trustworthy is because itâs a small amount of storage for them at a decent price. Itâs not like they are offering terabytes of storage for 200 euros or something.
About cloud storage services: Do you trust these brand softwares, or do you log in into the websites and drag and drop the files in there? Iâve just seen all these fancy software apps that each company tends to release, and im not sure if thereâs a point. As long as your files are encrypted, + you enable encryption on your cloud storage service, I do not see the role of these programs, specially if closed source which obviously I wouldnât run and I assume they are all open source.
Myself, I just use the web version. It has everything you need for your use case. The application is more for if you access it a lot and for convenience.
Hi, just to be sure when understanding PIM. So what you are saying is, if the value of PIM is below 485 you are actually decreasing the strength of the setup? This seems crazy to me. How is this not warned with big letters during creation of a volume?
I mean, what if you have no idea and just type 20 or something?
By what do they say here, I understand that if your pass is less than 20 characters, then it will always use 485 minimum (even if you enter a lower PIM, it will override it and use 485 for iterations is what they mean?)
Well but what if your password is 20+ chars and you literally type 1 PIM? The way they phrase this here I understand that it actually weakens the encryption:
Motivations behind using a custom PIM value can be:
Add an extra secret parameter (PIM) that an attacker will have to guess
Increase security level by using large PIM values to thwart future development of brute force attacks.
Speeding up booting or mounting through the use of a small PIM value (less than 98 for system encryption that doesnât use SHA-512 or Whirlpool and less than 485 for the other cases)
So the first point is obvious.. okay 3 more numbers for an attacker to guess. Is this relevant for someone with firepower to bruteforce? I guess it helps.
The second point, I understand you increase protection against bruteforce, as long as itâs longer than 98 or 485 for sha256/sha512.
The third point is what seems shocking. It basically means, use a lower value to decrypt faster (because your encryption protection is weaker). And they should remind that this applies only to passwords shorter than 20 characters if I understood this correctly above. But in any case.. whatâs the deal here? I guess most people use around 20+ chars, so this PIM value will have a role in the strength of the encryption. If you go in there on the VeraCrypt volume creation wizard, you are not told that if you enter a value lower than 98 or 485 for sha256 and sha512 respectively, you are actually decreasing the strength of the encryption⌠wtf. I mean what if you enter a really low value and you have no idea about this? This is pretty lame tbh. Well at least you can tweak the PIM value it seems without having to redo the entire thing (or maybe you do because on the screenshot it looks like it wipes the contents)
I think this wizard should warn the user about this, because one just assumes this is just like a regular PIN number, just 3 numbers that have no impact on the encryption, certainly not potentially decreasing it.
This also adds an interesting/odd dynamic here⌠like, how many people may just put 999 in there because itâs the max security. So what if someone guesses the 999 number right? Isnât this less safe than a lower less obvious value? For an attacker it also potentially shortens the number of values from 485 and below because most people may not want to decrease but increase the effectiveness of the encryption (so an attacker has less numbers to guess is what I mean). Just considering all possible angles of this, hope it makes sense?
First of all, it is âPIM(personal iterations multiplier)â, not âPINâ. It has nothing to do with PIN numbers. And it is not VeraCryptâs fault that someone misreads PIM as PIN.
Second, Iâm not sure whether VeraCrypt prevents users from intentionally decreasing the iteration by using a low PIM number. But if youâre unsure about what PIM does, it is best not to modify it. This (seemingly obvious) rule applies to almost everything; do not change something if youâre not sure about it. No software/hardware can prevent a bad OPSEC. At the very least, read the official documentation or simply google âVeracrypt PIMâ, and youâll get enough information in less than 10 minutes.
Third, setting the PIM to 999 is not obvious at all. But even when the PIM value is known to the attacker, bruteforcing with PIM of 999 is harder than default PIM. PIM literally means âhow many times to iterate the key derivation functionâ, and higher the value, greater the calculations it requires.
Lastly, I suggest that you first go through the official documentation before asking basic questions. Might seem a bit long, but itâs definitely worth reading it.
Yes, if you set a value less than 485, you are decreasing the brute-force resistance than what the default provides. I presume it is not warned because people are encouraged to look up things they do not understand and read documentation.
Then you are decreasing the brute-force resistance of your volume.
I am unsure what you mean by this. The PIM is completely independent from the password. The PIM doesnât change based on password length.
No, it doesnât weaken the encryption itself. A PIM only impacts how difficult it is to derive a key from a password. I will show math below as an example. It is very technical and not super important to understand. Just know that a higher PIM = harder to brute-force password guesses.
Work factor â 1024 Ă 982 = 1,006,208 MiB¡passes.
PIM 20: 6,048 MiB¡passes
PIM 100: 83,968 MiB¡passes (~13.9à harder than PIM20)
PIM 1000: 1,006,208 MiB¡passes (~167à harder than PIM20).
Using a baseline of 1,000 guesses/second:
Guesses/sec at PIM20 = 1,000 g/s (baseline)
Guesses/sec at PIM100 â 1,000 / 13.9 â 72 g/s
Guesses/sec at PIM1000 â 1,000 / 167 â 6 g/s
Yes, maybe only a little but still helps.
Yes, if your PIM is higher than 485 it will increase the cost to brute-force your password.
Yes, using a lower PIM is only really advised if mounting to older devices that are slower.
No, PIM applies to any password length. If I were to guess where you are messing up is if you have a very long and complex password, it doesnât matter if your PIM is 1, it will be too difficult to brute-force anyway.
Correct. Like I said, I think the dev expects people to research things they donât understand. VeraCrypt isnât meant to be used by grandma. Itâs meant for power users who want more control. I never inputted random numbers for anything when I was first learning VC. This is not to diss or anything, I would just research what everything does before touching it.
Yes you can change it and no you do not need to wipe the contents. The PIM information is stored in the header of the container.
No. PIM is not a true secret and shouldnât be used as one. The main purpose of using a PIM is to maintain a higher cost of brute-forcing your password for the container. It is not meant to be used as a âyouâll never guess this.â because as stated earlier, if your adversary can brute-force at high numbers like a government agency, testing 1,000 PIMS on top of the brute-force isnât very difficult.
Yes, but it doesnât matter much. See the last response. The PIM isnât meant to be a âsecretâ as much as a technical feature, thatâs just itâs secondary âsideâ feature you could say. Hypothetically speaking, If you had a 128-character password and told the NSA your PIM was 485 OR EVEN 20, they wouldnât really be able to do much. Brute forcing a 128-character truly random password with a PIM of 1 would exceed the lifetime of the universe by magnitudes of hundreds. It is, practically speaking, impossible.
I get it. Itâs very easy to get wrapped up in the technicals of things. Just make sure your password is secure. If you are using a truly random 128-character password, the first weakness I think of is storage. Most people cannot reasonably remember that long of a password, they have to store it somewhere. If I were an adversary, my attack vector would be gaining access to that password.
Piece of paper in a safe? How can I break into that safe without damaging the paper.
Online password manager? How can I get into your password vault exploiting the online nature of it?
Offline password manager? How can I infect your PC with malware to gain access to RAM contents to then exfiltrate your database and access it on my own hardware.
Most people are a lot weaker than their encryption. If your adversary knows they canât crack the encryption, they will try and crack YOU. Remember this. You are only as strong as your weakest link, and that is usually yourself.
