Questions about Truecrypt keyfiles

I'm wondering how truecrypt keyfiles work. Is the container encrypted against them? Or are they concatenated to the password?

If you have multiple keyfiles how does it know "which order" to use them? Basically, if I have files "key1" "key2" and "key3" it doesnt matter which order i choose them, truecrypt unlocks anyways. How does that work?

I assume truecrypt stores some plaintext info, like which encryption algorithm to use (AES, Twofish, etc). Does it store any info on keyfiles? Files names or anything?

If it doesn't, would it then "make sense" to store "fake" keyfiles ie: generate 9 keyfiles but only use 3 and store them all together. An attacker who gains access would need to try different combinations until they get it - obviously not super strong, but I'm curious. This wouldn't work at all if truecrypt stores plaintext info on keyfiles.

 

The first portion of your question can be found here ( - http://www.truecrypt.org/docs/?s=keyfiles-technical-details -) The documentation is however wrong in one respect. It speaks of a hash function whereas in the code only a cyclic redundancy code (CRC-32) is applied.

I do not believe there is any order when it comes to keyfile usage. As long as you append them all during the mounting of the container/drive it will decrypt due to the nature of the checksum mentioned above. And no, as far as I am aware there is not any keyfile information leaked when the volume is in an encrypted state. (Though I have not looked into v.7a.)

That being said with regards to your keyfile solution, while that may give a potential adversary a headache, it also can result in one for you as well. Not storing the keyfile on the same medium as the container would be good enough in my opinion.

In all, if you are going to use keyfiles there have been some research "attacks" against keyfiles in a sense. I have attacks in quotations because it involves more than one variable to align to compromise the strength of the keyfile or container password. To mitigate the potential vector, I would advise you or anyone reading to not use any file not explicitly generated by you (goes without saying).

 

Yes I read the technical details and I understand now why order isn't necessary, no info necessary.

In this situation it would be 9 keyfiles on a USB, only 3 of which work. It's like having a 3 character password with a character set of 9, hardly strong, just something I thought of - your attacker has to crack the password even if they have access to the keyfiles, so it's like adding another 3&9 combinations.

As in if you use a maliciously crafted keyfile that's generated by someone else it could be used to compromise the password or something?

 

There was some research done around a year ago where a group went after the CRC-32 checksum used for the keyfile algorithm. By adding extra bytes to the file used, they effectively zeroed out the checksum when the keyfile was mounted in other words the container could be both opened with or without the keyfile. Obviously if a password was included you would still needed to enter that. (Their proof of concept was their own research paper, an altered .pdf file hehe) The flip side of the coin is that an attacker could theoretically plant this file and craft it in a way that alters the password itself, meaning now the adversary knows the container password which would be unknown to the victim.

However bottom line nothing really was broken thus my "quotations", as it doesn't really matter what keyfile processing algorithm is used, if an attacker can get to a point where they are able to modify the content of the keyfile before the volume creation, they can reduce entropy regardless.