#8 Add Security Level Choices

[Anonymous]

Compare to TrueCrypt, VeraCrypt is more secure. But it is also more slow.
I encrypted a partition with key files(with hidden volume mode). Every time I mount the volume, it takes more than 30 seconds. But TrueCrypt need less than 1 sec.
So could you add some security level choices? By default it can set to highest level, and for some one who need much more performance, can choose to decrease security level.

[Anonymous]

May be there is some bug that caused mounting volume performance problem?

[Mounir IDRASSI]

As noted in the description of VeraCrypt, the slowness affects only the opening of the volumes and not the read/write operations once the volume is mounted.

Concerning the fact that TrueCrypt needs less than 1 second to mount the volume, this is not a good thing from the security point of view. That's why we choose in VeraCrypt to increase the complexity of the derivation function to make it highly secure for at least the next 10 years.

There is no bug that affects the mounting performance but it can be slow depending on which derivation function you choose (RIPEMD160, SHA512, Whirlpool). As you may know, no information about the type of PRF used in key derivation is present in the volume header for security reasons. Thus, VeraCrypt tries all available PRF functions in a sequential order till it finds the correct one. So if you choose Whirlpool for example, you'll encounter a very slow volume opening process.

A solution to this is to add a combo box on the volume opening dialog in order to let the user choose between automatic derivation function search (current way) or manual derivation function selection. This will dramatically speed up things for SHA512 and Whirlpool.

Concerning the idea of add a security level, this will translate to let the user choose between values of iterations count. From the code point of view, this is complex to implement as we have to change the business logic to make the iterations count configurable (iterations count is not encoded in volume header for security reasons).
Moreover, it can make things more confusing for users since they must also choose the same security level during volume opening since VeraCrypt can't know which one was used.

Thus, we'll keep this idea of security levels on hold and we'll focus on enabling the users to manually choose the derivation function as explained above.

[Anonymous]

Thank you very much for explanation.

[Anonymous]

Since you decided to take the big step of being incompatible with Truecrypt format, you might have also decided to select SHA512 as the default.

For people who care about these "details" and select SHA512 because it's more secure, it would avoid the delay during the mount. For others, it wouldn't make a difference.

Unless there is a good reason not to. Is there one ?

Another anonymous (because he hasn't taken time to create an account. :-))

PS : thanks for taking the relay on this extremely useful tool.

[Mounir IDRASSI]

Thanks for the feedback. We agree that SHA512 should become the default derivation algorithm instead of RIPEMD160 and it will be the case one we implement the manual selection of PRF in the GUI and the bootloade.
It has not been done since the beginning because RIPEMD160 is the only algorithm supported for bootloader and there some logic shared between it and the main GUI program.
We are cleaning the code and the SHA512 will be the default although we are not sure that we'll be able to integrate it in the bootloader because of size issues that force us to have a small bootloader.
So stay tuned.

[Stephen Brinich]

"no information about the type of PRF used in key derivation is present in the volume header for security reasons"

I'm dubious about how much that really improves security (adding an extra choice between three options is like adding one and a half bits to the key length) especially if it causes a significant delay in mounting volumes.

[Mounir IDRASSI]

The security reason is plausible deniability. We want encrypted volumes to consist of nothing more than random data. That's why we don't add any prefix or unencrypted header to the volume. And that's why we can't know in advance which PRF was used.

Of course, this applies more to partitions and devices than file hosted volumes for which there is no plausible explanation for a total random content. Still, plausible deniability can be achieved by creating a hidden volume within an innocent looking normal volume.

[Stephen Brinich]

OK, not having any identifiable "VeraCrypt specific" parameters makes sense, leaving no alternative but to try the list of derivation functions until one works.

It might work to have a limited list of security levels (e.g. three possible iteration counts: "low", "medium", and "high", each being a preset number), trying each possibility for each function (interrupting the iteration sequence at "LOW_Number" iterations to check, if the check fails continuing until it gets to "MEDIUM_Number" iterations, etc). The problem is that the extra checks would increase the mount delay for the "high" level (I don't know if the checking process takes long enough for this to be significant) and possibly tend to herd users down to the lower levels (which might still be an improvement over the existing TrueCrypt depending on the iteration-level choices).

(edited a bit for clarity)

[Mounir IDRASSI]

the PIM feature was introduced to address this: https://veracrypt.codeplex.com/wikipage?title=Personal%20Iterations%20Multiplier%20%28PIM%29