This project has moved. For the latest updates, please go here.

TC vs. VC Speed / Iteration counts revisited

Topics: Feature Requests, Users Discussion
May 26, 2015 at 12:35 AM
This started out as an additional feature suggestion regarding the revision of the iteration count issue and turned into a lengthy rant, so I figured I'd keep the suggestion verbose and post the rant part here.
Concerning the choice of iterations, my idea is that the user will enter a value that will be transformed to the iterations count using the formula: IterationsCount = (1024 x UserValue) + LowerBound
If the password is less than 20 characters, IterationsCount can not be lower than 500000 and so UserValue has a minimal value. When the password is longer than 20 characters, UserValue can be freely fixed (0 accepted).
This was taken from Mounirs post on the sourceforge forum LINK .

I have a few thoughts to expand on regarding this. I can very well understand both sides of the argument. "Going crazy" in terms of iterations or cascading to maintain something close like perfect forward secrecy at least for the rest of one's natural life even against the most determined and well equipped adversaries.

On the other hand security has to stand in the way of normal procedures and activities as little as possible. While hardline cryptoenthusiasts might be very willing to smoke a cigarette after password entry until the system boots up it will bother regular people to a degree where they will find ways to avoid it. It will lead to careless actions like putting a notebook to sleep instead of hibernation/shutdown, which of course compromises security. Or leaving a desktop turned on overnight. Or leaving volumes open for longer times than actually necessary. Or going back to different solutions, like Bitlocker (ugh) or old TrueCrypt versions (which I now also consider "dangerous" because it is hard to find a trusted copy and MD5 checksum - who can tell of any have been tampered with?)

People encrypt for a variety of reasons. You cannot expect everyone to become a specialist on the matter and avoid all operational mistakes like those mentioned above when faced with a software that "bothers" him in the stage of opening up a volume. The resolution for this guy would be not encrypt at all. But we want crypto for the masses, right? So the software has to be adjustable to be as unintrusive as possible. For some cases this means that the crypto is weaker than it could be. But who are we to judge the threat models and risk assessment of other people? The individual choice for a low iteration count does not decrease the security of those with a high one.

I think we all want an adoptation and success as wide as possible for VC, so, in essence I propose to expand the volume and FDE creation processes by a benchmarking feature. Very much like the throughput benchmark from TC and VC it would allow the user to figure out what iteration count works for him. There should also be an estimation as to how long an iteration count of XYZ will take in the pre boot environment (I am sure this can be calculated from the systems runtime 32 or 64bit performance, at least approximately). This will enable the users to make sure their boot time is not delayed much and in line with what they are willing to sacrifice. Some people start their notebook 5 times a day. Have them wait for the PBA each time?

Also, I believe that the minimal acceptable number of iterations should be not very far away from that of the original TC. It was argued here somewhere to be an attempt at weakening the software overall but I don't believe that to be universally true. It would be if the count was hardcoded to a number lower than in TC. But no one suggests that. I just believe that it should be possible for the user to chose a strenght similar to TC, if his threat model is not that of a rogue nation state with billions to spare.

Therefore, I argue, the inclusion of users with "lower security expectations" does not have to lower the overall standard of the software used. On the contrary, I believe it can improve it. A project like this, in the early stage, benefits from every single user as he brings bug reports and suggestions with him. And if the product satisfies him (and not some rather academic sense of security) he will let others know. Thus in fact growing the user base. The "hardline" users security with tens of thousands of iterations and long minutes of preboot authentication is not decreased or destroyed just because some users chose to use just a few thousand iterations and boot away in under ten seconds. But the more people use, more people look at it, reputation grows, etc.

Basically: educate the user about the tradeoff involved (speed vs. security) and let the user chose what he requires. This is IMO favorable to shoving down an "extreme" one-size-fits-all down everybodys throat. In one post somewhere it was argued that the "solutions" for a long delay at preboot or volume mount are a) buy faster hardware or b) use something "inferior" or older like TC. I very much dislike that mentality, because a) everyone should be capable of using crypto, even if they are unemployed and have to use donated hardware that is a few years behind the state of the art and b) there really aren't any. Bitlocker has to be assumed compromised as it is closed source AND coming from a US company. Many other solutions are closed-source, Many are of dubious heritage. Legacy TC versions have to be considered potentially compromised unless you happen to have stored a few "known good" copies before the plug was pulled.

