Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

To improve security to some extent, I use keyfile generation technique (to change an existing file into an actual keyfile).

The actual keyfile is stored on volatile file system that doesn't survive computer reboot.

The question is, whether I may erase and delete the actual keyfile after the volume ahs been created?

If yes, then it could be safely overwritten and destroyed immediately after usage, further enhancing security associated with using truecrypt.

share|improve this question

2 Answers 2

To improve security to some extent, I use keyfile generation technique (to change an existing file into an actual keyfile).

Are you using an external tool to do that, or something built-in to TrueCrypt? AFAIK you can use any type of file as a TC keyfile, but the file is used as-is, no transformation is done. From the docs:

Note that TrueCrypt never modifies the keyfile contents. You can select more than one keyfile; the order does not matter. You can also let TrueCrypt generate a file with random content and use it as a keyfile. To do so, select Tools > Keyfile Generator.

Whatever method is used to "turn a regular file into a keyfile", you must make sure it's deterministic (i.e. always generate the same keyfile given the same input), otherwise you can't throw it away after use. And of course, if you generate it from a random source, you must keep it to be able to unlock the volume later.

If yes, then it could be safely overwritten and destroyed immediately after usage, further enhancing security associated with using truecrypt.

I don't see how that will enhance security. If the original file is sufficient to decrypt a volume, an attacker that has access to it can also do the same, regardless of how many intermediate steps there are to transform it into the resulting keyfile. Same with keyfile+password vs. original file+password. That means you have to protect this file as well as you'd do with the keyfile.

You could argue that using an arbitrary file is safer than using a "standardised" keyfile, since there are so many of them in your computer, and the attacker must know which one is the key. A 64 byte file with random data "stands out in the crowd", so they would in principle be the first ones to be tried. That's a bit like "security though obscurity", but if you have no better way to protect your keyfile, this should give you a little more protection.

However, I must point out that since TrueCrypt accepts many keyfiles at once, and it does its own hashing to combine them together and with the supplied password, you shouldn't need to perform the intermediary step yourself (that just potentially increases the attack surface).

And for a reason to have many keyfiles: if your storage media has N files and K of them will be used as keyfiles, the total number of combinations your attacker must try is N! / (K! * (N-K)!). By carefully choosing this number you can make it much more difficult to brute force it, even if the attacker has access to all your files and a lot of time and resources to try them. (just make sure to scatter the keyfiles through different folders...) It's up to you to decide the tradeoff between security and convenience, since supplying all those keyfiles also has its cost - in user patience, which can be very limited.

Update: as per your comment, you're using 20 files out of 1000, which in principle would take a long time to crack (1.6 * 10^10 years at 1000 tries/second). However, you mentioned that the files are chosen based on user input, so I must point out this fact:

Despite the large number of possibilities to choose those 20 files (5.3 * 10^20 ~ 68 bits of entropy), not all of them are equally likely to be chosen, since the process is not random. In fact, each sequence of user inputs (lets call that a "password") will deterministically lead to a single combination. Thus, the entropy of your scheme will be at most the same as the entropy of your "password" (capped at 68 bits). In other words, an attacker that knows your process needs only to redo the same (against a list of "password" guesses) to get a viable combination of files - a better result than trying all them at random.

Also, you must make sure the logic for choosing those files does not leads to too many collisions. If two or more inputs lead to the same set of files, either of them can be used interchangeably. If that happens, the resulting entropy can be even lower than you'd get by simply using that user input as a password. And, unnecessary to say, using a password with more than 68 bits of entropy will have no effect (i.e. 11 characters or more), since at this point collisions are guaranteed to happen (contrast to the max 512 bits of entropy that you can get by using a random keyfile, or about 420 by using a random password with 64 printable ASCII chars).

share|improve this answer
    
thanks for the detailed comment. However, the answer was whether I can erase the keyfile(s) entirely, whether the mounted volume does not need them to remain mounted. As for my approach, it's this. I create a vast number of random-size files with good entropy. A script takes user input and, judging by it, builds command line, using certain sequence of the mentioned keyfiles. I usually use 1000 or more keyfiles and encrypting uses 20 or more or them, so the possible attackers will need quite a time to try. So all I need to know is whether I can erase keyfiles. –  Konstantin Boyandin Feb 1 '13 at 3:03
    
@KonstantinBoyandin sorry, I assumed you wanted feedback on the security of your approach. The supplied keyfiles and password are used to derive the header keys (using a slow hash - PBKDF2, as of 7.1), which are then used to decrypt the master keys - as seen in the docs. Once this derivation and decryption are done, there's no use for the original inputs, since the actual keys will remain in RAM. So yes, you can erase them safely after mount. –  mgibsonbr Feb 1 '13 at 3:31
    
@KonstantinBoyandin please see also my update in the answer. I'm afraid the described process is not as secure as you expect it to be. Might even be equivalent of just using a password, plain and simple - thought it's marginally better, since: a) the attacker must have access to your files; b) this slows down the system a little, reducing the number of guesses per second. –  mgibsonbr Feb 1 '13 at 3:48
    
Thanks, that's what I wished to know. As soon as the volume is mounted, keyfiles can be safely removed/garbled. The diea is to keep keyfiles elsewhere and only copy them for the duration of mounting process. –  Konstantin Boyandin Feb 2 '13 at 9:31

Short answer : You can't delete the key file because it is required for the drive to mount.

Long answer : You actually can do what you want with the key files, even while the volume is mounted, but your volume will never mount again (unless you restore a password based volume header you might have saved earlier).

The key file, combined with your password if you use one, encrypts the header wich contains the volume key. It is that volume key that is important. This is why you can change keyfiles for a multi-gigabyte container without decrypting and encrypting the container again. Only the volume header (which contians the volume key) gets re-encrypted. It is a constant time operation.

After the volume key is decrypted and the volume is mounted, the key files are not used. Same for your password. They can be deleted or modified. But this will make it impossible to mount volumes that use the keyfile.

TrueCrypt Keyfile screen mentions it :

It will be impossible to mount volumes that use the keyfile

Your only hope if you delete your key files is to restore a volume header you saved somewhere.

Also, when you think about your threat model, keep in mind that the volume key are stored in volatile memory. An Evil Maid attack will go after the volume key, not your key files. An attacker won't even know which encryption method you used in the first place.

share|improve this answer
    
thanks. However, the asnwer was already given. The idea is to make mounting depending on a) password and b) keyfiles set, both of which can be taken from different (and more than 2) sources, thus somewhat diminishing, under certain circumstances, the possibility to find the proper keyfile sequence. I know of the mentioend attack. If system/bootable media is compromised, it should be checked first, otherwise it will be next to impossible to use any encryption safely. –  Konstantin Boyandin Feb 2 '13 at 9:35

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.