Key size speed, Strength, and correct format?

Topics: Technical Issues
Feb 9, 2015 at 1:20 AM
Edited Feb 9, 2015 at 7:58 PM
There's a few things I'm not clear on: I numbered them for clarity.
Also quickly wanted to Thank you to idrassi for all your support this far. You seem to be doing most of the responding and I know this must be very time consuming for you.

In the documentation it was mentioned that VeraCrypt only address the first 1MB of key-file's space because of performance. I just created a key that was:
Size: 976 KB (1,000,000 bytes)
On disk: 980 KB (1,003,520 bytes)

I didn't notice any difference in mounting times when mounting the test container with the larger key. I suppose there would be no difference with an encrypted drive. Where is the performance hit lost from using a larger key? Is it the on-the-fly encryption that suffers the performance loss, or the mount time?

I still don't really understand if using a 1MB key file would have any advantage over a 64 bit? There must be some reason because the size option was increased. The documentation doesn't really get into that. The math examples are beyond me. Sorry. Would there be any advantage from a security stand point to use a key a little larger then a 64 bytes? It doesn't seem like so since the internal output key is always 64 bytes anyway.

(3rd) what is the correct format to enter into the key generator dialog box? Say you wanted to enter a different value then the default, such as half a MB, or 1 MB. Are these numbers the same as data storage 1024 = 1 MB?


Would 1 MB simply be entered as: 1000000 bytes?
So 500 KB would be: 500000 bytes

Advanced Thanks
Feb 9, 2015 at 9:59 PM

Indeed, answering the questions is time and mind consuming but I do my best to be active on this side as it gives me the opportunity to interact with the community. Sometimes, when I'm busy coding I can't be present on the forums and I hope users can understand this and forgive my lack of responsiveness.

Concerning your questions:
  1. The 1MB limit of keyfiles was indeed chosen for performance reason, but as noted by the documentation, what is meant is "performance issues connected with processing extremely large files". Thus, the performance that is cited is the performance of reading and processing large files and in order to avoid this, a limit was chosen to ensure that this processing will always take the same maximum time no matter how bug the keyfile is. That's exactly why you don't see any difference between a 64 bytes key file and a 1MB key file.
  2. I think you meant 64 bytes, not 64-bit, in your question. From the entropy point of view, there is no security advantage of using a 1MB over a 64-bytes keyfiles IF AND ONLY IF all the 64-bytes were generated randomly through a good random generator. Keyfiles created using VeraCrypt have good random properties and thus they provide an entropy close to 512 bits which is the maximum needed.
    In practice, people don't always use randomly generated keyfiles. For security reasons, they will most certainly have to use innocent looking file as keyfiles, like MP3 or MPEG multimedia files. In this case, 64-bytes are not enough as they will never provide the necessary 512 bits of entropy. By processing 1MB of data of this type of file, we have more chances to achieve 512 bits of entropy while still ensuring a quick processing time.
  3. In VeraCrypt keyfile generator, the field size is expressed in bytes. It doesn't accept the symbols MB or KB. In the documentation, when MB is mentioned, it means a Mebibyte which is 1048576 bytes (2^20). A half of a MiB is 524288 bytes (2^19). This value is displayed in VeraCrypt keyfile generator dialog near the Random Size checkbox.
Voila voila. I hope I have clarified all the points.

Feb 10, 2015 at 9:15 PM
Edited Feb 10, 2015 at 9:22 PM
Thanks idrassi.
I will be making a donation soon, what ever it takes to keep this going! If I can just clarify one last time.

When you say, performance reason connected with "processing extremely large files" to be more specific: Do you mean large files that are being copied to and from the disk via the on-the-fly process? Or just opining a large file such as a large container. I didn't think the (user keyfile) was processed every time a read/write operation was preformed. I thought the (internal output-key) (which should always be the same size) is what the on-the-fly driver used for read/writes after the drive or volume has been mounted.

I see what you mean about the different types of files. So if you used something like an Mp3, the large size of 1MB could help because of the inconsistent entropy, but with a properly generated key file from something such as the built in VeraCrypt key generator, a 64 bit is just as strong because the entropy is done right.

By the way, I used TrueCrypt, I think it was 7.0 when I made my key file that I still use. I think it's 64 bytes. Do you recommend producing a new one with VeraCrypt? In other words, would VeraCrypt make a better key file than the Truecrypt 7.0 -7.0a key generator did?
Feb 12, 2015 at 10:13 AM
The processing I was talking about is related to the processing of large keyfiles not files stored in the volume. Sorry for not being clear enough. The idea is to have a mounting time that is constant independently from the size of the key files used.

VeraCrypt uses the same random generator as TrueCrypt. The only enhancement that was introduced is that the mouse mouvement dialog used to gather entropy from the user is displayed in VeraCrypt every time we need to generate random content whereas in TrueCrypt it was displayed only once per application run. The TrueCrypt approach is not insecure by itself but if the user keeps running for a long time and if he performs several sensitive operations (like creating volumes, creating keyfiles) then the random quality will not be as good as with VeraCrypt where new user entropy is injected before each operation.
In light of this, there is no fundamental problem with the use of keyfiles generated through TrueCrypt.
Feb 14, 2015 at 11:06 PM
idrassi wrote:
VeraCrypt uses the same random generator as TrueCrypt. The only enhancement that was introduced is that the mouse movement dialog used to gather entropy from the user is displayed in VeraCrypt every time we need to generate random content whereas in TrueCrypt it was displayed only once per application run.
Thank you. Yes, interesting what you said about TrueCrypt "only displaying the dialog only once per run". This use to drive me nuts. I would go to change a few drive's passwords and after the first one, the other's would not give me a pop up for the mouse entropy dialog. Something didn't seem right. So glad that you guys caught that!

You guys are doing a great job fixing all this stuff!