Boy, what was supposed to take a few mins now took over half an hour. I need to go to bed.

Looking forward to your replies
May 26, 2015 at 3:49 PM
Edited May 26, 2015 at 3:52 PM
FYI, Mounir has released a beta with setting the iteration feature.

https://sourceforge.net/p/veracrypt/discussion/technical/thread/77d58591/?page=5
Coordinator
May 26, 2015 at 5:31 PM
Thank you very much for this thorough feedback. You analysis is very interesting and it coincides with the release of the first beta that includes the dynamic mode implementation.

It is important to have various opinions and points of view in order for VeraCrypt to meet the challenges of the real world. I agree that educating users is far more important that privileging security over usability because frustrated users will certainly take shortcuts that will break the security model.

In the dynamic mode approach, users have an incentive to use long passwords (more than 20 characters) if they need extra speed since they can choose a small PIN value. This is an indirect way to educate users. And by doing so they can also add an extra layer of security since the PIN value is never stored and they can keep is secret, although most users will use 1as PIN for best performances.

I like the idea of benchmarking key derivation: this will definitely be very helpful especially now that the PIN feature is available. This would enable users to choose the best PIN value the suite their need. Unfortunately, since the boot environment is 16-bit, it is not possible to give a realistic boot benchmark from the desktop environment but it is possible to implement some heuristic formula.

Did you have a chance to play with the latest 1.12 beta that implements the dynamic mode? (https://sourceforge.net/projects/veracrypt/files/VeraCrypt%20Nightly%20Builds/). I would like to have your feedback on it. Certainly, it needs some polishing to make more user friendly but I think it is a step in the right direction.

Thank you for sharing your ideas. I hope such exchanges will continue so that VeraCrypt can advance in the best direction.
May 27, 2015 at 7:52 PM
Edited May 27, 2015 at 8:06 PM
I have been following the iteration count debate and while I am enthusiastic about the new feature to allow this to be user-selectable, I am concerned about this real-world effect this new feature will have in the wild.

Proposal:

My proposal, which I will identify at the outset, is to add data for system encryption identifying the encryption type and hash algorithm used. This will allow one of two things to be done. Either a reduction in boot times by a factor of 16, or an increase in iteration counts for the same boot times by a factor of 16. Below I will give a little history, then analyze the best and worse case scenarios for maintaining VeraCrypt as it is (hiding the encryption method) versus following my proposal.

History:

TrueCrypt was historically very tightly married to the idea of "Plausible Deniability". This is historically the reason why data identifying the type of encryption used for any container (including system encryption) was never included in the container. In the TrueCrypt maintainers' opinion, there should be nothing to differentiate a container from random data. And while, for a normal container there is some value to this, in that no container can even be proven to be encrypted data at all, you cannot hide the fact that system encryption is in place due to the presence of the bootloader. However, retention of the same basic idea of never giving anything away has been retained when it comes to system encryption. The entire concept of plausible deniability and the way it is implemented in VeraCrypt is dubious and, in my opinion, dangerous, but that's a different discussion.

Analysis - VeraCrypt Status Quo

Best case: What is the best possible case real world effect of keeping the algorithm and hash secret? Well, there are eight algorithm combinations and two hashes, giving 16 combinations. Which means if I am brute-forcing a particular password or key, I need to do it 16 times to check all possible algorithm combinations. This is essentially indistinguishable to adding 5 bits of extra entropy to the password. Best case scenario, your password is 16 times harder to brute force.

Worst case: Keeping the algorithm you use a secret has various forms of attack. Not the least of which is simply the fact that as, effectively, part of the password, it has to actually be kept secret to be secret. By that I mean, what random system encryption user, when asked "Hey, you use VeraCrypt? How secure is that? What kind of encryption do you use?" will keep that secret? Do people treat that information like they would their password? Because as it stands now, it is, and needs to be. There are various other possible attacks on the algorithm used. It seems that VeraCrypt tries to mitigate timing attacks by checking all algorithm combinations at boot time. This means even if your algorithm is the first in the check chain, VeraCrypt seems to go through the work of checking all others before it boots. This helps to keep the algorithm secret, which is good, but may still be vulnerable to tempest attacks. Also, cryptanalysis can sometimes identify an algorithm by very slight bit biases where certain bits are more likely, say, to be a one than random chance would specify. This hasn't been identified yet (that I know of) for VeraCrypt's ciphers, but Twofish and Serpent have not received a whole lot of scrutiny either. So, worst case scenario is, someone finds out what algorithm you use and it is instantly 16 times easier to brute-force your system.

Analysis - VeryCrypt Adopts Proposal

Best Case: What is the best possible real world effect of identifying the algorithms used? Well it means that the bootloader doesn't have to try a bunch of different ones any more, and can then focus its attention on one. You can thus multiply the iteration count times 16 and have VeraCrypt boot in the same time as it does now. This is, as you might guess, the same as adding 5 bits of entropy to your password. So, best case (just as status quo) is it is 16 times harder to brute force your password.

Worst Case: The difference with my proposal is that there is no worst case. The algorithm is already known, so revealing it doesn't hurt anything. No one is likely going to answer "Hey, what's your password?" or even "What's the first character of your password?" in a way that will weaken their password, the same way they might answer what their encryption algorithm is. So, worst case scenario is.... the same... your password is still 16 times harder to brute-force.

Final arguments

There is a phrase in the security industry to describe using secret methodology to obtain benefits. It's called "security through obscurity". It's generally a pejorative term. Trying to keep the methods of encryption secret in order to add to your security is considered by most to be "mommy medicine". Something that makes you feel better but adds no real security. VeraCrypt has an opportunity right now, as it is revisiting the iteration count issue, to trade security-through-obscurity for real security. People are going to reduce the iteration count if you give it as a setting. That is going to happen. Not in every case, but many. People are ready right now to trade REAL security for decreased boot times. How about instead we trade the dubious security of hiding the algorithm instead? We can trade that for a) decreased booting times, or b) real security. Or both! You could increase the iteration count by a factor of four and still boot four times faster.

