#How to use veracrypt keyfile password
), a nested set of calls starting with salt and password so if either one changes, while even assuming broken RNG at least password could change, you should recalculate entire routine along a keyfile. The proper implementation would be HASH(HASH(HASH(HASH(salt) ^ HASH(password)) ^ keyfile), keyfile. In other words, in order to get all possible keyfile contributions to password from your filesystem you need 64 bytes of data per each file, and that you can do silently with backdoored online antivirus! This problem is shared by Veracrypt, Discryptor and Keepass and probably all open source encryption software. Third problem is that keyfile processing is not stating with password or salt, therefore if you by accident use short password and the same keyfile TWICE, from the attackers standpoint, he would never need to recalculate the keyfile again over entire file, but rather stay with the same known CRC32 spread over 64bytes of pattern unique to a given file. Keepass, Diskcryptor do not have this problem. Second problem is that truecrypt keyfile parsing algorithm uses CRC32 instead of SHA256 or better, therefore appending CRC32 value at the end of most of your files (active preemptive attack on keyfiles), BEFORE you use them as a 'new fresh keyfile', might nullify the keyfile output, rendering you vulnerable when you switch unknowingly to a new keyfile thinking it will add something fresh to teh password. Veracrypt and Truecrypt both have this problem of 1MB limit per file (the rest is ignored),such files are easily transmitted over the network without even decreasing your bandwidth as a warning telltale. the one with keyfiles.Large files cannot be stored hidden in a bootsector using Evil Maid style attack etc, therefore you want the keyfiles to be large. In three-factor authentication (something you have), when being less or more connected to the internet, you might want to be able to detect file traffic of your files from your most acessed directory, i.e.
Keyfile parsing ignores data beyond first 1MB. There are at least the following problems with TrueCrypt keyfile implementations: Using a weak password on your main volume, then encrypting your keyfiles with a strong password is pointless - at that point you should just use a strong password on the main volume, and leave the keyfiles unencrypted. If you store them on a USB stick or flash card, a thorough search of your house / person will probably result in an attacker finding them. If you store them on your hard disk, forensic analysis of your disk will usually be able to locate your keyfiles.
You're limited to security-through-obscurity techniques, where you try to hide the keyfiles. A combination of the two allows for strong security.Īs such, relying only on keyfiles for security is probably a bad idea. In most cases, something you know is much stronger than something you have - people can steal your belongings, but it's much more difficult to steal your knowledge.
The password is something you know, the keyfiles are something you have. TrueCrypt's keyfiles are part of a two-factor authentication scheme. However, this does not mean that you get the same practical security from both types of key material. Fundamentally, the decryption key is an xor combination of the hash of the password and the hash of the keyfiles. In terms of cryptography, it is computationally infeasible break into your TrueCrypt volume without having both the password and the keyfiles. Tl dr - use a strong password, and complement this with keyfiles if possible.
0 kommentar(er)
