# Using multiple keyfiles in truecrypt

I have a truecrypt container who's main password is 20+ characters long. I don't know if the keyfiles are still necessary for further improving the security. But anyway, I have folder of some .jpeg pictures from which I'm using three random choice pictures as a keyfiles. It seems this way I could even use five keyfiles at random but what's the advantage of using them? Isn't it just using one key file would be sufficient?

-

To know the strength of your password, don't look at its length, but at its potential. A password is as good as it is random, i.e. as good as the number of other values it could have assumed.

A simple case is when the password was generated as a sequence of random letters, each letter chosen uniformly and independently of the other letters. Since there are 26 letters, a 20-letter password implies 2620 = 19928148895209409152340197376 combinations. An attacker trying to guess the password will need, on average, to try half of them before hitting the right one. The accumulated cost would be tremendous, so the attacker would have very little chance of breaking through it. This number of possible, equiprobable combinations is often called entropy (not exactly the same notion as in physics, but close enough) and traditionally expressed in bits: you have an entropy of n bits if the number of equiprobable combinations is close to 2n. With 20 random letters, this means about 94 bits of entropy.

Moreover, TrueCrypt uses a good password hashing function, namely PBKDF2 with a random salt and 1000 (or 2000) iterations. Password hashing is a subtle matter, and TrueCrypt does it correctly.

To make the story short, if your password entropy is anywhere beyond 70 bits, your security is fine -- meaning that the cost of brute-forcing the password would far exceed the cost of simply obtaining the data through other means, such as abducting you and your family, or simply buying you out. We are talking about several (many) billions of dollars here... So, with random letters (all lowercase, let's make it simple to remember), 15 letters are enough. If you add uppercase letters and digits in the mix, 12 letters suffice, but the password may be harder to remember, and harder to type, especially on tablets/smartphones.

A crucial point of password generation is the need for good, impartial randomness. If you chose the password in your head, then it is not random. Witticism is not randomness; quite the opposite indeed. It is hard to estimate how much random can be a human-generated password, but it is often observed that such passwords are assumed by their owners to be a lot more random than is actually the case.

In the example above, I used letters but the calculation easily expands to any set of "symbols", even words. See this answer for details on a famous example.

The key files serve two purposes:

• To provide some extra entropy to a weak password.
• To provide some extra entropy which does not come in through the same path as the password.

Indeed, a poor password can be brute-forced if it does not have enough entropy, but even good passwords can be preyed upon through various methods: keyloggers, well-placed security cameras, sleep-talkers... Some of these methods will grab the password but not the key file, so the key file may save your skin in some situations.

The key file adds some security only insofar as the attacker does not know the file contents. However, it is a file. It is written on physical media. It is made available to the machine itself upon disk unlocking. We must assume that someone who steals the machine will also have a copy of all the files which could serve as key files (it depends on where you store them, but they are probably close to the machine since you need them to boot it). So the secrecy of the key file is not about the file contents, but about which file is used. For instance, if you have 100 possible files, then entropy is multiplied by 100 (in "bits" notation, this means about 6.6 extra bits). On the other hand, you have to remember which file was used, so that's some extra effort beyond the one needed for the password itself.

Personal opinions:

I note that key file processing in TrueCrypt is singularly homemade and weird; my cryptographer's senses are quite alarmed at this assembly of CRC-32 and haphazard scrambling. It would have been much simpler and better to simply hash each file, then hash the concatenation of the hashes and the password itself.

Also, the scenarios where key files have any value are rather restricted: these are scenarios where the attacker could grab the password, but not the key file, or not the information about which key file was used. For instance, a camera which has a view on the keyboard may also see your screen and easily obtain that information.

Therefore, I deem key files "not worth it" and I find that using the brain memory capacity to remember the key file to use is better employed at remembering a stronger (more random) password.

-
Thanks for explanation. But can you please tell how you derive that: "20 random letters, this means about 94 bits of enthropy" – Salvador Dali Sep 23 '13 at 0:51
@SalvadorDali Entropy bits per character is log2(n) where n is the size of the character pool, so for 26 (a-z) that's 4.7 bits per character. 4.7 bits per character * 20 characters = 94 bits of entropy. – Polynomial Sep 23 '13 at 15:24
thank you very much – Salvador Dali Sep 23 '13 at 16:21
I know this post is a bit old, but according to the recent audit (istruecryptauditedyet.com), the fact that they use PBKDF2 instead of scrypt and the fact that the number of iterations is hard-coded means that this version of TrueCrypt won't be able to keep up with GPU speeds. – Paul Apr 15 '14 at 18:18

TrueCrypt uses up to one megabyte of the keyfile to increase the randomness of the given password. Thus even one file with properly random content would probably be enough to defeat brute force attacks. (Well, up to the 64 bytes of the final internal password length, which is still plenty enough these days.)

Though using true random data inside the keyfile would probably be better, since estimating the true randomness of an image file is sometimes hard to estimate. And TrueCrypt comes with a proper keyfile generator for that.

Of course, all this is assuming your password and keyfiles are never available for the supposed attacker. One use for multiple keyfiles would be to select random six among say, one thousand pictures. Possible combinations would be around 1015, and rough calculations say that even with test speeds up to millions of files per second, it still would take a couple of decades to find out the right combination. The biggest downside is probably decreased usability, since now you also have to take care (and backup!) the set of keyfiles as well as the encrypted file.

-