Let's make some changes and increase VeraCrypt's real security.
May 27, 2015 at 10:05 PM
Edited May 27, 2015 at 10:18 PM
I would prefer that the encryption and hash algorithms are not known and to force the attacker to guess. Not everyone shares what encryption and hash algorithms they use. Having the encryption and hash algorithms in the clear will not speed-up the mount times nor cause users to increase their password strength in terms of entropy and number of characters.

On the VeraCrypt roadmap is the ability to store the bootloader on a USB thumbdrive to create plausible deniability for system encryption and to help prevent Evil Maid attacks.

As Mounir has pointed-out many times, the longer delay of mounting a volume for system encryption has nothing to do with the encryption algorithm that has been selected, it is the 16-bit code for the bootloader and having to try each hash algorithm when autodetection is used along with the higher iterations for the hash algorithm.

For both system and non-system encrypted volumes, the latest beta allows user configurable hash iterations within certain limits to allow users who prefer faster mount times over the higher security. A win-win for all involved.

The roadmap includes creating a 32-bit bootloader and finally a 64-bit bootloader for 64-bit Windows OS to reduce the time to mount system encrypted volume.
May 28, 2015 at 1:34 AM
The new PIN feature is pretty nice, however I do not like the 20-char requirement for choosing a low PIN amount. In my business environment I am not trying to protect myself from a state-level attacker, more like a criminal that might steal our HDD's and perhaps put a bit of effort into decrypting them. For this scenario a password of length 8 and a PIN of just 1 would be more than secure. Perhaps a command-line switch could be added that would remove the 20-char requirement so sysadmins can better set up business computers.
May 28, 2015 at 2:25 AM
Edited May 28, 2015 at 2:58 AM
Hello Brett,

Mounir has posted on the topic of password length and its entropy that would be worth reading.

http://tinyurl.com/qat8pws

