This project has moved and is read-only. For the latest updates, please go here.

Keyfiles Size and Documentation

Topics: Users Discussion
Dec 9, 2014 at 2:30 PM
Hello Mounir,

I have a question about the keyfile size. When I create a keyfile using 1.0e version, the size of the file shows in Windows as 1 KB.

The documentation has the following warning:
WARNING: If you lose a keyfile or if any bit of its first 1024 kilobytes changes, it will be impossible to mount volumes that use the keyfile!
1024 KB = 1 MB yet the keyfile generator only creates 1 KB size file.

Since you have been working with the TC and VC code, does the code use the first 1 KB or 1 MB of the file?

I am trying to understand the differences between the generated file and the documentation.

Kind Regards,
Dec 9, 2014 at 10:22 PM
Edited Dec 9, 2014 at 10:23 PM
VeraCrypt, like TrueCrypt, uses the first 1 MB of any key file. As for the generated key files with VeraCrypt 1.0e (and also TrueCrypt), their size is 64 bytes but Windows Explorer show their size as 1 KB because it is the minimum size supported by Explorer display. You can check that they are indeed 64 bytes by going to the file properties.

In the next version, the user can choose the size of the generated key file between 64 bytes and 1 MB, the default being 64 bytes.
Dec 10, 2014 at 12:12 AM
Hello Mounir,

Thank you for the explanation.

Out of curiosity, what does random keyfile sizes between 64 bytes and 1 MB provide for the security? Is it to prevent keyfiles from being easily identifiable if they were all 64 bytes?

One recommendation I would make to the documentation is to replace "...first 1024 kilobytes.." with "...first 1 MB..." to be more clear.

Many thanks for your hard work!

Kind Regards,
Dec 10, 2014 at 1:13 PM
Edited Dec 10, 2014 at 1:14 PM
Out of curiosity, what does random keyfile sizes between 64 bytes and 1 MB provide for the security?

I made the request for random sized keyfile generation to provide a little obfuscation.

Although somewhat security by obscurity, any effort to frustrate an attacker is welcome. The more uncertainty we can force onto the attacker hash type used, algorithm used, what is or isn't a keyfile the better. We must also not always assume a user is trying to protect themselves from the 3 letter agencies in every scenario.

I personally generated these keyfiles and I don't actually use them on my volumes. I like them to be "available" for an attacker to find. :)

One of VC's strengths is it's uncertainty, there are a good number of variables to every VC volume and now keyfiles. An attacker has to start to make assumptions and guesses when attacking a VC volume. A nightmare situation for them but very good for us :)
Dec 10, 2014 at 3:35 PM
LOL. I like your idea and creating the keyfiles even though you do not use them.,

Thank you for the explanation. :)
Dec 10, 2014 at 4:55 PM
Edited Dec 10, 2014 at 4:58 PM

Oh I do use keyfiles, 1 MB ones and have done so from TrueCrypt days.

However the keyfiles I use aren't the ones I allow them to "find" :) That is one reason for the multiple keyfile request. The more keyfiles scattered across many peoples hard drives the better.

It is very common for "security experts" to undervalue security by obscurity. They all too often dismiss it, however I think they believe this because they approach security from their side only.

If you have ever, even for 1 day tried working on the other team so to speak, you will really appreciate just how demoralising uncertainty is.

If for example I know the password hash is SHA256 and it is iterated 1000 times, I can start work on brute forcing your password from common password lists.

If however I don't know the hash or even how many times it is iterated I cannot even start work.

I actually made a feature request to automatically randomise the hash type used when a user crated a new volume to enhance this effect. Without it the attacker may just assume defaults have been used which provides them with some hope. I want to remove that feeling :D
Feb 9, 2015 at 1:12 AM
Edited Feb 9, 2015 at 2:11 AM
EDIT. Sorry