Let me ask this question. Is TrueCrypt/VeraCrypt purpose for commercial usage or home users?

In my opinion, the purpose of VeraCrypt software is for the home users as many businesses have regulatory obligations that they must meet and pass audits to prove that they are meeting the regulatory laws for their country and/or industry.

For example, can you prove to an auditor that all the PC's owned by the company are encrypted? What happens when a PC is reinstalled with Windows and is placed on the company network? Is your company using software to automatically detect this unencrypted PC and push the installation of encryption software and begin encrypting the disk?

Those questions are real issues that companies I have worked for had to resolve. Sometimes the hard way as when a PC got reinstalled without encryption and the PC was lost/stolen with sensitive data that cost the company millions of dollars in providing free credit watch for affected customers.

For full disk encryption on all PC's, this would mean using commercial software like Symantec Whole Disk Encryption and Endpoint by Check Point Software are a couple of business encryption software that come to my mind.

BTW, our IT Security global policy for all PC passwords required a minimum of 15 characters with at least one number and at least one special character. You were forced to change passwords every 45 days and could not repeat a exact or similar password for at least a year.

Kind Regards,
Enigma2Illusion
May 28, 2015 at 6:00 PM
idrassi wrote:
Thank you very much for this thorough feedback. You analysis is very interesting and it coincides with the release of the first beta that includes the dynamic mode implementation.
Thanks for taking the time to read through and thanks for pointing me towards the fresh release.
I like the idea of benchmarking key derivation: this will definitely be very helpful especially now that the PIN feature is available. This would enable users to choose the best PIN value the suite their need. Unfortunately, since the boot environment is 16-bit, it is not possible to give a realistic boot benchmark from the desktop environment but it is possible to implement some heuristic formula.
Yeah, I was aware of that, howeer as you say it should be quite an easy calculation once users hae gathered some "real world" examples. There has to be some sort of "relative factor" allowing for ballpark computation, and ballpark is all we need,, the user only needs a approximation.
Did you have a chance to play with the latest 1.12 beta that implements the dynamic mode? (https://sourceforge.net/projects/veracrypt/files/VeraCrypt%20Nightly%20Builds/). I would like to have your feedback on it. Certainly, it needs some polishing to make more user friendly but I think it is a step in the right direction.
Not yet, I was busy with work, but I will give it a look either tonight or on the weekend at latest.
There is a phrase in the security industry to describe using secret methodology to obtain benefits. It's called "security through obscurity". It's generally a pejorative term. Trying to keep the methods of encryption secret in order to add to your security is considered by most to be "mommy medicine". Something that makes you feel better but adds no real security. [...] How about instead we trade the dubious security of hiding the algorithm instead? We can trade that for a) decreased booting times, or b) real security. Or both! You could increase the iteration count by a factor of four and still boot four times faster.
Technically, is there not an option to combine those two concepts? My "under the hood" knowledge of crypto is too limited to know for myself. But lets take a container file. Traditionally, as far as I understand, there is no "plaintext header information" pointing the process towards the knowledge of what algorithm has to be used to decrypt. So the process goes through all of them, essentially bruteforcing the available variants (with the user supplied password) until it finds the right one? Is this about right?

So, would it not be possible to add the necessary information in plaintext to the container / MBR. The process would look for the header string first, use that designated algorithm for encryption and get on with business. If there is no info present in the expected format it would revert to the status quo and just bruteforce the possible algorithms until it finds the right one. I am no a programmer or cryptoexpert, but I don't see why those have to be mutually exclusive.

Generally, howeer I mostly agree with your sentiments, but I don't think you can really call this TC design feature "secuirty through obscurity". After all the source code was available for everyone, and there was no obscurity really, just a willfull omission to give adversaries as little as possible to go on. One thing however:
VeraCrypt has an opportunity right now, as it is revisiting the iteration count issue, to trade security-through-obscurity for real security. People are going to reduce the iteration count if you give it as a setting. That is going to happen. Not in every case, but many. People are ready right now to trade REAL security for decreased boot times.
There is also a saying in security that goes something like "security is a highly individual concept, not a singular product or acitvity". I agree that people who actually have to fear the government coming after them should be able to choose highly time-consuming, but technically very complex and secure settings to protect their containers or FDE systems. But I am not sure if those compose a majority of users. Many people just want protection against abuse of their personal data should they ever have their notebook stolen. The common laptop / identity thief is a very different attack vector. Then again some people just need containers to put their data up in the cloud. They could use a passworded zip file just as well, but they enjoy the possibility of mounting the file like a drive, instead of adding files through the archiver GUI. And others might have high security requirements, but need to boot their machine often so they might opt for a weak FDE and double encrypt the sensitive bits of their data again in a very strong container within the FDE.

What I am saying is that everyone should be given the means of tailoring the VC settings to their needs. The default should be biased toward strong, but there should be "advanced settings" allowing override. In the same vein I regard a password character limit as problematic, as has been pointed out by Brett in this thread. I believe he is fully capable of judging his adversaries, their attack vectors and therefore should be able to use VC as per his wishes. I am not asking to bring down the mandatory PW length limit down 8 for everyone. But, as proposed, maybe a command line switch or something similar.
BTW, our IT Security global policy for all PC passwords required a minimum of 15 characters with at least one number and at least one special character. You were forced to change passwords every 45 days and could not repeat a exact or similar password for at least a year.
I could never understand why companies did this. IMO, policies like those are utter bullshit because they enforce behavior that is counterproductive to security. Hardly anyone can make up a completely different but proper secure password every few weeks and still remember it. If everyone abides to this rule you will very likely have regular calls to IT support because people forgot the password they just were forced to change yesterday and need to reset it. If those calls don't happen rest assured that the employees have found very creative ways to abide by this regulation. Ways that weaken security and open lots of attack vectors. Some will write it down on a PostIt stuck under their keyboard or in their top desk drawer. Again, others will just use the date the forced password change happened as the password in the form of "November,13,2014" and mark the day in their calendar or smartphone.

From a technical perspective and academic viewpoint it is usually somewhat simple to figure out theoretical improvements to security, because the term is by its very definition relative. However, sometimes those changes, like the above forced password change policy, actually weaken the security when implemented in the wild, because the technology experts have no way of accounting for the erratic human behavior and capability limits.
May 28, 2015 at 6:58 PM
randomname0815 wrote:
Traditionally, as far as I understand, there is no "plaintext header information" pointing the process towards the knowledge of what algorithm has to be used to decrypt. So the process goes through all of them, essentially bruteforcing the available variants (with the user supplied password) until it finds the right one? Is this about right?
.
The longer mount times are a result of the high iterations performed on the volume's header key which holds the encryption key used to perform the on-the-fly encryption/decryption to the volume's data.

To eliminate VeraCrypt trying all the hash algorithms when you are mounting a volume, you have a couple of methods.

You can set the default hash algorithm in Settings > Default Mount Parameters then select the algorithm. If you leave it at the default Autodetection will cause VeraCrypt to try all the hash algorithms.

Secondly on the main password screen, you can override the default PKCS-5 PRF (hash algorithm) setting when mounting the volume to select the appropriate hash algorithm.
May 28, 2015 at 9:13 PM
So essentially autodetecting volume mounting / FDE access consists of running the total number of iterations on each and every one of the available hash algorithms to retrieve the keys?
May 28, 2015 at 10:58 PM
Edited May 28, 2015 at 11:27 PM
randomname0815 wrote:
So essentially autodetecting volume mounting / FDE access consists of running the total number of iterations on each and every one of the available hash algorithms to retrieve the keys?
.
Yes and also Favorites. From the manual:
Please note that since we can't assume that all favorites use the same PRF (hash) nor the same TrueCrypt mode, VeraCrypt uses Autodetection for the PRF of subsequent favorite volumes and it tries both TrueCryptMode values (false, true) which means that the total mounting time will be slower compared to the individual mounting of each volume with the manual selection of the correct PRF and the correct TrueCryptMode.
.
Starting in 1.0f version for non-system encryption, the order of preference of derivation algorithms :
SHA-512 -> Whirlpool -> SHA-256 -> RIPEMD160

You can read about the caveat the link below regarding the parallelization:

https://veracrypt.codeplex.com/workitem/61

I cannot find the order of preference of derivation algorithms for system encryption.
May 30, 2015 at 2:08 AM
Enigma2Illusion wrote:
I would prefer that the encryption and hash algorithms are not known and to force the attacker to guess ... Having the encryption and hash algorithms in the clear will not speed-up the mount times
It absolutely will speed up mount times for system encryption. Right now the system has to try sixteen different hash/algo combinations. Having the algos in the clear will allow you to swap algo secrecy (which is dubious security) for either much shorter mount times, or real security by having more iterations.

Enigma2Illusion also wrote:
On the VeraCrypt roadmap is the ability to store the bootloader on a USB thumbdrive to create plausible deniability for system encryption and to help prevent Evil Maid attacks.
Plausible deniability requires the former before you can have the latter. I don't care where you store your bootloader, having a hard drive in a computer that isn't bootable and contains random data is a big billboard saying "encrypted". The whole idea of storing a bootloader on a CD or pen drive should not be promoted as being for deniability.

The whole plausible deniability system in VeraCrypt needs to be flushed. It's beyond dangerous for a person to rely on it. I will fight that fight separately, as it's a separate issue though.

Enigma2Illusion then also wrote:
As Mounir has pointed-out many times, the longer delay of mounting a volume for system encryption has nothing to do with the encryption algorithm that has been selected, it is the 16-bit code for the bootloader and having to try each hash algorithm when autodetection is used along with the higher iterations for the hash algorithm.
It has to do with having to try each hash/encryption combination, exactly. Identifying the algos used removes the need for that. And, as I said, you can used the time you gain by not having to try every combination to either increase iterations further, which is real security, or to reduce boot times, as people are asking for. Instead of trading iteration counts for boot times, which is trading real security for faster booting, trade having to try each algo.
May 30, 2015 at 3:20 PM
Edited May 30, 2015 at 8:50 PM
Kudalufi wrote:
It absolutely will speed up mount times for system encryption. Right now the system has to try sixteen different hash/algo combinations. Having the algos in the clear will allow you to swap algo secrecy (which is dubious security) for either much shorter mount times, or real security by having more iterations.
.
Help me understand the 16 different hash/encryption combinations given that the long delay is opening the header key.

The manual states:
Header keys used by ciphers in a cascade are mutually independent, even though they are derived from a single password (to which keyfiles may have been applied). For example, for the AES-Twofish-Serpent cascade, the header key derivation function is instructed to derive a 768-bit encryption key from a given password (and, for XTS mode, in addition, a 768-bit secondary header key from the given password). The generated 768-bit header key is then split into three 256-bit keys (for XTS mode, the secondary header key is split into three 256-bit keys too, so the cascade actually uses six 256-bit keys in total), out of which the first key is used by Serpent, the second key is used by Twofish, and the third by AES (in addition, for XTS mode, the first secondary key is used by Serpent, the second secondary key is used by Twofish, and the third secondary key by AES). Hence, even when an adversary has one of the keys, he cannot use it to derive the other keys, as there is no feasible method to determine the password from which the key was derived (except for brute force attack mounted on a weak password).
.
From the example in the manual above, is there only one header key and one encryption key of 768-bits which has to be split-up into three independent encryption 256-bit keys? Or are there three header keys for each of the cascade encryption algorithms?

Meaning, the time delay for system encryption is finding which of the two hash algorithms (for backward compatibility RIPEMD-160 and the replacement SHA-256) unlocks the header key to access the encryption key to attempt the 8 encryption algorithm combinations.

Kudalufi wrote:
Plausible deniability requires the former before you can have the latter. I don't care where you store your bootloader, having a hard drive in a computer that isn't bootable and contains random data is a big billboard saying "encrypted". The whole idea of storing a bootloader on a CD or pen drive should not be promoted as being for deniability.
.
Or you can say that I have been bitten by a virus or malware. I don't know why everything on the drive is all jumbled-up.

Get creative and come-up with your own plausible statement. The key word is plausible deniability. :)